- Driver grafis kernel untuk GPU Apple M1/M2, selain memiliki ciri berbasis Rust, juga mencapai kesesuaian dengan OpenGL 4.6 dan Vulkan 1.3, sehingga memperluas cakupan dukungan standar
- Tessellation, inti dari OpenGL 4.0, sulit memenuhi standar hanya dengan kemampuan hardware GPU Apple, sehingga ditangani dengan memindahkan tessellator referensi Microsoft ke OpenCL C dan menjalankannya di GPU
- Dalam demo Vulkan di Mac M2, tessellation berbasis OpenCL mencatat 265fps, jauh lebih cepat dibanding implementasi software-only yang di bawah 1fps, tetapi masih di bawah tessellator hardware yang mencapai 820fps
- Untuk menjalankan game AAA, lingkungan DirectX·Windows·x86·halaman 4KB harus disesuaikan ke Apple Silicon berbasis Linux·Arm64·halaman 16KB, sehingga beberapa layer translasi dan konfigurasi virtual machine digunakan bersama
- Game seperti Portal, The Witcher 3, dan Cyberpunk 2077 benar-benar berhasil dijalankan, tetapi kebutuhan memori dan cakupan dukungan ray tracing masih menjadi batasan penting
Driver GPU Apple yang naik hingga OpenGL 4.6
- Driver grafis kernel untuk GPU Apple M1/M2 ditulis dalam Rust dan mencapai kesesuaian dengan beberapa standar grafis
- Alyssa Rosenzweig memperbarui status driver dan game yang dapat didukung di X.Org Developers Conference 2024
- Materi presentasi dipublikasikan sebagai video YouTube dan slide
- Pada XDC tahun sebelumnya, driver telah mencapai kesesuaian OpenGL ES 3.1, lalu kemudian mencapai kesesuaian hingga OpenGL 4.6
- Tessellation) yang diperlukan untuk OpenGL 4.0 adalah teknik untuk menambah atau mengurangi detail scene secara dinamis
Keterbatasan tessellator hardware GPU Apple
- GPU Apple memiliki tessellator hardware, tetapi tidak memiliki fungsi yang diperlukan untuk implementasi standar OpenGL, sehingga driver tidak bisa langsung menggunakannya apa adanya
- Hardware tampaknya tidak mendukung point mode dan isoline; kedua fitur ini dapat diemulasikan
- Masalah yang lebih besar adalah transform feedback dan geometry shader
- Hardware tidak mendukung keduanya
- Driver mengemulasikannya dengan compute shader
- Perbedaan algoritme tessellation antara tessellator hardware dan emulasi dapat menyebabkan kegagalan invariance, sehingga kombinasi ini harus dihindari
- Apple mendukung OpenGL 4.1 tetapi tidak memiliki kesesuaian, dan fungsi yang tidak didukung hardware digantikan dengan software
- Rosenzweig menyatakan bahwa ia tidak sedang mengimplementasikan Metal, jadi tidak akan mengambil pendekatan seperti itu
Tessellator referensi yang dipindahkan ke OpenCL C
- Driver memanfaatkan tessellator referensi yang dipublikasikan Microsoft lebih dari 10 tahun lalu
- Kode ini awalnya dimaksudkan untuk menunjukkan perilaku yang harus diimplementasikan vendor hardware saat memperkenalkan tessellation
- Berupa sekitar 2000 baris kode C++, dan melakukan tessellation pada satu patch
- Karena 2000 baris C++ tidak bisa dijalankan begitu saja di driver GPU, kode ini dipindahkan ke OpenCL C
- OpenCL C hampir sama dengan C CPU umum, tetapi memiliki batasan dan ekstensi untuk GPU
- Tujuannya bukan memahami kode secara sepenuhnya, melainkan tidak merusak perilakunya selama proses porting
- Tessellator CPU hanya memproses satu patch pada satu waktu, tetapi sebuah scene bisa memiliki 10.000 patch
- Paralelisme masif GPU digunakan agar banyak thread melakukan tessellation
- Alokasi buffer output selama pemrosesan paralel dikelola dengan instruksi atomic GPU
- Output tessellator harus digambar sebagai perintah draw dalam format packed data structure yang dibutuhkan GPU
- Biasanya, dalam kode driver C, hal ini ditangani oleh fungsi yang dihasilkan GenXML tool
- Karena tessellator berbentuk kode C berkat OpenCL, fungsi yang dihasilkan dapat disertakan ke dalam kode yang berjalan di GPU
Performa tessellation
- Tessellation berbasis OpenCL digunakan untuk menjalankan terrain tessellation pada demo Vulkan di Mac M2
- Perbandingan performanya adalah sebagai berikut
- Terrain tessellation software-only: di bawah 1fps
- Tessellation berbasis OpenCL: 265fps
- Angka yang diukur dengan menghubungkan tessellator hardware: 820fps
- Rosenzweig menilai performa pendekatan OpenCL “cukup baik” dan memperkirakan kecil kemungkinan menjadi bottleneck di game nyata
- Performa driver masih memiliki ruang untuk ditingkatkan
Vulkan 1.3 dan Honeykrisp
- Driver GPU Honeykrisp M1/M2 mencapai kesesuaian Vulkan 1.3
- Titik awalnya adalah bentuk yang menyalin NVK Vulkan driver for NVIDIA GPUs dan menggabungkannya dengan driver OpenGL 4.6
- Dalam sekitar satu bulan, driver mulai lulus conformance test suite
- Saat itu adalah 6 bulan sebelum presentasi
- Setelah itu, fitur berikut ditambahkan
- geometry shader
- tessellation shader
- transform feedback
- shader object
- Saat ini driver mendukung semua fitur yang diperlukan oleh berbagai versi DirectX
Layer translasi untuk menjalankan game AAA
- Untuk menjalankan game AAA di lingkungan Apple Silicon, beberapa perbedaan lingkungan harus ditangani sekaligus
- Lingkungan target game: DirectX, Windows, CPU x86, halaman 4KB
- Hardware target sebenarnya: Apple Silicon berbasis Linux, Arm64, halaman 16KB
- Translasi dari DirectX ke Vulkan dan eksekusi dari Windows ke Linux masing-masing ditangani oleh DXVK dan Wine
- Untuk translasi dari x86 ke Arm64, ada opsi yang sudah ada seperti FEX-Emu atau Box64
- Kendala terbesar adalah perbedaan ukuran halaman
- FEX-Emu membutuhkan halaman 4KB
- Box64 memiliki hack yang menggunakan halaman 16KB, tetapi tidak bekerja dengan Wine sehingga tidak membantu di sini
- macOS dapat menggunakan halaman 4KB untuk emulasi x86, tetapi membutuhkan dukungan kernel yang sangat invasif
- Asahi Linux sudah memiliki sekitar 1000 patch menuju kernel mainline, sehingga pendekatan menulis ulang manajer memori Linux tidak masuk akal
Konfigurasi VM dengan kernel guest 4KB
- Linux tidak mendukung ukuran halaman heterogen antarproses yang berbeda, tetapi hal itu dimungkinkan antar-kernel yang berbeda dan ditangani lewat virtualisasi
- Kernel guest KVM dapat memiliki ukuran halaman yang berbeda dari kernel host
- Struktur yang digunakan adalah memasukkan FEX-Emu, Wine, DXVK, Honeykrisp, Steam, dan seluruh game ke dalam virtual machine yang menjalankan kernel guest 4KB
- Overhead CPU diperkirakan rendah berkat virtualisasi hardware, dan beban sebenarnya ada di sisi periferal
- Honeykrisp berjalan di guest melalui virtgpu native contexts, bukan di kernel host
- Pembuatan command buffer GPU akhir dilakukan di guest
- Alih-alih setiap panggilan Vulkan melewati batas virtual machine, command buffer yang sudah selesai diteruskan ke host
- Renderer VirGL di host meneruskannya ke GPU
- Rosenzweig mengatakan pendekatan ini tidak mencapai 100% kecepatan native, tetapi jelas melebihi 90%
- Overhead CPU dan GPU berjalan paralel, sehingga biayanya tidak saling terakumulasi
Game yang benar-benar dijalankan dan status publikasi
- Konfigurasi ini benar-benar menjalankan beberapa game
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- Komponen terkait dipublikasikan pada 10 Oktober, hari presentasi tersebut
- Pengguna Fedora Asahi Remix dapat segera memperbarui untuk menerima komponen tersebut
- Saat presentasi, menjalankan Steam memakan waktu karena virtual machine dan emulasi x86, lalu Control berjalan pada 45fps di sistem M1 MAX
Batasan memori dan ray tracing
- Sebagian game dapat berjalan bahkan di Mac dengan RAM 8GB
- Rosenzweig memainkan Castle Crashers di sistem 8GB selama konferensi
- Portal juga berjalan di sistem 8GB
- Judul game kelas atas kemungkinan besar hanya akan berjalan di sistem 16GB atau lebih
- Rosenzweig berharap kebutuhan resource akan menurun seiring waktu
- Dukungan ray tracing bukan prioritas tinggi
- Control dapat menggunakan fitur tersebut
- Hardware Apple baru mendukung ray tracing mulai M3
- Driver saat ini ditujukan untuk GPU M1 dan M2
- Rosenzweig berencana mulai mengerjakan M3 dalam waktu dekat
1 komentar
Komentar Hacker News
Dedikasi untuk menyelesaikan dukungan M1/M2 sampai tuntas benar-benar patut dihormati
Terlalu banyak proyek yang ditinggalkan begitu mainan ray tracing baru yang mengilap muncul, sementara pekerjaan seperti ini menyakitkan karena hardware yang minim dokumentasi, tetapi sangat memuaskan ketika berhasil berjalan
Saya juga membeli M1 karena proyek ini dan kerja OpenGL+ES dari Alyssa, dan hanya mem-boot Asahi Linux
Perangkat seperti ini dibuat untuk tahan lama, dan dukungan jangka panjang dari Apple sendiri maupun komunitas Linux layak dipuji
Karena open source, besar kemungkinan Apple juga melihatnya, dan tulisan itu juga membahas pekerjaan untuk mengakali fitur-fitur yang tidak ada di chip
Saya sudah coding lebih dari 20 tahun, tetapi momen paling membahagiakan dan paling muram dalam karier saya sama-sama berasal dari proyek hardware yang hanya saya ikuti selama 4 bulan
Cara Alyssa menjalankan semuanya di mesin virtual untuk mengatasi perbedaan ukuran halaman 4KB dan 16KB terasa seperti hack yang cerdik sekaligus potensi bottleneck performa
Saya penasaran apa arti workaround seperti ini dalam jangka panjang
Bukankah kita sudah sampai pada titik ketika kompleksitas menjembatani celah hardware proprietari yang dirancang untuk ekosistem tertutup mulai lebih besar daripada manfaatnya
Control berjalan 45fps di M1 MAX dengan driver open source memang menggembirakan, tetapi saya bertanya-tanya apakah komunitas harus terus menggelontorkan sumber daya besar untuk makin membuka sistem tertutup, atau justru mendorong standar hardware yang lebih terbuka
Apple menciptakan hambatan yang tidak perlu bagi developer melalui ukuran halaman nonstandar dan batasan GPU yang menyulitkan fitur standar seperti tessellation shader, dan ekosistem tertutup seperti ini bukan hanya menyulitkan kontributor open source, tetapi juga menekan inovasi yang akan menguntungkan semua pengguna
Jelas itu menopang model bisnis tertutupnya, dan dalam praktiknya sangat berhasil bagi Apple
Mereka membuat hardware yang hebat, dan meski belakangan software-nya agak kurang stabil, pengguna biasa umumnya mendapat pengalaman yang baik dari kombinasi hardware dan software itu
Jadi, dengan merancang hardware seperti sekarang, Apple bukan sedang memasang “hambatan yang tidak perlu” bagi developer, melainkan sekadar berfokus pada desain hardware yang sesuai kebutuhannya sendiri
Lagi pula, kalau hardware-nya tidak hebat, minat untuk memakainya dengan cara yang tidak dimaksudkan Apple juga tidak akan sebesar ini
Ada perbedaan cukup besar antara mengabaikan standar lalu menciptakan ulang roda yang lebih baik, dan sengaja menyimpang dari standar untuk menghalangi kompatibilitas
Intinya adalah apakah mereka tidak mengeluarkan sumber daya untuk mempertahankan perilaku standar, atau justru aktif mengeluarkan sumber daya untuk menyimpang dari standar; kalau yang pertama, secara pribadi saya tidak menganggap itu patut disalahkan
Di dalam ekosistem ini, yang terutama akan diperhatikan Apple mungkin kompatibilitas aplikasi native dan pengalaman inferensi AI pada tingkat yang sebanding, dan keduanya tampaknya kadang terselesaikan lewat upaya bersama
Di luar itu, mereka lebih suka mengunci sebanyak mungkin, dan sayangnya komunitas cenderung lebih tertarik pada daya tarik keseluruhan dibanding inisiatif terbuka yang baik
Lakukan keduanya saja
Awalnya saya ingin mengatakan bahwa Alyssa, karena bekerja di Valve, seharusnya membantu agar Steam berjalan di Linux pada Mac, tetapi sepertinya memang sudah begitu [1]
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Ini memunculkan pertanyaan yang cukup menarik tentang apa yang direncanakan Valve di sini
Meski sulit, menjalankan Steam/Proton di Mac sangat masuk akal bagi Valve, dan Apple mungkin akan cukup kesal jika orang-orang mem-boot Linux di Mac untuk bermain game
Pekerjaan Alyssa R dan Asahi Lina luar biasa
Namun, jika tidak akrab dengan kode driver, sebagian besar isi ini benar-benar sulit dipahami, dan sisi hardware punya terlalu banyak bagian yang sangat tidak biasa, jadi saya berharap kode seperti ini bisa ditulis dengan jauh lebih mudah
Saya juga cukup menikmati kelucuan old-school seperti kostum penyihir
Saya penasaran apakah ada hardware yang dikenal bisa melakukan ini
Saya sudah mencari, tetapi sulit menemukan hasil yang saya inginkan di antara spam blog terkait PowerPoint, dan AI Google juga tidak membantu
Apakah ada orang lain yang terkejut bahwa begitu banyak hal tidak ada di hardware, dan begitu banyak bagian diemulasi?
Secara praktis, semuanya bisa dianggap emulasi
Salah satu alasan produsen GPU enggan merilis driver mereka sebagai open source juga karena sebagian besar saus rahasianya terjadi di software driver di atas arsitektur komputasi paralel masif tersebut
Geometry shader secara luas dianggap sebagai kesalahan yang seharusnya tidak pernah distandardisasi sejak awal, dan Metal juga tidak pernah mendukungnya sama sekali, sehingga fitur itu hanya mungkin muncul di kode OpenGL lama di macOS; jadi sulit menyalahkan Apple karena tidak mendukungnya di hardware
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa memang luar biasa
Saya ingat tulisan pertamanya tentang pekerjaan GPU, lalu setelah tahu bahwa saat itu dia baru berusia 17 tahun, rasanya kepala saya mau meledak
Fakta bahwa siapa pun bisa melakukan hal seperti itu saja sudah menakjubkan, apalagi kalau yang melakukannya seorang remaja—benar-benar mengejutkan
Kalau membawa OpenGL dan Vulkan terbaru ke Apple Silicon memang tidak mungkin tanpa lapisan emulasi, secara teori bisakah dibuat Metal API native untuk Linux?
Atau apakah Metal sudah terlalu tertanam dalam macOS SDK?
MoltenVK juga sedang mencoba memecahkan masalah yang sama seperti yang disebut Alyssa dalam presentasinya [1, komentar terakhir di isu itu dari Alyssa]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
Itu pada dasarnya kesimpulan dari presentasi Alyssa Rosenzweig
Karena Apple mengetahui dokumentasi internalnya, mereka berada di posisi terbaik untuk membuat implementasi tingkat rendah yang lebih baik
Hambatan utama saat ini adalah sikap keras kepala bahwa porting Metal adalah satu-satunya jalur yang didukung secara resmi
Kalau Valve berhasil mengeluarkan sihir gelap untuk menjalankan game AAA di Mac tanpa dukungan Apple, situasinya akan menarik, dan bisa membuat Apple meninjau ulang pendekatannya jika mereka tidak ingin tersudut di platformnya sendiri
Ada juga implementasi DirectX untuk Linux, dan Proton bekerja dengan cara seperti itu
Namun pertanyaannya adalah apakah API itu dibuat sebagai lapisan di atas Vulkan, ditangani sepenuhnya di sisi klien seperti MoltenVK atau dxvk, atau diintegrasikan lebih dalam ke Mesa
Untuk mulai pertama kali, opsi pertama jelas tampaknya lebih mudah
Saya sudah terlatih untuk berharap artikel dengan judul seperti ini berisi sesuatu seperti “dukungan dihentikan dan mereka di-acqui-hire”
Alyssa Rosenzweig pantas mendapatkan Turing Award
Saya selalu penasaran dengan tautan /SubscriberLink/ seperti ini
Apakah membagikannya tidak etis?
Email pribadi, pesan mailing list proyek, dan tulisan blog semuanya dianggap sesuai, dan mereka menyambut tautan itu dibagikan selama tidak digunakan sebagai cara untuk mengakali upaya mendapatkan pelanggan
Namun mereka dengan sopan meminta agar tidak disebarkan terlalu berlebihan karena mereka harus menjalankan situs serta membayar penulis dan editor, dan sejauh yang saya pahami sumber dananya hanya dari langganan
Biaya langganan LWN cukup terjangkau, dan mendukung liputan teknis mendalam terbaik tentang Linux serta topik terkait
Saya tidak punya hubungan dengan LWN, hanya pelanggan yang puas, dan saya merasa pengetahuan yang saya dapat dari tulisan LWN juga ikut berkontribusi pada keberhasilan karier saya
Agar orang mau berlangganan, mereka harus terlebih dahulu tahu LWN itu ada
Lihat FAQ: https://lwn.net/op/FAQ.lwn#slinks
Paywall LWN unik karena semua konten dibuka gratis setelah satu minggu
Subscriber link ada untuk mendorong orang berlangganan jika mampu
Bisa saja saya keliru, tetapi saya membacanya seolah ada pendanaan agar konten yang sebelumnya berbayar dibuka per artikel
Saya penasaran apakah ada yang tahu apakah memang begitu