Menuju Era Tanpa Kebutuhan Graphics API

 (sebastianaaltonen.com)
7 poin oleh GN⁺ 2025-12-17 | 1 komentar | Bagikan ke WhatsApp
  • Selama 10 tahun terakhir, graphics API tingkat rendah seperti DirectX 12, Vulkan, Metal memang meningkatkan performa GPU, tetapi kompleksitas dan biaya pemeliharaannya juga melonjak tajam
  • GPU modern mendukung hierarki cache penuh, pointer 64-bit, resource bindless, sehingga objek status dan model binding kompleks lama menjadi tidak lagi diperlukan
  • Desain yang diusulkan sangat menyederhanakan pipeline rendering dengan menggunakan akses memori berbasis pointer C/C++ dan satu root pointer 64-bit
  • Pendekatan ini menghapus ledakan PSO, resource barrier, binding API yang kompleks, dan menawarkan struktur yang menghubungkan memori GPU serta bahasa shader secara langsung
  • Pendekatan ini adalah API generasi berikutnya yang dioptimalkan untuk arsitektur GPU modern, dan menunjukkan arah yang seharusnya dituju oleh DirectX 13 atau Vulkan 2.0

Perubahan pada graphics API tingkat rendah

  • Pada 2013, arsitektur AMD GCN di Xbox One dan PS4 menjadi standar pengembangan game AAA, lalu muncullah API tingkat rendah seperti Mantle, DirectX 12, Vulkan, dan Metal
    • Artinya, API-API tersebut dirancang dengan acuan arsitektur GPU sekitar tahun 2013
  • DirectX 11/OpenGL sebelumnya memiliki keterbatasan karena rendering single-thread dan overhead driver yang tinggi
  • API-API ini mengurangi biaya draw call dengan pipeline object (PSO) yang telah dikompilasi sebelumnya, tetapi karena tidak cocok dengan struktur engine, kompleksitas justru meningkat
  • Akibatnya, di dalam engine muncul lagi semacam “lapisan driver low-level” tersendiri, sehingga peran graphics programmer menjadi semakin terfragmentasi

Latar belakang historis: mengapa jadi serumit ini

  • GPU awal dibangun dengan memori yang terpisah dan arsitektur yang berpusat pada fixed-function pipeline
  • OpenGL dan DirectX mengadopsi desain berbasis state dan objek untuk mengabstraksikan keragaman hardware
  • Bahkan hingga DirectX 11, texture dan buffer masih dikelola sebagai descriptor opak
  • Pola desain ini kemudian terbawa terus secara inersia ke API-API berikutnya

Ketidaksesuaian antara GPU modern dan API saat ini

  • GPU saat ini mendukung hierarki cache yang konsisten, PCIe ReBAR, pointer 64-bit, texture bindless
  • Kini dimungkinkan adanya struktur di mana CPU menulis langsung ke memori GPU dan GPU langsung membacanya
  • Dalam lingkungan seperti ini, struktur seperti PSO, descriptor set, binding table menjadi tidak diperlukan
  • Masalah ledakan cache PSO membuat cache ratusan GB dibutuhkan, dan ini menjadi penyebab loading lambat dan stuttering
  • API baru dapat menghapus struktur usang seperti ini dan beralih ke pendekatan sederhana berbasis pointer

Penyederhanaan manajemen memori GPU

  • Vulkan/DirectX 12 lama tidak efisien karena setelah resource dibuat, kompatibilitas heap masih perlu dicek
  • Pendekatan yang diusulkan memakai API sederhana berbentuk gpuMalloc/gpuFree untuk mengalokasikan memori GPU secara langsung
    • CPU dapat memetakan memori GPU secara langsung untuk inisialisasi
    • Data berukuran besar dikirim lewat perintah copy untuk menjalankan kompresi DCC dan pemrosesan swizzle
    Iklan
  • Alamat mapping CPU dan alamat GPU dibedakan, lalu dikonversi dengan gpuHostToDevicePointer

Modernisasi data dan bahasa shader

  • Menggunakan bahasa shader berbasis pointer C/C++ seperti CUDA, Metal, dan OpenCL
  • Akses memori yang efisien dimungkinkan lewat wide load pada level struct (128-bit atau lebih)
  • ByteAddressBuffer atau texel buffer milik DirectX tidak lagi menjadi pilihan optimal
  • Karena GLSL/HLSL tidak mendukung pointer, tidak ada ekosistem pustaka shader reusable, sementara CUDA berkembang dengan pustaka yang kaya

Root argument dan struktur data

  • Kernel GPU menerima satu pointer 64-bit sebagai input lalu melakukan cast ke struct
  • CPU dan GPU berbagi header C/C++ yang sama untuk menjaga konsistensi struktur data
  • Kata kunci const/restrict digunakan untuk mendorong optimisasi compiler, sekaligus menghapus pemisahan UBO/SSBO yang tidak perlu
  • Memanfaatkan preloading scalar register dan optimisasi dynamic uniform pada GPU modern

Penyederhanaan texture binding

  • Semua texture dikelola sebagai array descriptor 256-bit (heap) yang bisa ditulis langsung oleh CPU maupun GPU
  • Mendukung sampling texture non-uniform melalui akses berbasis indeks 32-bit
  • Lebih sederhana daripada descriptor heap di DirectX 12 SM 6.6, dan mirip dengan Vulkan VK_EXT_descriptor_buffer
  • Pembuatan, upload, dan sampling texture semuanya disatukan dalam model berbasis pointer memori GPU

Pipeline shader dan konstanta

  • Pembuatan pipeline cukup dengan memuat shader IR lalu memanggil gpuCreatePipeline
  • Tidak perlu root signature, descriptor set, atau definisi binding
  • Konstanta statis (berbasis struct) menggantikan shader specialization constant, sehingga mengurangi masalah ledakan kombinasi PSO
  • Struct konstanta dapat memuat pointer GPU, sehingga alamat runtime bisa di-hardcode secara langsung
Iklan

Penyederhanaan barrier dan sinkronisasi

  • Daftar barrier per resource pada API lama tidak selaras dengan struktur GPU modern
  • Model yang diusulkan hanya memakai flag bitfield pada level queue/stage
  • Disederhanakan menjadi bentuk gpuBarrier(before, after, hazard), tanpa perlu pelacakan resource
  • Perintah gpuSignalAfter / gpuWaitBefore memungkinkan sinkronisasi GPU→GPU yang mirip timeline semaphore

Command buffer dan rendering

  • Hanya memakai command buffer sekali pakai (transient), menghapus model reuse kompleks ala Vulkan
  • gpuBeginRenderPass / gpuEndRenderPass digunakan untuk menetapkan render target dan melakukan clear
  • Tidak ada barrier otomatis antar render pass, sehingga rendering paralel dan optimisasi depth pre-pass dimungkinkan

Penyederhanaan pipeline raster

  • Vertex/pixel shader mengakses data berbasis pointer sehingga binding API dihapus
  • GpuDepthStencilState dan GpuBlendState dipisahkan dari PSO untuk mengurangi jumlah kombinasi
  • GPU mobile mendukung programmable blending lewat framebuffer fetch intrinsic
  • PSO hanya memuat status minimum seperti topologi, format, jumlah sampel, dan sebagainya

Indirect draw dan rendering berbasis GPU

  • Semua argumen (data, arguments) dikirim sebagai pointer GPU
  • Mendukung multi-draw melalui gpuDrawIndexedInstancedIndirectMulti
  • GPU dapat langsung membuat root data dan draw argument, sehingga rendering yang sepenuhnya GPU-driven dapat diwujudkan

Tooling dan kompatibilitas

  • Struktur berbasis pointer dapat ditelusuri lewat informasi simbol seperti pada debugger CUDA/Metal
  • Dilindungi oleh memori virtual sehingga tidak ada masalah keamanan; akses yang salah akan memicu page fault
  • Seperti kasus MoltenVK dan Proton, API DirectX/Vulkan/Metal lama tetap dapat didukung melalui lapisan translasi

Spesifikasi minimum dan kesimpulan

  • Nvidia Turing (2018), AMD RDNA1 (2019), Intel Xe1 (2022), Apple M1 (2020) semuanya mendukung kemampuan yang diusulkan
  • GPU masa kini sudah beralih ke struktur bindless, pointer 64-bit, cache yang konsisten
  • Yang masih tertahan pada abstraksi masa lalu hanyalah API-nya
  • API baru ini lebih sederhana daripada DirectX 11, lebih cepat daripada Vulkan, dan lebih fleksibel daripada Metal
  • Vulkan 2.0 / DirectX 13 generasi berikutnya perlu beralih ke desain yang sepenuhnya bindless dan mendorong perluasan ekosistem lewat bahasa shader berbasis pointer C/C++ alih-alih HLSL/GLSL

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-17
Komentar Hacker News

  • Artikel ini sangat bagus dalam menunjukkan bagian-bagian Vulkan dan DX12 yang tidak perlu
    Saat ini DX12 terasa seperti telantar karena bahkan tidak mendukung pointer buffer, dan Vulkan juga belum dirapikan ke versi 2.0 sehingga banyak driver yang tidak mengimplementasikan fitur ekstensi dengan benar
    Jika API baru seperti ini ada, OpenGL bisa diemulasikan di atasnya dengan jauh lebih cepat, dan hal seperti SDL3 GPU sepertinya juga bisa mendapat peningkatan performa 3–4x

    • Kondisi dokumentasi DirectX saat ini sangat buruk
      Buku Frank Luna pun tidak membahas fitur-fitur terbaru, jadi harus mengubek-ubek situs Learn, sampel GitHub, dan dokumen referensi
      Vulkan juga sama rumitnya, dan bahkan kalau 2.0 keluar pun masih diragukan bagaimana tepatnya itu bisa dipakai di platform penting seperti Android
    • Saya rasa semua ini mungkin disebabkan oleh persyaratan PCI Resizable BAR
      Selain Intel Arc, sebagian besar GPU tetap bisa berjalan tanpa reBAR, tetapi tampaknya Microsoft atau Intel harus memaksakannya di UEFI agar fitur seperti bindless texture bisa digunakan dengan stabil
      Namun, ini juga berarti akan ada batas bawah untuk perangkat keras yang didukung, dan dukungannya di motherboard sebelum 2020 masih tidak konsisten

  • Motivasi inti tulisan ini tidak terlihat
    Menurut indeks blognya, maksudnya adalah bahwa “selama 10 tahun terakhir kompleksitas API grafis dan bahasa shader meningkat tajam, dan sekarang kita perlu menyederhanakan lapisan abstraksi untuk meningkatkan efisiensi pengembangan dan performa, sekaligus bersiap menghadapi beban kerja GPU masa depan”

    • Ini mirip dengan alasan kemunculan NVMe
      Awalnya SSD mendaur ulang antarmuka IDE/SATA, tetapi performa sejati baru bisa dicapai setelah meninggalkan asumsi disk berputar dan membuat metode transfer baru
      Analogi yang dipakai tampaknya adalah bahwa API grafis juga sudah saatnya melepaskan batasan warisan semacam itu

  • Saya mungkin bias karena sudah lama mengikuti pekerjaan Sebastian Aaltonen, tetapi tulisan kali ini benar-benar luar biasa
    Saya rasa arah ke depan adalah kembali ke software rendering
    Bedanya, kali ini algoritme dan struktur datanya mendapat akselerasi perangkat keras
    Tren seperti ini sudah berlangsung di industri VFX, dan contoh sekitar lima tahun lalu adalah saat OTOY mem-porting OctaneRender berbasis CUDA

    • Di dalam GPU ada banyak perangkat keras fixed-function, dan jika itu dibuang performanya akan turun drastis
      Tipe-tipe shader berperan mengisi celah di antara pipeline ini, jadi pendekatan yang sepenuhnya disoftwarkan tidak realistis
    • Sebenarnya perubahan seperti ini sebagian sudah terjadi
      Misalnya, Nanite milik Unreal Engine menggunakan software rasterizer yang berjalan lewat compute shader GPU saat memproses segitiga kecil

  • Detail dalam tulisan ini sangat mengesankan
    Saya hanya memahami sebagian, tetapi rasanya ini akan menjadi referensi untuk perancangan API grafis ke depan
    Bagi kebanyakan gamer, Vulkan/DX12 tidak memberi banyak keuntungan, dan banyak game kesulitan karena masalah PSO
    Vulkan memang sedang membaik, tetapi WebGPU mewarisi batasan dari rancangan Vulkan awal
    Saat perangkat keras berevolusi begitu cepat, mungkin merupakan kesalahan untuk membuat API yang terlalu low-level
    Bisa jadi pendekatan yang berfokus pada komputasi umum seperti CUDA justru arah yang lebih baik

  • Saya jadi merasa rindu pada Mantle
    Memang ada kekurangannya, tetapi terasa seperti benar-benar berurusan langsung dengan perangkat keras, dan masa pengembangan Xbox 360 adalah yang paling menyenangkan

    • API grafis Switch juga sangat bagus dalam cara yang serupa
      Itu dirancang oleh Nvidia dan Nintendo, dan menurut saya merupakan API paling intuitif di antara konsol

  • Setelah membaca tulisan ini, saya merasa seperti sedang menyaksikan momen bersejarah

  • Ini mengingatkan saya pada Google Toucan, yang tampaknya merupakan proyek terkait

  • Tulisan ini membangkitkan banyak kenangan lama
    Beberapa faktor tambahan yang dipertimbangkan para perancang API adalah

    • Virtualisasi GPU — kemampuan agar beberapa aplikasi bisa berbagi resource GPU (misalnya D3D residency API)
    • Perilaku tak terdefinisi (Undefined Behavior) — jika aplikasi tanpa sengaja bergantung pada ini, porting ke API baru akan menjadi sulit

  • Saya penasaran mengapa Microsoft tidak merilis versi DirectX baru
    DirectX Ultimate maupun 12.2 pada dasarnya sama saja dengan DX12
    Apakah pentingnya API sendiri berkurang karena pengaruh middleware seperti Unreal Engine, atau justru EPIC yang perlu mengusulkan API baru?

    • Diskusi seperti ini kebanyakan hanya ramai di komunitas FOSS
      Pengembang game sungguhan membuat RHI (Rendering Hardware Interface) agar bisa fokus pada pengembangan game
      Ray tracing dan mesh shader adalah inovasi terbesar, tetapi pemakaiannya masih sedikit sehingga rasanya perkembangan tidak melangkah lebih jauh
    • Sampai batas tertentu, keduanya benar
      Dengan sentralisasi engine seperti Unreal dan Unity, minat terhadap inovasi API berkurang, dan kemajuan hanya berlanjut di sisi GPU
      API CPU masih sebatas pemetaan buffer yang sederhana
      Seperti saat tessellation shader muncul dulu, sepertinya dibutuhkan perubahan perangkat keras baru agar ada kemajuan

  • Saya penasaran apakah Valve mungkin akan membuat API grafisnya sendiri untuk SteamOS

    • Sebenarnya kompleksitas Vulkan juga sebagian adalah tanggung jawab Valve
      Saya dengar pada tahap awal pengembangan Vulkan, Valve adalah salah satu pendorong utamanya