Pertanyaan dan konteks
Pertanyaan frontend ini menggabungkan platform peramban dengan rekayasa rilis (release engineering). Aplikasi sudah memiliki jalur WebGL atau CPU dan menginginkan rendering yang lebih cepat di WebGPU sambil menjangkau perangkat yang hanya mengekspos subset API terbatas. Intinya adalah negosiasi kapabilitas dan batasan; mendapatkan adapter tidak berarti setiap shader, format, atau target performa tersedia.
Spesifikasi GPUWeb mendeskripsikan mode kompatibilitas sebagai subset WebGPU terbatas yang ditujukan untuk memetakan ke API grafis lama. Suatu implementasi masih dapat menolak adapter, mengekspos lebih sedikit fitur atau batasan, atau kehilangan perangkat saat runtime. Ketersediaan, kebenaran (correctness), dan performa harus diukur secara terpisah.
Hal yang dievaluasi pewawancara
- Membangun matriks kapabilitas sebelum memilih adapter, fitur, atau batasan.
- Mendefinisikan jalur core, compatibility, WebGL, CPU, dan hasil statis sebagai fallback produk berurutan alih-alih satu nilai Boolean.
- Mengetahui bahwa
GPUDevice.lostadalah sinyal penghentian asinkron dan pemulihan akan membangun kembali sumber daya serta status render. - Merancang peluncuran di perangkat nyata, quality gates, telemetri yang menjaga privasi, dan rollback cepat.
- Memisahkan antara “merender dengan benar,” “memenuhi latensi,” dan “menggunakan daya yang dapat diterima.”
Pertanyaan klarifikasi
- Apakah beban kerja berupa rendering, komputasi umum, atau inferensi dalam peramban? Masing-masing membutuhkan kapabilitas penyimpanan, tekstur, dan presisi yang berbeda.
- Pengalaman apa yang harus dipertahankan oleh perangkat low-end? Ini menentukan jalur minimum WebGL, CPU, atau hasil statis.
- Bolehkah pemuatan pertama menjalankan uji kapabilitas singkat (probe)? Tanpa uji ini, profil perangkat historis bisa usang atau salah.
- Bisakah canvas dan sumber daya diinisialisasi ulang setelah kehilangan perangkat? Jika tidak, status aplikasi memerlukan batas UI yang dapat dipulihkan.
- Apakah peluncuran disegmentasikan berdasarkan peramban, GPU, driver, wilayah, atau pengguna? Segmentasi menentukan bagaimana regresi spesifik driver ditemukan.
Jawaban 30 detik
“Saya akan mendeteksi WebGPU, adapter, fitur, dan batasan, lalu mendefinisikan core, compatibility, WebGL, CPU, atau keluaran statis sebagai tangga kapabilitas eksplisit. Setiap tingkatan hanya membuat shader, pipeline, dan sumber daya yang didukungnya serta memiliki uji kebenaran dan anggaran performa. Saya mendengarkan device.lost dan menggunakan alur pemulihan penerbangan tunggal (single-flight recovery) untuk membangun kembali perangkat, sumber daya, dan status canvas; kegagalan akan mendegradasi fitur dan mencatat alasannya. Peluncuran disegmentasikan berdasarkan peramban, GPU, driver, dan versi aplikasi. Saya memantau inisialisasi, kehilangan perangkat, kesalahan rendering, frame time p95, dan penyelesaian tugas, dengan sakelar mati jarak jauh (remote off switch) yang tidak pernah menghapus jalur lama.”
Solusi langkah demi langkah
Langkah 1: Jadikan deteksi kapabilitas sebagai kontrak
Konfirmasikan secure context dan navigator.gpu, lalu minta adapter. Baca fitur dan batasan yang didukungnya; memeriksa keberadaan objek API saja tidak cukup. Klasifikasikan hasilnya sebagai core, compatibility, WebGL, atau CPU, dan gunakan dimensi kasar peramban, sistem operasi, vendor GPU, driver, dan versi aplikasi untuk telemetri.
Mode kompatibilitas memperluas cakupan perangkat yang dapat menjalankan aplikasi tetapi memiliki batas atas fitur, batasan, dan performa yang lebih konservatif. Tulis persyaratan ketat beban kerja sebagai daftar: format tekstur, tata letak pengikatan (binding layout), ukuran penyimpanan, batas workgroup, dan presisi. Jika satu kapabilitas yang diperlukan tidak ada, pilih tingkatan berikutnya daripada menunggu pembuatan shader gagal.
Langkah 2: Bangun sumber daya untuk tingkatan kapabilitas
Beri setiap tingkatan varian shader, deskripsi pipeline, dan anggaran sumber dayanya sendiri. Mulailah dengan segitiga kecil atau smoke test inferensi kecil, validasi pengiriman perintah dan keluaran, dan baru setelah itu masuk ke scene lengkap. Jangan mengasumsikan bind group atau format tekstur yang dibuat untuk core dapat diterima dalam mode kompatibilitas.
Jika terjadi kegagalan pembuatan sumber daya, catat kesalahan terstruktur dan lepaskan objek tingkatan tersebut. Gambar statis, canvas WebGL, atau hasil CPU harus berbagi model status produk sehingga pengguna dapat menyelesaikan tugasnya. Fallback tidak berarti memiliki frame rate atau presisi yang identik.
Langkah 3: Tangani kehilangan perangkat dan race condition pemulihan
GPUDevice.lost selesai (resolves) ketika masa pakai perangkat berakhir. Masuk ke status pemulihan: hentikan pengiriman pekerjaan baru, batalkan atau tandai frame lama, minta adapter dan perangkat baru, bangun kembali shader, pipeline, buffer, tekstur, dan bind group untuk tingkatan kapabilitas tersebut, lalu lanjutkan render loop. Token generasi atau single-flight promise mencegah dua upaya pemulihan menimpa perangkat baru.
Jika alasan kehilangan menunjukkan tekanan sumber daya atau masalah driver, batasi percobaan ulang dan intervalnya. Kegagalan berulang akan beralih ke WebGL atau CPU dan memberi tahu UI bahwa fitur mengalami penurunan (degraded). Pertanyaan kehilangan perangkat yang umum berfokus pada mekanisme pemulihan; pertanyaan ini berfokus pada matriks kapabilitas kompatibilitas dan kontrol rilis, jadi pisahkan kedua cakupan tersebut.
Langkah 4: Rancang peluncuran bertahap dan rollback
Mulai dengan matriks perangkat internal, lalu perluas berdasarkan versi peramban, vendor GPU, driver, sistem operasi, dan wilayah. Flag harus dapat dinonaktifkan dari jarak jauh, tetapi pengiriman konfigurasi tidak boleh menjadi titik kegagalan tunggal (single point of failure) untuk kebenaran fungsi; klien tetap menyimpan default yang aman.
Lacak kegagalan permintaan adapter, kegagalan pembuatan perangkat, waktu hingga interaksi pertama, frame time p50/p95 atau latensi inferensi, kesalahan shader dan pipeline, tingkat kehilangan perangkat, keberhasilan pemulihan, tingkat fallback, dan penyelesaian tugas. Segmentasi perangkat keras mengungkap regresi driver. Batasi telemetri pada label dan versi perangkat kasar alih-alih fingerprinting lengkap.
Langkah 5: Validasi kebenaran, performa, dan daya
Bandingkan keluaran WebGPU, compatibility, WebGL, dan CPU dengan toleransi untuk piksel, batas geometri, warna tekstur, dan hasil inferensi. Tetapkan scene, resolusi, dan ukuran batch untuk uji performa serta laporkan p50/p95; rata-rata perangkat flagship bukanlah jaminan. Uji laju pengiriman perintah, memori, dan proksi suhu perangkat dalam skenario latar belakang dan baterai lemah.
Tetapkan batasan (gates) per tingkatan: kompatibilitas memerlukan frame rate minimum dan toleransi kesalahan keluaran dari produk, bukan anggaran core. Jika kesalahan, daya, atau waktu pemulihan melewati ambang batas, nonaktifkan tingkatan tersebut, pertahankan keluaran WebGL/CPU, dan kumpulkan detail driver dengan reproduksi minimal.
Pertimbangan desain dan batasan
#### API probe vs profil perangkat
Probe langsung akurat tetapi memakan waktu pada pemuatan pertama; profil perangkat cepat tetapi bisa usang atau mengarah ke fingerprinting. Gunakan probe singkat untuk kapabilitas mutlak dan profil hanya untuk pengurutan serta peluncuran, jangan pernah untuk melewati batasan sebenarnya.
#### Mode kompatibilitas vs WebGL
Mode kompatibilitas mempertahankan lebih banyak model sumber daya dan perintah WebGPU, yang dapat berbagi arsitektur. WebGL mungkin memiliki cakupan matang yang lebih luas, tetapi model shader, sinkronisasi, dan performanya berbeda. Pilih berdasarkan kapabilitas yang diperlukan, biaya migrasi kebenaran, dan tugas pengguna, bukan kebaruan API.
#### Pemulihan otomatis vs fallback langsung
Pemulihan berbatas menangani tekanan sumber daya sementara; percobaan ulang tanpa batas mengubah kegagalan driver menjadi jank dan peningkatan konsumsi daya. Setelah pemulihan gagal atau kehilangan berulang melewati ambang batas, segera beralih dan kirim satu peristiwa diagnostik.
Jawaban model
“Saya akan membagi peluncuran WebGPU menjadi matriks kapabilitas, pembuatan sumber daya, state machine pemulihan, dan kontrol bertahap. Saya memverifikasi secure context, meminta adapter, membaca fitur dan batasan, serta menyusun core, compatibility, WebGL, dan CPU sebagai tangga kapabilitas; setiap tingkatan hanya membuat shader dan sumber daya yang didukung. Setelah device.lost, saya menghentikan pengiriman dan menggunakan token generasi sehingga satu alur pemulihan membangun kembali perangkat dan setiap objek GPU, lalu melakukan fallback jika gagal. Peluncuran disegmentasikan berdasarkan peramban, GPU, driver, dan versi, dengan metrik inisialisasi, frame time, kesalahan, kehilangan, pemulihan, dan penyelesaian tugas ditambah sakelar mati jarak jauh. Mode kompatibilitas memperluas jangkauan, bukan jaminan performa, sehingga kebenaran, latensi, dan daya memiliki gates yang terpisah.”
Kesalahan umum
- Hanya memeriksa
navigator.gpu→ Pembuatan adapter atau perangkat masih bisa gagal, dan fitur atau batasan mungkin tidak mencukupi → Bangun dan verifikasi matriks kapabilitas. - Memperlakukan mode kompatibilitas sebagai core versi low-end → Shader, format, dan batasan mungkin berbeda → Berikan persyaratan dan smoke test tersendiri untuk setiap tingkatan.
- Memanggil fungsi render lagi setelah kehilangan perangkat → Sumber daya milik perangkat yang sudah mati → Bangun kembali setiap sumber daya melalui alur pemulihan single-flight.
- Mencoba ulang pembuatan perangkat tanpa batas → Kerusakan driver menjadi jank dan konsumsi daya berlebih → Batasi percobaan dan interval, lalu lakukan fallback.
- Hanya memantau rata-rata frame rate → Kohor GPU atau driver kecil dapat gagal total → Segmentasikan p95 dan penyelesaian tugas berdasarkan peramban, GPU, dan driver.
Pertanyaan lanjutan dan jawaban
Bagaimana Anda memutuskan apakah beban kerja sesuai dengan batasan mode kompatibilitas?
Tulis persyaratan mutlak untuk fitur, format tekstur, penyimpanan, ukuran workgroup, dan presisi, lalu bandingkan dengan batasan adapter. Masuk ke tingkatan tersebut hanya jika daftar terpenuhi; jika tidak, pilih WebGL, CPU, atau keluaran statis dan catat kapabilitas yang hilang.
Bisakah Anda memuat ulang halaman ketika pengguna sedang mengedit dan perangkat hilang?
Tidak secara default. Simpan status pengeditan di lapisan aplikasi, jeda pekerjaan GPU, dan coba satu pembangunan kembali yang dibatasi. Jika gagal, alihkan renderer sambil mempertahankan status dan jelaskan penurunan visual kepada pengguna. Muat ulang hanya jika migrasi status tidak aman, disertai titik masuk pemulihan.
Suatu kohor driver tiba-tiba mengalami tingkat kehilangan perangkat yang tinggi. Bagaimana Anda melakukan rollback?
Konfirmasikan anomali berdasarkan GPU, driver, peramban, dan versi aplikasi, lalu nonaktifkan peluncuran kompatibilitas untuk kombinasi tersebut sambil membiarkan kohor lain tetap aktif. Periksa inisialisasi, shader, tekanan sumber daya, dan alasan kehilangan; lakukan reproduksi secara minimal dan mulai ulang dari matriks internal setelah diperbaiki.
Bagaimana Anda menunjukkan bahwa fallback WebGL mempertahankan hasil bisnis?
Buat golden set lintas-backend untuk input yang identik, bandingkan toleransi piksel atau keluaran inferensi, dan sertakan kasus kosong, batas, serta beban tinggi. Tetapkan gates terpisah untuk penyelesaian tugas, kebenaran hasil, dan latensi; kesamaan visual tidak membuktikan kesetaraan numerik atau interaksi.