Temu Duga Frontend: Bagaimanakah anda memulihkan keadaan dengan selamat selepas WebGPU GPUDevice hilang (lost)?

Prompt dan kes penggunaan

Aplikasi grafik pelayar memaparkan kanvas hitam selepas resume latar belakang, kemas kini pemacu (driver), atau tekanan sumber. Reka bentuk pengendalian kehilangan peranti WebGPU: cara memerhati GPUDevice.lost, membezakan pemusnahan yang disengajakan daripada kehilangan sementara, membina semula peranti dan setiap sumber GPU, serta menghalang aliran pemulihan serentak daripada menimpa antara satu sama lain. Sertakan juga pelayar yang tidak disokong, penyesuai (adapter) yang tidak tersedia secara kekal, dan sandaran persembahan (rendering fallback) yang lancar.

Perkara yang diuji oleh penemu duga

• Memahami lost sebagai Promise kitaran hayat peranti dan bukannya ralat render biasa.
• Membezakan destroyed daripada kehilangan yang disebabkan oleh pelayar, pemacu, atau pengurusan sumber.
• Membina semula penyesuai, peranti, saluran paip (pipelines), penimbal (buffers), tekstur, dan kumpulan ikat (bind groups).
• Merekabentuk pemulihan penerbangan tunggal (single-flight), pembatalan bingkai lapuk, dan pemulaan idempoten.
• Mengendalikan konteks selamat, Worker, keserasian, dan keterlihatan (observability).

Soalan untuk dijelaskan terlebih dahulu

• Adakah aplikasi ini kanvas masa nyata, editor, atau tugas pengiraan luar talian, dan apakah masa pemulihan yang boleh diterima?
• Adakah babak sebelah CPU, input pengguna, dan suntingan yang belum dilakukan perlu dikekalkan?
• Pelayar, Worker, keadaan kuasa, dan belanjawan memori manakah yang berada dalam skop?
• Patutkah kegagalan beralih kepada WebGL, pratonton statik, atau gesaan muat semula?

Jawapan tiga puluh saat

Saya menganggap peranti GPU sebagai sesi yang boleh diganti: penerangan babak dan sumber sebelah CPU adalah berwibawa, manakala objek GPU adalah cache. Selepas memerhati device.lost, mesin keadaan penerbangan tunggal menjeda penghantaran dan membaca GPUDeviceLostInfo.reason; destroyed yang disengajakan menamatkan sesi, manakala sebab lain mencetuskan penyesuai dan peranti baharu, pembinaan semula sumber, dan pemulihan gelung render. Kegagalan berulang atau penyesuai yang mengembalikan peranti yang telah hilang akan memasuki laluan sandaran, dengan sebab, masa pemulihan, dan sumber yang gagal direkodkan.

Jawapan mendalam, langkah demi langkah

1. Asingkan keadaan peranti dan aplikasi

Kekalkan graf babak, parameter bahan, data geometri, dan sumber tekstur pada bahagian CPU. Peranti, baris gilir, penimbal, tekstur, saluran paip, dan kumpulan ikat adalah objek sesi GPU yang boleh dilupuskan, bukan kebenaran perniagaan.

2. Perhatikan Promise kitaran hayat

GPUDevice.lost kekal tergantung (pending) sepanjang jangka hayat peranti dan diselesaikan dengan GPUDeviceLostInfo selepas kehilangan berlaku. Daftarkan satu pendengar selepas permulaan dan hantar panggilan balik (callback) ke dalam satu mesin keadaan pemulihan.

3. Jelaskan sebab kehilangan

GPUDevice.destroy() yang jelas biasanya sepadan dengan reason destroyed, jadi ia tidak sepatutnya mencetuskan mula semula tanpa syarat. Pengurusan sumber pelayar, kemas kini pemacu, dan kerosakan peranti sementara mungkin pulih; penyesuai yang dicabut atau dilumpuhkan kuasanya mungkin terus mengembalikan peranti yang telah hilang.

4. Gunakan pintu pemulihan penerbangan tunggal (single-flight recovery gate)

Kembalikan Promise yang sama daripada titik masuk pemulihan dan bukannya membiarkan setiap bingkai animasi dimulakan. Jeda penghantaran, buang pengekod arahan lama, dan gunakan token generasi untuk menolak panggilan balik tak segerak daripada peranti lama.

5. Bina semula sumber daripada penerangan

Kekalkan penggunaan penimbal, saiz dan format tekstur, pensampel, reka letak kumpulan ikat, kod sumber pembayang (shader), dan konfigurasi saluran paip. Selepas mencipta peranti baharu, bina semula mengikut urutan pergantungan: pembayang dan reka letak, saluran paip, penimbal dan tekstur, paparan, kumpulan ikat, kemudian konteks kanvas dan gelung render.

6. Urus data dan belanjawan CPU

Tekstur dan geometri yang besar boleh datang daripada URL yang boleh dibaca semula, IndexedDB, atau cache termampat. Muat naik dalam kelompok yang peka keterlihatan dan keutamaan dengan belanjawan memori dan isyarat pembatalan, supaya pemulihan tidak segera mencipta semula tekanan sumber.

7. Kendalikan keserentakan dan keterlihatan

Penyembunyian halaman, mesej Worker, dan percubaan semula pengguna semuanya boleh meminta pemulihan. Hadkan mesin keadaan kepada ready, lost, recovering, dan degraded; hanya generasi semasa dibenarkan menghantar bingkai. Tangguhkan pembinaan semula yang mahal semasa halaman disembunyikan.

8. Reka bentuk sandaran dan keterlihatan

Semak konteks selamat dan navigator.gpu sebelum meminta penyesuai dan peranti. Selepas kegagalan berulang, kehilangan peranti kekal, atau pelayar yang tidak disokong, beralih kepada WebGL, pratonton statik, atau gesaan muat semula yang jelas. Rekodkan sebab, maklumat penyesuai, percubaan, tempoh, sumber yang gagal, dan nisbah sandaran tanpa mendedahkan ralat dalaman kepada pengguna.

Pertukaran dan sempadan

Meminta peranti baharu tidak memulihkan penimbal, tekstur, atau saluran paip lama; ia mesti dibina semula daripada penerangan sebelah CPU. Pemulihan tidak boleh menganggap setiap kehilangan adalah sementara, dan ia mesti menggunakan pengunduran (backoff) dan bukannya percubaan semula tanpa henti. WebGPU memerlukan konteks selamat dan kekal dengan ketersediaan terhad; Worker boleh menggunakan API ini, tetapi perbezaan pelayar dan pemacu tergolong dalam matriks keluaran.

Pelan pelancaran dan bukti

1. Bina manifes sumber CPU dan kilang sumber GPU yang langkah penciptaannya boleh diulang.
2. Tambahkan generasi dan keadaan pemulihan penerbangan tunggal pada peranti, penyesuai, konteks kanvas, dan gelung render.
3. Suntik kes pemusnahan yang disengajakan, resume latar belakang, set semula pemacu, tekanan memori, dan penyesuai yang telah hilang.
4. Sahkan urutan sumber, pengekalan suntingan pengguna, jeda bingkai, dan UI sandaran, termasuk Worker.
5. Gunakan catatan MDN mengenai Promise lost, GPUDeviceLostInfo, konteks selamat, dan ketersediaan terhad sebagai bukti keserasian.

Kesilapan biasa dan tindakan susulan

Kesilapan 1: Hanya memanggil requestDevice sekali lagi

Peranti baharu tidak mempunyai sumber lama. Bina semula saluran paip, penimbal, tekstur, paparan, dan kumpulan ikat daripada penerangan CPU.

Kesilapan 2: Mencuba semula setiap sebab secara automatik

Pemusnahan yang disengajakan mungkin merupakan penutupan biasa; mencuba semula penyesuai yang tidak tersedia secara kekal akan mewujudkan gelung tak terhingga. Cabangkan mengikut sebab dengan pengunduran (backoff).

Kesilapan 3: Memulakan pemulihan pada setiap bingkai animasi

Aliran serentak bersaing pada keadaan kongsi. Promise penerbangan tunggal dan pintu generasi memastikan hanya satu sesi semasa sahaja wujud.

Kesilapan 4: Menganggap objek GPU sebagai keadaan perniagaan

Kehilangan peranti membersihkan sesi GPU. Pastikan babak, input pengguna, dan sumber rujukan kekal bebas daripada peranti.

Kesilapan 5: Mengabaikan laluan tidak disokong dan sandaran

WebGPU bukan Baseline dan hanya tersedia dalam konteks selamat. Kesan lebih awal dan sediakan WebGL, pratonton statik, atau pelan muat semula.