gpu: spike T01 — les atomiques WGSL tiennent, le readback non #184
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/editor-flame"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Un smoke opt-in (
npm run smoke:gpu:atomic-splat, GPU requis, hors CI commetous les *.smoke.mjs) qui tranche le point bloquant du plan flame-ifs GPU.
Trois résultats, dont deux inattendus :
atomic<u32>compile et compte juste sous @kmamal/gpu — 65 536 impacts,65 536 relus, aucune perte. La tranche ne meurt pas.
La contention redoutée n'existe pas, et joue même à l'envers : la
distribution concentrée (le coeur d'un attracteur) va DEUX FOIS plus vite que
l'uniforme à points égaux. Localité L2 + agrégation d'atomiques par warp.
Le splat monte à 2,2 milliards de points/s — filmer à la densité de
l'estampe (20 M points, 9 ms) est gratuit, contre ~2670 ms sur CPU.
Le mur se déplace sur la relecture :
await mapAsyncne rend la main que surun tic de ~100 ms (piège déjà au README §6). Une passe de 1 ms et une de
30 ms se lisent donc pareil. Le smoke mesure en PENTE — 201 passes dans une
seule soumission — sans quoi le cas 2,5 M sortait négatif.
Conséquence pour T04, consignée dans le plan : un seul readback par frame, tout
reste sur GPU jusqu'à la RGBA8 ; et surveiller le débordement u32, dont la marge
n'est que de ×11,6 sur le pixel le plus chaud à 20 M points.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01QE2RdcPX6NLG13GrSPGjkt
Le plan découpait gros et le disait ; /atomiseur-spec le rend jouable fiche par fiche. Trois blocs : les fondations pures (PRNG par chaîne, contrat WGSL/JS, comparaison sous seuil), le moteur d'accumulation (sept fiches — c'est le gros du travail, un deuxième GENRE de moteur à côté de FieldEngine), puis le pourtour (aiguillage de motion, éditeur, gardes, mesures). La cartographie du code a relevé trois divergences avec le plan, notées dans l'index et dans les fiches concernées — le code fait foi : - T08 cite `editor/target-path.mjs` comme siège des contrôles de plongée ; c'est en fait le garde de nom de fichier de `rendu-json/`. Les vrais contrôles sont les ids story-* de `editor/page.html`. - T03 invoque un « hash perceptuel, comme le fait déjà le dépôt ». Le dépôt n'en a aucun : sa pratique est écart moyen + part de pixels sous seuil. - T09 veut marquer « dans les bandes » un pipeline dont l'en-tête affirme qu'il n'en a aucune. Ce sera une surimpression. Et un fait qui va dans le sens du plan : la collision de clé que T09 redoute existe déjà, à la chaîne près — pipeline-video.js:187 et pipeline-video-gpu.mjs écrivent le même `${canonicalHash}/video/${format.code}.mp4`. D'où une fiche qui peut se jouer tout de suite, avant le moteur. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QE2RdcPX6NLG13GrSPGjktcreateFieldForEngine résout désormais sa mécanique sur le GENRE du moteur : createFieldGpu pour les champs (une invocation par pixel, une passe), createAccumulationGpu pour la flamme (une invocation par chaîne, cinq passes). Les deux rendant le même objet { render, dispose }, les appelants n'ont pas à savoir lequel ils tiennent. Écart avec la fiche, assumé : elle proposait de tester gpu-fields.mjs directement. Impossible — ce module importe device.mjs, donc @kmamal/gpu, absent du runner de CI et interdit de renderer/package.json (sandbox-isolation.test.mjs le vérifie). Le test n'aurait jamais tourné là où il compte. D'où un module pur à part, engine-mechanics.mjs, sans aucun import GPU ; gpu-fields.mjs n'en est plus que le câblage — exactement ce qu'on avait déjà fait à field-gpu.mjs. Un genre inconnu échoue en le nommant : retomber silencieusement sur le champ compilerait un shader multi-passes comme s'il n'avait qu'un point d'entrée, pour un 422 obscur une minute plus tard. Suite complète : 2850/2852, les deux échecs restants étant les pipeline-slide connus (dérive SIMD libvips, antérieurs et sans rapport). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QE2RdcPX6NLG13GrSPGjkt