Wawancara Frontend: Bagaimana cara memulihkan secara aman setelah WebGPU GPUDevice hilang (lost)?

Prompt dan use case

Aplikasi grafis browser menampilkan canvas hitam setelah resume dari latar belakang, pembaruan driver, atau tekanan resource. Rancang penanganan kehilangan device WebGPU: cara mengamati GPUDevice.lost, membedakan pemusnahan yang disengaja dari kehilangan sementara, membangun kembali device dan setiap resource GPU, serta mencegah alur pemulihan yang bersamaan agar tidak saling menimpa. Cakup juga browser yang tidak didukung, adaptor yang tidak tersedia secara permanen, dan fallback rendering yang halus.

Hal yang diuji oleh pewawancara

Memahami lost sebagai Promise siklus hidup device alih-alih kesalahan render biasa.
Membedakan destroyed dari kehilangan yang disebabkan oleh browser, driver, atau manajemen resource.
Membangun kembali adaptor, device, pipeline, buffer, tekstur, dan bind group.
Merancang pemulihan single-flight, pembatalan frame usang, dan inisialisasi idempoten.
Menangani secure context, Worker, kompatibilitas, dan observabilitas.

Pertanyaan untuk diklarifikasi terlebih dahulu

Apakah aplikasi berupa canvas real-time, editor, atau tugas komputasi offline, dan berapa waktu pemulihan yang dapat diterima?
Apakah scene di sisi CPU, input pengguna, dan pengeditan yang belum di-commit harus tetap bertahan?
Browser, Worker, status daya, dan anggaran memori mana saja yang masuk dalam cakupan?
Apakah kegagalan harus beralih ke WebGL, pratinjau statis, atau prompt muat ulang?

Jawaban tiga puluh detik

Saya memperlakukan device GPU sebagai sesi yang dapat diganti: deskripsi resource dan scene di sisi CPU bersifat otoritatif, sedangkan objek GPU hanyalah cache. Setelah mengamati device.lost, state machine single-flight menjeda pengiriman (submission) dan membaca GPUDeviceLostInfo.reason; destroyed yang disengaja akan mengakhiri sesi, sementara alasan lain memicu adaptor dan device baru, pembangunan kembali resource, serta pemulihan render loop. Kegagalan berulang atau adaptor yang mengembalikan device yang sudah hilang akan masuk ke jalur fallback, dengan mencatat alasan, waktu pemulihan, dan resource yang gagal.

Jawaban mendalam, langkah demi langkah

1. Pisahkan state device dan aplikasi

Simpan scene graph, parameter material, data geometri, dan sumber tekstur di sisi CPU. Device, antrean (queue), buffer, tekstur, pipeline, dan bind group adalah objek sesi GPU yang dapat dibuang, bukan kebenaran bisnis.

2. Amati Promise siklus hidup

GPUDevice.lost tetap dalam status pending selama masa pakai device dan terselesaikan dengan GPUDeviceLostInfo setelah kehilangan terjadi. Daftarkan satu listener setelah inisialisasi dan kirimkan callback ke dalam satu state machine pemulihan.

3. Jelaskan alasan kehilangan

GPUDevice.destroy() eksplisit biasanya sesuai dengan reason destroyed, sehingga tidak boleh memicu restart tanpa syarat. Manajemen resource browser, pembaruan driver, dan gangguan device sementara dapat dipulihkan; adaptor yang dicabut atau dinonaktifkan dayanya mungkin terus mengembalikan device yang sudah hilang.

4. Gunakan gate pemulihan single-flight

Kembalikan Promise yang sama dari titik masuk pemulihan alih-alih membiarkan setiap animation frame melakukan inisialisasi. Jeda pengiriman, buang command encoder lama, dan gunakan token generasi untuk menolak callback asinkron dari device lama.

5. Bangun kembali resource dari deskripsi

Pertahankan penggunaan buffer, ukuran dan format tekstur, sampler, tata letak bind-group, kode sumber shader, dan konfigurasi pipeline. Setelah membuat device baru, bangun kembali sesuai urutan dependensi: shader dan layout, pipeline, buffer dan tekstur, view, bind group, kemudian context canvas dan render loop.

6. Kelola data CPU dan anggaran

Tekstur dan geometri besar dapat berasal dari URL yang dapat dibaca ulang, IndexedDB, atau cache terkompresi. Unggah dalam batch yang sadar akan visibilitas dan prioritas dengan anggaran memori dan sinyal pembatalan, sehingga pemulihan tidak langsung menimbulkan kembali tekanan resource.

7. Tangani konkurensi dan visibilitas

Penyembunyian halaman, pesan Worker, dan percobaan ulang oleh pengguna semuanya dapat meminta pemulihan. Batasi state machine ke ready, lost, recovering, dan degraded; hanya generasi saat ini yang boleh mengirimkan frame. Tunda pembangunan kembali yang mahal saat halaman tersembunyi.

8. Rancang fallback dan observabilitas

Periksa secure context dan navigator.gpu sebelum meminta adaptor dan device. Setelah kegagalan berulang, kehilangan device permanen, atau browser yang tidak didukung, beralihlah ke WebGL, pratinjau statis, atau prompt muat ulang yang jelas. Catat alasan, informasi adaptor, upaya, durasi, resource yang gagal, dan rasio fallback tanpa mengekspos error internal kepada pengguna.

Trade-off dan batasan

Meminta device baru tidak memulihkan buffer, tekstur, atau pipeline lama; semuanya harus dibangun kembali dari deskripsi di sisi CPU. Pemulihan tidak dapat berasumsi bahwa setiap kehilangan bersifat sementara, dan harus menggunakan backoff alih-alih percobaan ulang tanpa batas. WebGPU memerlukan secure context dan ketersediaannya masih terbatas; Worker dapat menggunakan API ini, tetapi perbedaan browser dan driver harus dimasukkan ke dalam matriks rilis.

Rencana peluncuran dan bukti

Bangun manifes resource CPU dan GPU resource factory yang langkah pembuatannya dapat diulang.
Tambahkan generasi dan state pemulihan single-flight ke device, adaptor, context canvas, dan render loop.
Injeksikan kasus pemusnahan yang disengaja, resume latar belakang, reset driver, tekanan memori, dan adaptor yang sudah hilang.
Verifikasi urutan resource, preservasi pengeditan pengguna, jeda frame, dan UI fallback, termasuk Worker.
Gunakan catatan MDN mengenai Promise lost, GPUDeviceLostInfo, secure context, dan ketersediaan terbatas sebagai bukti kompatibilitas.

Kesalahan umum dan tindak lanjut

Kesalahan 1: Hanya memanggil requestDevice lagi

Device baru tidak memiliki resource lama. Bangun kembali pipeline, buffer, tekstur, view, dan bind group dari deskripsi CPU.

Kesalahan 2: Mengulang setiap alasan secara otomatis

Pemusnahan yang disengaja mungkin merupakan shutdown normal; mencoba ulang pada adaptor yang tidak tersedia secara permanen akan menciptakan perulangan tak terbatas. Buat percabangan berdasarkan alasan disertai backoff.

Kesalahan 3: Memulai pemulihan pada setiap animation frame

Alur konkuren akan berlomba pada shared state. Promise single-flight dan generation gate memastikan hanya ada satu sesi aktif saat ini.

Kesalahan 4: Memperlakukan objek GPU sebagai business state

Kehilangan device menghapus sesi GPU. Pastikan scene, input pengguna, dan sumber resource tetap independen dari device.

Kesalahan 5: Mengabaikan jalur tidak didukung dan fallback

WebGPU bukan Baseline dan hanya tersedia dalam secure context. Deteksi sejak dini dan sediakan WebGL, pratinjau statis, atau rencana muat ulang.