Prompt dan konteks
Soalan frontend ini menggabungkan platform pelayar dengan kejuruteraan pelepasan (release engineering). Aplikasi sudah mempunyai laluan WebGL atau CPU dan inginkan rendering yang lebih pantas pada WebGPU sambil menjangkau peranti yang hanya mendedahkan subset API terhad. Terasnya adalah perundingan keupayaan dan had; memperoleh penyesuai tidak bermakna setiap shader, format, atau sasaran prestasi tersedia.
Spesifikasi GPUWeb menerangkan mod keserasian sebagai subset WebGPU terhad yang bertujuan untuk dipetakan ke API grafik yang lebih lama. Sesuatu pelaksanaan masih boleh menolak penyesuai, mendedahkan lebih sedikit ciri atau had, atau kehilangan peranti semasa waktu jalan (runtime). Ketersediaan, ketepatan, dan prestasi mesti diukur secara berasingan.
Perkara yang dinilai oleh penemu duga
- Membina matriks keupayaan sebelum memilih penyesuai, ciri, atau had.
- Menentukan laluan core, compatibility, WebGL, CPU, dan hasil statik sebagai sandaran produk yang tersusun dan bukannya satu nilai Boolean.
- Mengetahui bahawa
GPUDevice.lostialah isyarat penamatan tak segerak dan pemulihan membina semula sumber dan keadaan render. - Mereka bentuk pelancaran peranti sebenar, get kualiti (quality gates), telemetri yang mementingkan privasi, dan rollback yang pantas.
- Memisahkan antara “merender dengan betul,” “memenuhi kependaman,” dan “menggunakan kuasa yang boleh diterima.”
Soalan penjelasan
- Adakah beban kerja itu rendering, pengiraan umum, atau inferens dalam pelayar? Setiap satu memerlukan keupayaan storan, tekstur, dan kejituan yang berbeza.
- Apakah pengalaman yang mesti dikekalkan oleh peranti kelas rendah (low-end)? Ini menetapkan laluan minimum WebGL, CPU, atau hasil statik.
- Bolehkah pemuatan pertama menjalankan kuar (probe) keupayaan ringkas? Tanpanya, profil peranti sejarah mungkin lapuk atau salah.
- Bolehkah canvas dan sumber dimulakan semula selepas kehilangan peranti? Jika tidak, keadaan aplikasi memerlukan sempadan UI yang boleh dipulihkan.
- Adakah pelancaran disegmentasikan mengikut pelayar, GPU, pemacu (driver), rantau, atau pengguna? Segmentasi menentukan cara regresi khusus pemacu dikesan.
Jawapan 30 saat
“Saya akan mengesan WebGPU, penyesuai, ciri, dan had, kemudian menentukan core, compatibility, WebGL, CPU, atau output statik sebagai tangga keupayaan yang eksplisit. Setiap anak tangga hanya mencipta shader, talian paip (pipelines), dan sumber yang disokongnya serta mempunyai ujian ketepatan dan belanjawan prestasi. Saya mendengar device.lost dan menggunakan aliran pemulihan penerbangan tunggal (single-flight) untuk membina semula peranti, sumber, dan keadaan canvas; kegagalan akan menurunkan gred dan merekodkan sebab. Pelancaran disegmentasikan mengikut pelayar, GPU, pemacu, dan versi aplikasi. Saya memantau pemulaan, kehilangan peranti, ralat rendering, masa bingkai p95, dan penyiapan tugas, dengan suis tutup jauh yang tidak pernah membuang laluan lama.”
Penyelesaian langkah demi langkah
Langkah 1: Jadikan pengesanan keupayaan sebagai kontrak
Sahkan konteks selamat dan navigator.gpu, kemudian minta penyesuai. Baca ciri dan had yang disokongnya; menyemak bahawa objek API wujud tidak mencukupi. Kelaskan hasilnya sebagai core, compatibility, WebGL, atau CPU, dan gunakan dimensi kasar pelayar, sistem pengendalian, vendor GPU, pemacu, dan versi aplikasi untuk telemetri.
Mod keserasian memperluaskan set peranti yang boleh dijalankan tetapi mempunyai siling ciri, had, dan prestasi yang lebih konservatif. Tulis keperluan tegar beban kerja sebagai senarai: format tekstur, reka letak pengikatan (binding layout), saiz storan, had kumpulan kerja (workgroup), dan kejituan. Jika satu keupayaan yang diperlukan tiada, pilih anak tangga seterusnya daripada menunggu penciptaan shader gagal.
Langkah 2: Bina sumber untuk anak tangga keupayaan
Berikan setiap anak tangga varian shader, penerangan talian paip, dan belanjawan sumbernya sendiri. Mulakan dengan segi tiga kecil atau ujian asap (smoke test) inferens kecil, sahkan penyerahan arahan dan output, dan hanya selepas itu masuk ke pemandangan penuh. Jangan anggap kumpulan ikat (bind group) atau format tekstur yang dicipta untuk core diterima dalam mod keserasian.
Sekiranya berlaku kegagalan penciptaan sumber, rekodkan ralat berstruktur dan lepaskan objek anak tangga tersebut. Imej statik, canvas WebGL, atau hasil CPU mesti berkongsi model keadaan produk supaya pengguna boleh menyelesaikan tugas. Sandaran tidak membayangkan kadar bingkai atau kejituan yang serupa.
Langkah 3: Tangani kehilangan peranti dan perlumbaan pemulihan
GPUDevice.lost selesai apabila jangka hayat peranti tamat. Masuk ke keadaan pemulihan: berhenti menyerahkan kerja baharu, batalkan atau tandakan bingkai lama, minta penyesuai dan peranti baharu, bina semula shader, talian paip, penimbal, tekstur, dan kumpulan ikat untuk anak tangga keupayaan, kemudian sambung semula gelung render. Token generasi atau janji penerbangan tunggal menghalang dua percubaan pemulihan daripada menulis ganti peranti baharu.
Jika sebab kehilangan mencadangkan tekanan sumber atau isu pemacu, hadkan percubaan semula dan selang masanya. Kegagalan berulang bertukar kepada WebGL atau CPU dan memberitahu UI bahawa ciri tersebut telah diturunkan gred. Soalan kehilangan peranti yang sedia ada memberi tumpuan kepada mekanik pemulihan; soalan ini memberi tumpuan kepada matriks keupayaan keserasian dan kawalan pelepasan, jadi pastikan skop dipisahkan.
Langkah 4: Reka bentuk pelancaran berperingkat dan rollback
Mulakan dengan matriks peranti dalaman, kemudian kembangkan mengikut versi pelayar, vendor GPU, pemacu, sistem pengendalian, dan rantau. Bendera mestilah boleh dilumpuhkan dari jauh, tetapi penghantaran konfigurasi tidak boleh menjadi titik kegagalan tunggal (single point of failure) untuk ketepatan; klien menyimpan lalai yang selamat.
Jejaki kegagalan permintaan penyesuai, kegagalan penciptaan peranti, masa untuk interaksi pertama, masa bingkai p50/p95 atau kependaman inferens, ralat shader dan talian paip, kadar kehilangan peranti, kejayaan pemulihan, kadar sandaran, dan penyiapan tugas. Segmentasi perkakasan mendedahkan regresi pemacu. Kekalkan telemetri kepada label dan versi peranti kasar dan bukannya cap jari (fingerprint) lengkap.
Langkah 5: Sahkan ketepatan, prestasi, dan kuasa
Bandingkan output WebGPU, compatibility, WebGL, dan CPU dengan toleransi untuk piksel, sempadan geometri, warna tekstur, dan hasil inferens. Tetapkan pemandangan, resolusi, dan saiz kelompok untuk ujian prestasi dan laporkan p50/p95; purata peranti utama (flagship) bukanlah jaminan. Uji kadar penyerahan, memori, dan proksi suhu peranti dalam senario latar belakang dan bateri rendah.
Tetapkan get bagi setiap anak tangga: keserasian memerlukan kadar bingkai minimum produk dan toleransi ralat output, bukan belanjawan core. Jika ralat, kuasa, atau masa pemulihan melepasi ambang, lumpuhkan anak tangga tersebut, kekalkan output WebGL/CPU, dan kumpulkan butiran pemacu dengan pembiakan minimum.
Pertukaran reka bentuk dan sempadan
#### Kuar API vs profil peranti
Kuar langsung adalah tepat tetapi mengambil masa pemuatan pertama; profil peranti adalah pantas tetapi boleh menjadi lapuk atau membawa kepada cap jari. Gunakan kuar pendek untuk keupayaan tegar dan profil hanya untuk susunan dan pelancaran, jangan sekali-kali untuk memintas had sebenar.
#### Mod keserasian vs WebGL
Mod keserasian mengekalkan lebih banyak model sumber dan arahan WebGPU, yang boleh berkongsi seni bina. WebGL mungkin mempunyai liputan matang yang lebih luas, tetapi model shader, penyegerakan, dan prestasinya berbeza. Pilih mengikut keupayaan yang diperlukan, kos penghijrahan ketepatan, dan tugas pengguna, bukan kebaharuan API.
#### Pemulihan automatik vs sandaran serta-merta
Pemulihan terhad mengendalikan tekanan sumber sementara; percubaan semula tanpa had mengubah kegagalan pemacu menjadi jank dan penguatan penggunaan kuasa. Selepas pemulihan gagal atau kehilangan berulang melepasi ambang, tukar serta-merta dan pancarkan satu peristiwa diagnostik.
Jawapan model
“Saya akan membahagikan pelancaran WebGPU kepada matriks keupayaan, pembinaan sumber, mesin keadaan pemulihan, dan kawalan berperingkat. Saya mengesahkan konteks selamat, meminta penyesuai, membaca ciri dan had, serta menyusun core, compatibility, WebGL, dan CPU sebagai tangga keupayaan; setiap anak tangga hanya mencipta shader dan sumber yang disokong. Selepas device.lost, saya menghentikan penyerahan dan menggunakan token generasi supaya satu aliran pemulihan membina semula peranti dan setiap objek GPU, kemudian beralih kepada sandaran jika gagal. Pelancaran disegmentasikan mengikut pelayar, GPU, pemacu, dan versi, dengan metrik pemulaan, masa bingkai, ralat, kehilangan, pemulihan, dan penyiapan tugas berserta suis tutup jauh. Mod keserasian memperluaskan liputan, bukan jaminan prestasi, jadi ketepatan, kependaman, dan kuasa mempunyai get yang berasingan.”
Kesilapan biasa
- Hanya menyemak
navigator.gpu→ Penciptaan penyesuai atau peranti masih boleh gagal, dan ciri atau had mungkin tidak mencukupi → Bina dan sahkan matriks keupayaan. - Memperlakukan mod keserasian sebagai core kelas rendah → Shader, format, dan had mungkin berbeza → Berikan setiap anak tangga keperluan dan ujian asapnya sendiri.
- Memanggil fungsi render sekali lagi selepas kehilangan → Sumber adalah milik peranti yang telah mati → Bina semula setiap sumber melalui aliran pemulihan penerbangan tunggal.
- Mencuba semula penciptaan peranti selama-lamanya → Kerosakan pemacu menjadi jank dan penggunaan kuasa berlebihan → Hadkan percubaan dan selang masa, kemudian beralih ke sandaran.
- Hanya memerhatikan purata kadar bingkai → Kohort GPU atau pemacu kecil boleh gagal sepenuhnya → Segmentasikan p95 dan penyiapan tugas mengikut pelayar, GPU, dan pemacu.
Soalan susulan dan jawapan
Bagaimanakah anda memutuskan sama ada beban kerja sesuai dengan had keserasian?
Tulis keperluan tegar untuk ciri, format tekstur, storan, saiz kumpulan kerja, dan kejituan, kemudian bandingkannya dengan had penyesuai. Masuk ke anak tangga hanya apabila senarai itu dipenuhi; jika tidak, pilih WebGL, CPU, atau output statik dan rekodkan keupayaan yang hilang.
Bolehkah anda memuat semula halaman apabila pengguna sedang mengedit dan peranti hilang?
Bukan secara lalai. Kekalkan keadaan pengeditan pada lapisan aplikasi, jeda kerja GPU, dan cuba satu pembinaan semula yang terhad. Jika ia gagal, tukar perender sambil mengekalkan keadaan dan terangkan penurunan visual kepada pengguna. Muat semula hanya apabila penghijrahan keadaan tidak selamat, dengan titik masuk pemulihan.
Suatu kohort pemacu tiba-tiba mempunyai kadar kehilangan yang tinggi. Bagaimanakah anda melakukan rollback?
Sahkan keabnormalan mengikut GPU, pemacu, pelayar, dan versi aplikasi, kemudian lumpuhkan pelancaran keserasian untuk gabungan tersebut sambil membiarkan kohort lain didayakan. Periksa pemulaan, shader, tekanan sumber, dan sebab kehilangan; lakukan pembiakan secara minimum dan mulakan semula daripada matriks dalaman selepas pembetulan.
Bagaimanakah anda menunjukkan bahawa sandaran WebGL mengekalkan hasil perniagaan?
Cipta set rujukan emas (golden set) rentas-bahagian belakang untuk input yang serupa, bandingkan toleransi piksel atau output inferens, dan sertakan kes kosong, sempadan, dan beban tinggi. Tetapkan get berasingan untuk penyiapan tugas, ketepatan hasil, dan kependaman; persamaan visual tidak membuktikan kesetaraan berangka atau interaksi.