Dukungan Vulkan 1.3 di M1 dalam Satu Bulan

• Honeykrisp masih belum dirilis untuk pengguna akhir; saat ini hanya source code untuk developer yang tersedia
• Honeykrisp untuk M1 adalah implementasi Vulkan conformant pertama di Apple hardware, dan mengimplementasikan spesifikasi penuh Vulkan 1.3 tanpa waiver portability
• Honeykrisp tidak berbasis pekerjaan Vulkan M1 sebelumnya, melainkan berbasis driver NVK open source untuk GPU NVIDIA; pengembangannya dimulai dengan menambahkan kode M1 dan menghapus bagian terkait NVIDIA
• Hasil akhir Vulkan 1.3 conformance test suite tercatat Pass 686930, Fail 0
• Semua state diperlakukan sebagai dynamic state, serta kode untuk membangun, mengompilasi, dan melakukan cache prolog dan epilog ditambahkan, sehingga diimplementasikan ke arah full dynamic state dan EXT_shader_object
• Untuk zero-copy rendering, EXT_image_drm_format_modifier diimplementasikan
• Untuk kompatibilitas Direct3D, Honeykrisp mendukung EXT_custom_border_color yang dibutuhkan DXVK dan vkd3d-proton; koreksi border colour diemulasikan dengan menyisipkan kode ke shader
• Emulasi custom border colour disebut “simple, correct, and slow”, dan rencananya akan dipercepat nanti dengan driver tricks
• Pekerjaan berikutnya adalah mengimplementasikan item yang dibutuhkan DXVK dan vkd3d-proton untuk pelapisan Direct3D; transform feedback diberikan sebagai contoh

[GN⁺]

Pendapat Hacker News

• Ini pekerjaan yang benar-benar mengesankan, dan sangat menunjukkan nilai dari komponen terbuka yang dibagikan serta terus disempurnakan secara iteratif.
  Saya penasaran berapa lama sampai Proton bisa di-port, tetapi meski implementasi Vulkan-nya optimal, banyak game sepertinya akan berkinerja buruk karena perbedaan arsitektur GPU, overhead translasi ARM, dan biaya Proton itu sendiri.
  Meski begitu, saya optimistis bahwa jika SoC seperti Snapdragon makin umum di desktop, ke depannya akan ada lebih banyak game yang menargetkan memori terpadu dan ARM.

  • Akan cukup ironis jika pengalaman bermain game di Asahi menjadi lebih mudah dan sederhana daripada di macOS.
    Ini menunjukkan betapa besarnya kesalahan Apple selama 10 tahun terakhir karena mengabaikan Vulkan, tetapi sepertinya mereka tidak akan pernah mengakuinya sampai semuanya sudah terlambat.
  • Cukup banyak game yang tidak membutuhkan dxvk berjalan di 60FPS atau lebih. Lihat https://vt.social/@lina/112524118075585601
    Alyssa juga belakangan sedang mengerjakan peningkatan performa FEX.

• Saya penasaran apakah pekerjaan menambahkan Vulkan ke Linux dan menerjemahkan DirectX di Asahi Linux ini akan memengaruhi impian Apple untuk menarik game AAA ke Apple Silicon.
  Apple mungkin ingin para developer AAA mem-porting game ke Metal agar berjalan di iPhone, iPad, Mac, dan Vision Pro dengan satu codebase.
  Mungkin saja gamer Mac pada akhirnya memasang Asahi Linux demi memainkan judul AAA PC.

  • Impian Apple bukanlah agar game AAA hadir di Apple Silicon, melainkan hadir di Apple App Store. Lapisan seperti Proton bisa dibuat seperti GPTK.
    Yang benar-benar mereka inginkan adalah game AAA masuk ke App Store, bukan Steam atau Epic Games Store, dan karena itu saya melihat GPTK sebagai solusi setengah hati, dengan lisensi yang juga mencegah Valve mengintegrasikannya langsung ke Steam.
  • Asahi Linux bisa menjadi Boot Camp baru bagi pengguna Mac yang dulu melakukan dual boot untuk bermain game.
    Saya pernah mencoba Diablo II Resurrected lewat Whiskey di M1, dan cukup mengesankan bahwa game native Windows bisa langsung berjalan seperti itu. Saat ini satu-satunya penghalang hanyalah pembaruan launcher Blizzard yang bodoh yang crash dan mencegah game dijalankan.
    Meski merupakan game DX9 lama, EverQuest II juga berjalan sangat baik di Mac mini M1 pada 1440p, dan Asahi Linux bisa membantu untuk judul 32-bit lama seperti Guild Wars.
  • Kalau Apple benar-benar menginginkan itu, mereka tinggal mengimplementasikan Vulkan.
  • Apple sudah merilis Game Porting Toolkit.

• Kalau belum terlalu mengenal Vulkan 1.3 tetapi tertarik pada pekerjaan API grafis low-level, ini benar-benar layak dilihat. Ini berada di level yang sama sekali berbeda dari Vulkan 1.0 dan mengubah permainan.
  Setelah melewati hambatan awal, bekerja dengannya terasa menyenangkan, dan berkat semua dynamic state serta penghapusan pengaturan render pass di muka, jauh lebih mudah ditangani. Bahkan menjadi lebih mudah daripada OpenGL yang sudah saya pakai selama 20 tahun, dan pemrograman grafis terasa menyenangkan lagi.
  Selama memiliki driver terbaru, sebagian besar fitur bisa dipakai di hampir semua platform desktop dengan GPU dalam kira-kira 10 tahun terakhir.
  Sayangnya belum ada framework dengan “default yang masuk akal” agar bisa langsung mulai, tetapi ada banyak library helper yang berguna untuk berbagai bahasa.

  • Saya sudah sedikit demi sedikit memakai OpenGL selama 20 tahun, dan meski bukan programmer game profesional, saya membuat konten 3D di waktu luang.
    Saya belum sempat pindah ke Vulkan, tetapi sepertinya pada akhirnya tinggal melewati hambatan inisialisasi dan konfigurasi. Setelah itu, rasanya saya tidak akan kembali ke OpenGL.
    Tulisan ini memberi sedikit dorongan dan membuat saya merasa harus benar-benar mencobanya.
  • Apakah ada tutorial atau dokumentasi untuk mulai memakai Vulkan 1.3 secara spesifik? Terakhir kali saya mencari, yang ada hanya materi yang mencampur-adukkan berbagai kombinasi cara lama dan cara baru.
    OpenGL juga memang seperti itu, jadi mungkin tidak terlalu berbeda, tetapi rasanya Khronos benar-benar berhasil membuatnya rumit.

• Saya baru saja memperbarui karena dukungan ES 3.2, dan sudah dibuat takjub. M1 saya terasa seperti dibuat untuk Asahi.
  Sejujurnya, kemungkinan besar macOS hanya pernah boot sekali saat instalasi atau karena tidak sengaja. Senang ada pembaruan sedetail ini.
  Saya penasaran apakah ada browser yang mendukung rendering tanpa salin, atau apakah masih ada beberapa lapisan compositor di antaranya. Saya juga ingat transform feedback WebGL2 sempat terblokir karena memicu readback.

  • Apakah macOS bisa dihapus sepenuhnya? Melihat ini membuat saya mempertimbangkan Mac mini untuk dibawa bepergian.

• Kalau ada sesuatu yang crash, saya selalu berpikir pasti bukan bug compiler, tetapi pada 16 April, ternyata itu memang bug compiler.
  Saya bisa mengatakan dengan yakin bahwa saya belum pernah mengalami hal seperti itu sepanjang karier, tetapi mungkin hal itu tidak terlalu langka ketika tingkat abstraksinya makin rendah.

  • Pasti bukan bug compiler, dan pasti juga bukan bug CPU.
    Kecuali jika Anda developer kernel low-level, maka keduanya bisa saja benar.
    Terlepas dari candaan, pada kenyataannya memang jauh lebih sering bukan itu penyebabnya, tetapi hal seperti itu jelas bisa terjadi.
  • Setidaknya bagian register allocator itu ditulis sendiri, bukan?
    Kalau yang diuji adalah compiler yang masih dalam pengerjaan dan merupakan karya sendiri, pepatah “pasti bukan bug compiler” tidak terlalu berlaku.

• Ada struktur yang tidak biasa di shader: if (condition) { while (true) { } }
condition selalu bernilai false, tetapi compiler tidak mengetahuinya
  Selain sebagai racun yang menyiksa penulis compiler shader yang mematuhi standar, saya penasaran apa tujuan struktur ini

  • Bukankah inti pengujian adalah melempar input beracun semacam ini ke penulis compiler agar compiler tidak rusak apa pun shader yang masuk?
    Kode itu sendiri mungkin tidak terlalu berguna dalam praktik, tetapi jika sebagian shader dalam situasi tertentu secara fungsional bisa disederhanakan menjadi bentuk seperti ini, compiler harus menanganinya dengan benar
  • Tujuan struktur ini bisa jadi memberi tahu compiler bahwa kondisi tersebut selalu false agar optimizer dapat melakukan lebih banyak optimisasi
    Jika konsepnya belum familiar, lihat fitur semacam ini di C++, LLVM, dan Rust:
    https://en.cppreference.com/w/cpp/utility/unreachable
    https://en.cppreference.com/w/cpp/language/attributes/assume
    https://en.cppreference.com/w/cpp/memory/assume_aligned
    https://llvm.org/docs/LangRef.html#unreachable-instruction
    https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
    https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
    https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
    Loop tak hingga pada dasarnya adalah instruksi yang tidak mungkin dicapai, dan instruksi yang tidak mungkin dicapai setelah percabangan pada dasarnya menjadi instruksi assume
  • Apakah ini cara shader melakukan “panic”?
  • Bisa juga merupakan kasus batas dari suatu code generation

• Saya penasaran apakah ini bisa dipakai di dalam VM. Saya mengembangkan di macOS dan umumnya puas, tetapi untuk pengujian saya menjalankan image Ubuntu di VMware
  Karena saya membuat aplikasi grafis 3D, saya tidak begitu tahu sejauh apa passthrough VMware. Saya penasaran apakah GPU Apple Silicon divirtualisasikan di VM, dan apakah menjalankan distribusi ini bisa meningkatkan performa grafis

  • Harus diinstal secara native. Jika ingin performa 3D yang bagus di VM Windows/Linux/macOS di atas macOS, Parallels jauh lebih baik daripada VMware

• Bisa jelaskan hubungan ini dengan MoltenVK? Karena ini driver native, apakah MoltenVK jadi tidak diperlukan?

  • MoltenVK adalah implementasi Vulkan berbasis Metal yang dibuat agar aplikasi Vulkan dapat berjalan di macOS
    Asahi Linux adalah distribusi yang sedang dikembangkan untuk membuat Linux kompatibel dengan prosesor Apple M series, dan tulisan ini membahas membuat Vulkan dengan akselerasi GPU berjalan di Asahi
  • Ini membahas penggunaan Vulkan di Asahi Linux pada hardware M1 Mac. MoltenVK menyediakan Vulkan di atas Metal pada macOS
  • Ini tentang Vulkan di Linux, bukan macOS
  • MoltenVK menerjemahkan Metal menjadi Vulkan. Metal adalah API grafis utama di OS X dan iOS, sedangkan ini adalah implementasi Vulkan native untuk Linux
    Artikelnya juga mengatakan demikian. Ini tidak bisa dijalankan langsung di OS X, jadi tidak menghilangkan kebutuhan akan MoltenVK