API GPU Baru SDL3 Telah Dimerge

 (github.com/libsdl-org)
1 poin oleh GN⁺ 2024-08-31 | 1 komentar | Bagikan ke WhatsApp
  • PR #9312 untuk GPU API baru SDL3 dimerge pada 29 Agustus 2024, dan prosesnya berjalan dengan cepat mengajukan pendekatan berbasis Refresh agar mendapat lebih banyak review menjelang SDL 3.0
  • Proposalnya menjadikan Refresh, komponen grafis dari MoonWorks, sebagai kandidat API final untuk SDL_gpu; mendukung Vulkan dan API grafis PS5, sementara dukungan D3D11 deferred context sedang dikerjakan
  • Desain API memakai model rendering modern yang membagi pekerjaan menjadi render pass, compute pass, dan copy pass, serta operasi penulisan resource disusun agar dapat di-cycle secara internal untuk menghindari dependensi antar-frame
  • Di sisi shader, proposal awal yang berfokus pada kompilasi offline disesuaikan ke arah validasi dukungan pembuatan shader saat runtime, dan dibahas struktur yang menerima format IR per backend agar SDL sendiri tidak membungkus shader compiler
  • Segera setelah merge, berlanjut penyesuaian seperti nama fungsi API, macro konfigurasi build, UTF-8 BOM, dan batas 60 FPS pada swapchain D3D12; hak commit juga ditambahkan untuk thatcosmonaut

Titik awal PR dan status merge

  • PR #9312 dimulai sebagai proposal GPU API baru untuk mempercepat review atas SDL_gpu
    • Tujuannya adalah segera mendapatkan “lebih banyak pasang mata” menjelang SDL 3.0
    • Dimerge setelah konfirmasi It's merged pada 29 Agustus 2024
  • Segera setelah merge, ada permintaan untuk sementara menahan perubahan sambil melakukan review dan penyesuaian
    • Setelah itu statusnya menjadi everything is merged, dan ada arahan bahwa perubahan di sisi GPU boleh dimerge lagi
    • thatcosmonaut ditambahkan ke hak commit karena kemungkinan besar akan mereview incoming changes

Kandidat API berbasis Refresh

  • Inti proposalnya adalah menjadikan Refresh, komponen grafis dari MoonWorks, sebagai kandidat API final untuk SDL_gpu
    • MoonWorks diperkenalkan sebagai proyek yang lebih mirip penerus XNA, bukan reimplementasi XNA seperti FNA
    • Refresh mirip dengan FNA3D, tetapi menargetkan API modern seperti Vulkan
  • Saat itu Refresh mendukung Vulkan dan API grafis PS5
    • Dukungan D3D11 deferred context sedang dikerjakan
    • Disebut sudah digunakan di produksi untuk Samurai Gunn 2 di PC dan konsol
  • Penulis PR menyebut thatcosmonaut sebagai kontak utama, dan FNA core team juga direncanakan terlibat dalam prosesnya

Desain API dan penanganan resource

  • API disusun sebagai API rendering modern yang berpusat pada deferred context
    • Pekerjaan dibagi menjadi render pass, compute pass, dan copy pass
    • Bagian API lainnya dijelaskan sebagai bentuk standar yang mendekati pemanggilan binding, render, dan compute dispatch
  • Semua operasi penulisan ke resource dapat menghindari dependensi antar-frame melalui cycle
    • Handle resource grafis seperti GpuBuffers berperan sebagai container untuk melakukan cycle terhadap referensi resource internal
    • Belakangan, konsep cycle disederhanakan menjadi bool, dan beberapa enum WriteOptions dihapus
  • Awalnya ada beberapa enum WriteOptions karena masalah perilaku API data terkait driver AMD D3D11
    • Dijelaskan bahwa perilaku API data D3D11 yang tidak berjalan sesuai harapan di AMD tidak dapat sepenuhnya diakali
    • Belakangan bagian ini disederhanakan dan cara kerjanya didokumentasikan di kode

Diskusi sistem shader

  • Solusi shader awalnya adalah skrip bernama shaderbuild.py
    • Berperan sebagai front-end untuk tool build shader offline di mesin klien
    • Strukturnya menggabungkan beberapa format lalu meneruskannya sesuai tiap backend render
  • Pendekatan ini dijelaskan sebagai desain yang tidak menghalangi kompilasi shader online
    • Ada penjelasan bahwa source SDLSL di masa depan dapat disertakan dalam binary dan langsung dikonversi di CreateShaderModule menjadi bytecode backend yang dibutuhkan
    • Keunggulannya adalah memungkinkan kompilasi online tanpa merusak API publik
  • Dalam masukan eksternal, muncul kekhawatiran bahwa kompilasi murni offline tidak cocok untuk engine tertentu
    • Ada catatan bahwa kewajiban memasang Python, glslc, dan spirv-cross di PATH bisa merepotkan developer
    • Ada juga pendapat bahwa di ekosistem SDL, tool kompilasi shader offline berbentuk satellite library terpisah mungkin lebih alami
  • Setelah itu, sistem shader disesuaikan ke arah pembedaan shader “raw” dan “portable”
    • Port FNA3D digunakan sebagai stress test untuk dukungan pembuatan shader saat runtime
    • Disebutkan konfigurasi yang menggunakan MojoShader SPIR-V emitter untuk diteruskan langsung di Vulkan, dan pada backend lain dikonversi lewat SDL_shader, library terpisah opsional
    • Targetnya adalah struktur di mana SDL sendiri tidak perlu tahu atau peduli dari mana shader berasal

Backend dan progres pengujian

  • Implementasi awal berbasis Refresh dinilai kuat karena backend Vulkan sudah tersedia
    • Ada pendapat bahwa backend Vulkan memiliki performa tinggi berdasarkan Refresh 2.0
    • Fakta bahwa compute adalah fitur kelas satu juga disebut sebagai perbedaan penting dibanding draf SDL_GPU sebelumnya
  • Dari akhir Maret hingga awal April 2024, beberapa contoh game nyata yang berjalan dibagikan
    • Dijelaskan bahwa statusnya sudah dapat berjalan tanpa kompilasi shader offline
    • Revisi terkini yang dapat mem-boot Streets of Rage 4 dibagikan
    • Wizorb berjalan di Metal
    • Celeste masuk ke status in-game pada sebagian besar trace database
  • Penambahan fitur juga berjalan bersamaan
    • Disebutkan bahwa dukungan hardware instancing akan ditambahkan pada push berikutnya
    • Setelah itu instancing dan occlusion queries masuk, dan dibagikan status bahwa implementasi sisi Metal masih perlu dilengkapi

Isu build, API, dan platform yang muncul dalam review

  • Karena urutan include Vulkan, terjadi error redefinisi typedef VkInstance dan VkSurfaceKHR
    • Diusulkan perbaikan untuk mengubah urutan include header Vulkan dan SDL_vulkan.h di SDL_gpu_vulkan.c
    • Juga diusulkan perbaikan untuk meredam peringatan bahwa suitableQueueFamilyIndex mungkin belum diinisialisasi dengan melakukan inisialisasi ke 0
  • Kebutuhan pembaruan dynapi juga disampaikan
    • Ada arahan bahwa menjalankan gendynapi.py di bawah src/dynapi/ akan memperbaruinya
    • Ada caveat bahwa saat dijalankan akan muncul banyak peringatan dokumentasi yang hilang
  • Ada usulan untuk mengganti tipe byte size pada signature fungsi API menjadi size_t, tetapi kesimpulannya adalah tetap memakai Uint32 untuk GPU API
    • Ada pendapat bahwa ketika ukuran buffer menjadi sangat besar, kompatibilitas serentak 32/64-bit bisa menjadi sulit
    • Kemungkinan Uint64 disebut sebagai alternatif, tetapi pada akhirnya disampaikan pendapat untuk tetap mempertahankan Uint32

Penyesuaian lanjutan setelah merge

  • Setelah merge, beberapa tweak dilakukan di #10622
    • Ada arahan bahwa nama fungsi baru akan dimerge terlebih dahulu agar dapat diterima oleh pengguna beta
    • Masalah di konfigurasi build yang mengharuskan macro kanan seperti SDL_GPU_VULKAN SDL_VIDEO_VULKAN dan SDL_GPU_METAL SDL_VIDEO_METAL sudah terdefinisi diperbaiki di #10622
    • Masalah UTF-8 BOM pada file source GPU juga diperbaiki di #10622
  • Di sisi D3D12, terkonfirmasi bahwa D3D12_ClaimWindow() mengatur swapchain ke VSYNC sehingga testsprite dibatasi ke 60 FPS
    • Dijelaskan bahwa workflow yang dimaksud adalah membuat swapchain dengan parameter yang didukung umum, yaitu SDR dan VSYNC, pada tahap claim window, lalu setelah menanyakan dukungan, memanggil SetSwapchainParameters
    • Meski render driver sudah memanggil SetSwapchainParameters setelah claim, batas 60 FPS masih tersisa di driver D3D12 sehingga menjadi target investigasi

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-31
Opini Hacker News

  • SDL3 masih dalam tahap pratinjau, tetapi GPU API baru sudah digabungkan ke branch utama dan para maintainer SDL3 sedang melakukan penyesuaian akhir
    Sejauh yang saya pahami, inti dari GPU API baru ini adalah memungkinkan kode grafis dan shader ditulis sekali lalu berjalan di berbagai platform, termasuk konsol, tanpa banyak kerepotan. Sebelumnya, hal seperti ini membutuhkan Unity atau Unreal, atau solusi kustom sendiri
    WebGPU/WGSL juga merupakan stack grafis lintas platform yang serupa, tetapi setahu saya belum ada yang membuat backend konsol. Sebaliknya, SDL3 GPU API tampaknya saat ini belum mendukung WebGPU sebagai backend

    • Unreal/Unity bukan satu-satunya solusi. Ada bgfx(https://github.com/bkaradzic/bgfx) yang cukup populer, dan setahu saya juga ada sokol gfx(https://github.com/floooh/sokol). Tentu masih ada banyak lagi yang kurang dikenal
    • Dulu saya pernah mengintegrasikan bgfx [1], yang memungkinkan kode grafis dan shader ditulis sekali serta mendukung konsol, dengan stack SDL2 dan Swift [2]. Bahkan sebagai orang yang belum pernah memakai alat seperti ini, pengalamannya cukup baik
      Saya menantikan SDL3 karena ia memperkenalkan abstraksi konsol sehingga GPU API tidak membutuhkan dependensi tambahan. Selain itu, Godot mendukung Steam Deck secara resmi, dan saya berharap ke depannya lebih banyak konsol juga didukung. Terkait hal ini, Miguel de Icaza sedang mendorong adopsi Swift di Godot, dan juga mengerjakan port editor ke SwiftUI di iPad. Perkembangannya [3] menarik
      [1] https://bkaradzic.github.io/bgfx/overview.html
      [2] https://github.com/bgbernovici/myndsmith
      [3] https://blog.la-terminal.net/xogot-code-editing/
    • Perlu juga dicatat bahwa Godot memiliki shader lintas platform. Bahasa GDShader sangat berbasis pada bahasa shader OpenGL, tetapi bukan salinan 1:1, dan dikompilasi sesuai platform target. Namun untuk PS5 dan Xbox harus bekerja sama dengan pihak ketiga. Ada juga orang yang memublikasikan build Nintendo untuk mereka yang telah menandatangani NDA Nintendo
    • Tapi mengapa SDL API lebih diperlukan daripada gfx-rs / wgpu? Saya penasaran apakah memang perlu membuat satu lagi yang baru

  • Konteks tambahan ada di sini: https://icculus.org/finger/flibitijibibo?date=2024-06-15&time=13-14-16

  • Saya penasaran bagaimana arah ini akan berkembang. Pada akhirnya, akan bagus jika ada lebih banyak pilihan untuk membuat game engine dan aplikasi kustom
    Belakangan ini saya mendalami Vulkan, dan meski mempelajarinya menyenangkan serta memberi banyak pencerahan, sifat Vulkan membuat progres terasa lambat. Kalau SDL3 sudah ada saat saya mulai, mungkin saya akan dengan senang hati memilihnya, dan hasil yang bisa ditunjukkan dibanding waktu yang diinvestasikan mungkin akan lebih banyak

  • Apakah API ini benar-benar layak dipakai baru akan terlihat seiring waktu. Terutama sinkronisasi resource dan cara penggantian nama objek akan menjadi kuncinya
    Apakah performanya akan lebih baik daripada WebGPU atau abstraksi lain juga masih harus dilihat. Perlu juga diperhatikan apakah ia tetap bisa kecil saat harus mengakali bug driver
    Saya juga skeptis terhadap bytecode baru untuk bahasa shading. Di WebGPU, parsing shader saat runtime bukanlah kekhawatiran dan sangat cepat. Pembuatan shader native juga cepat [1]. Yang lambat adalah pembuatan pipeline, dan bytecode ini tidak membantu bagian itu
    [1] http://kvark.github.io/naga/shader/2022/02/17/shader-translation-benchmark.html

  • Saya penasaran bagaimana mereka bisa melakukannya secepat ini. WebGPU native punya masa pengembangan yang panjang dan bahkan masih belum difinalisasi, sementara SDL GPU API mendukung lebih banyak platform, jadi rasanya justru akan memakan waktu lebih lama

    • Alasan WebGPU memakan waktu lama adalah karena mereka memutuskan membuat bahasa shading sendiri alih-alih memakai SPIR-V. SDL tidak melakukan kesalahan itu, dan menyerahkan compiler shader serta alat konversi kepada pengguna
      Ada proyek saudara [1] untuk bahasa shading lintas platform dan proyek lain [2] untuk mengonversi bahasa-bahasa yang sudah ada satu sama lain, tetapi proyek-proyek itu akan selesai ketika memang selesai, dan bagian API lainnya tidak perlu menunggu itu
      WebGPU adalah hasil kerja komite yang terdiri dari vendor dan para ahli bahasa, atau ahli standar, yang dibuat di tengah politik dan birokrasi, dan itu terlihat. SDL_GPU dibuat oleh para pengembang game yang mengutamakan kepraktisan di atas segalanya, sehingga kadang diremehkan dari menara gading
      [1]: https://github.com/libsdl-org/SDL_shader_tools
      [2]: https://github.com/flibitijibibo/SDL_gpu_shadercross
    • Para kontributor inti proyek SDL3 GPU punya pengalaman menangani dua lapisan abstraksi GPU lintas platform, FNA3D dan Refresh, yaitu lapisan yang menargetkan PC maupun konsol. Pengetahuan itu dan kode open source yang sudah ada menjadi pijakan sehingga mereka bisa merakitnya dengan cepat sekaligus berkualitas
    • Karena tidak ada komite, dan ada para pengembang termotivasi yang membutuhkan hasilnya untuk proyek mereka sendiri. Terutama orang-orang dari pihak FNA
    • Sederhana. SDL GPU menghilangkan bagian lain dari burung hantunya, yaitu bagian yang mengonversi shader dalam format umum menjadi representasi menengah khusus API

  • Senang bisa berkontribusi pada bagian dx12 :)

    • Bagus. Karena saya berencana menargetkan HLSL modern, sepertinya pada awalnya saya akan memakai backend itu. Semoga DXC menghasilkan SPIR-V yang bagus pada akhirnya
    • Ada rekomendasi materi untuk belajar DX12?

  • Mungkin saya akan mencobanya. Selama ini saya merasa SDL adalah perangkat lunak berkualitas. Cepat dikompilasi, mudah dikompilasi di berbagai platform, dan selalu berjalan dengan baik. Jadi saya juga menaruh harapan pada API baru ini

  • Secara umum saya penggemar berat SDL
    Ketika mencari library game lintas platform, SDL dan API-nya terasa punya keseimbangan yang tepat. Yang saya inginkan hanyalah library C/C++ yang bisa dipanggil untuk membuat window dan konteks grafis, serta framework rendering sprite yang cepat. Saya tidak butuh IDE lengkap atau library yang gemuk, dan juga tidak ingin belajar bahasa baru

  • SDL3 terasa seperti mengalami second-system effect. SDL2 lebih mirip SDL1 dengan handle window eksplisit, jadi SDL3 adalah sistem kedua, bukan ketiga. SDL1/2 adalah lapisan tipis yang membungkus boilerplate spesifik platform untuk membuka window dan menangani event input, sehingga kita bisa cepat masuk ke kode rendering OpenGL yang memang ingin ditulis

    • Kalau hanya perlu mendukung Windows/Linux/Android, bisa saja berargumen bahwa SDL GPU API terlalu gemuk dan tidak perlu
      Namun jika ingin mendukung sistem operasi Apple juga, Anda terikat pada OpenGL 4.1. Apple sudah menandainya secara resmi sebagai akan ditinggalkan 5 tahun lalu, jadi fitur GPU modern seperti compute shader tidak bisa dipakai
      Bisa juga mengambil jalur Vulkan dan memakai MoltenVK di sistem Apple, tetapi kompleksitas Vulkan naik cukup banyak dibanding OpenGL. Seperti yang sering dikatakan orang, levelnya “1000 baris kode untuk satu segitiga”. Tujuan GPU API SDL3 adalah memberi alternatif yang lebih mudah diakses tetapi tetap cukup fleksibel
      Konsol mungkin ceritanya mirip
      Katanya banyak orang meminta, “Bisakah dibuat sesuatu seperti SDL_render tetapi ditambah dukungan shader yang berjalan di semua platform,” dan itulah titik awalnya
      SDL3 juga menambahkan API audio yang lebih tinggi levelnya, tetapi saya kurang tahu kelebihannya
    • SDL2 tidak sekadar “SDL1 dengan handle window eksplisit”. Ada berbagai perubahan dan fitur baru di seluruh API, dan seperti SDL3, ada perubahan besar juga pada subsistem grafis. SDL1 memakai software rendering, sementara SDL2 menambahkan akselerasi hardware
      Selain itu SDL2 berkembang cukup jauh setelah 2.0.0, dan SDL3 melanjutkan evolusi itu sambil mengizinkan perubahan yang memutus kompatibilitas API. SDL3 bukan ditulis ulang dari nol, dan dari sudut pandang pengguna SDL, saya rasa pindah dari SDL2 ke SDL3 tidak akan terlalu sulit
      Dan SDL1/2 juga tidak pernah “hanya tipis” sampai tidak punya sistem grafis tingkat tinggi sendiri. Berguna jika pengguna baru atau pengguna dasar bisa langsung menampilkan sesuatu di layar dengan fitur bawaan
      Seperti yang disorot ahefner, SDL1 memang cukup “tipis” menurut standar modern, tetapi tetap menyediakan cukup fasilitas untuk menggambar hal-hal dasar di layar tanpa menulis matematika piksel sendiri, dan pada tahun 90-an itu cukup membantu
    • Masalahnya adalah OpenGL pada dasarnya sudah mati, dan Vulkan adalah pengganti yang poor dari sisi kemudahan penggunaan dibanding OpenGL
    • Render API pun sudah merupakan kegemukan yang tidak perlu bagi banyak pengguna SDL. Dari sisi ukuran biner, SDL2 juga sudah jauh lebih besar daripada SDL1
      Meski begitu, abstraksi ini mungkin bisa memenuhi kebutuhan di luar game 2D sederhana, sekaligus memungkinkan target ke ekosistem API grafis yang sayangnya makin terfragmentasi. Impian masa depan OpenGL(Next) yang universal sudah hilang. Namun bagian tersulitnya, yaitu konversi shader, tampaknya masih belum ada

  • Saya belum pernah memakai library ini, tetapi jika pemahaman saya dari thread yang ditautkan benar, sekarang saya ingin melihat contoh fitur GPU compute lintas platform yang disediakan. Saya penasaran apakah ada rekomendasi harus mulai dari mana