Zinc : démo GPU, compatibilité et Studio créatif

Date : 2026-09-29. Étude et spécification de démo ; aucune nouvelle fonction implémentée ou mesurée ici.

Cette note complète l’étude WebGL et audio. Objectif : jeux, expériences interactives et applications créatives avec rendu GPU, plugins facultatifs et outils utilisables depuis le Studio comme depuis la CLI ou VS Code. JUCE reste une référence fonctionnelle pour l’audio, pas une dépendance proposée.

1. Compatibilité : distinguer l’existant et l’objectif

Les états ci-dessous viennent du code et des manifests consultés, pas d’une campagne de tests sur ces appareils. Une cible déclarée par un plugin n’est pas une certification matérielle. Le système, le pilote, le moteur JS et la version des bibliothèques font partie de la compatibilité.

Sources locales : display-gl, 3D, Three, cibles PlayStation, HAL PS1, HAL PS2.

Mesa décrit VC4 comme GLES2 sur Pi 0 à 3 ; prévoir notamment des indices 16 bits et le découpage des maillages. Le pilote V3D concerne les générations suivantes. Ces capacités ne prouvent pas encore l’intégration Zinc. Mesa VC4, Mesa V3D.

Contrats proposés par profil

Toutes les colonnes suivantes sont des objectifs, pas des fonctionnalités disponibles. « Light » désigne des capacités réduites ; la qualité visuelle et le nombre d’objets sont des réglages indépendants.

Le WebGLRenderer Three actuel exige WebGL 2 depuis r163. Le profil light ne peut donc pas promettre l’exécution inchangée du Three actuel. Documentation Three.

Pour une livraison, chaque cellule devra porter un état non pris en charge, proposé, compilé, testé en émulateur ou testé sur matériel, avec versions, limites numériques interrogées et date. Le Studio et la CLI doivent afficher le même diagnostic : fonctionnalité, cause, alternative disponible. Une fonctionnalité obligatoire absente bloque le lancement ; une dégradation explicitement choisie reste visible.

2. Démo de référence : Interactive Lab

Une seule scène interactive, avec charges activables indépendamment, permettrait de mesurer plus que le nombre de balles. Conserver bouncing-ball pour isoler la 2D ; cette nouvelle démo teste l’ensemble de la chaîne 3D.

Les animations glTF ne sont pas présentes dans le loader Zinc actuel : il expose une liste d’animations vide et ignore notamment squelettes et morph targets. Il faut une implémentation ou l’intégration du loader amont, pas simplement ajouter un fichier GLB à une démo existante. Choisir des fixtures petites et redistribuables, avec licences consignées. Spécification glTF, assets Khronos, AnimationMixer Three.

Mesures et critères de réussite

• Afficher backend réel, appareil, pilote, moteur d’exécution, profil, résolution et capacités. Le rendu logiciel de la scène suivi d’un upload de texture ne satisfait pas le critère « 3D GPU ».
• Vérifier par capture de commandes que les maillages de scène sont rasterisés sur le GPU. L’animation, les collisions ou le skinning peuvent utiliser le CPU : les identifier séparément.
• Mesurer temps de frame médian, p95/p99, FPS, CPU simulation/animation/soumission, temps GPU quand une mesure fiable est disponible, draw calls, triangles, objets/particules réellement rendus, uploads et mémoire. Afficher « indisponible » pour les compteurs non accessibles.
• Séparer démarrage, compilation des shaders et chargement des mesures en régime stable. Fixer caméra, seed, résolution, durée et état de VSync ; consigner chauffe et throttling sur appareil.
• Augmenter une charge à la fois jusqu’au dépassement d’un budget choisi, par exemple 16,7 ms ou 33,3 ms. Rapporter la charge et le seuil soutenu, pas un « maximum universel ».
• Prévoir une passe avec toutes les entités visibles, sans suppression silencieuse ni réduction automatique de qualité. Compter les éléments rejetés et l’écrêtage des pools pour ne pas récompenser des dessins manquants.
• Distinguer simulation GPU de particules et rendu GPU de particules. Une simulation CPU avec sprites rendus en lots sur GPU est un premier jalon valable ; WebGL 2 ne fournit pas des compute shaders généraux.
• Tester ensuite le coût cumulé : animation + ombres + particules + UI + mapping, puis aperçu distant activé/désactivé.

Une variante light garde les mêmes interactions avec moins d’effets. Les variantes consoles conservent le scénario, avec assets et matériaux adaptés. Leurs résultats ne sont comparables en performance que pour les sous-tests visuellement et fonctionnellement équivalents. Une scène réussie ne remplace pas les tests de conformité WebGL.

3. PS1 et PS2 : adapter Three et Canvas au matériel

Réutiliser les SDK déjà employés par les targets : PSn00bSDK, ps2sdk et gsKit. L’étape utile est de soumettre les primitives de la scène au matériel ; aujourd’hui les HAL présentent une image rasterisée par le CPU.

Sur PS1, PSn00bSDK expose primitives GPU et opérations GTE de transformation/projection/éclairage. Un renderer adapté construirait les paquets et l’ordre de dessin, avec textures préparées et géométrie limitée. Le GPU ne fournit pas le pipeline programmable WebGL ; la perspective des textures et l’absence de depth buffer imposent des compromis visibles. Sur PS2, le partage proposé est EE/VU pour la géométrie et GS pour les pixels ; ps2sdk expose notamment les attributs STQ/RGBAQ/XYZ. Programmer un VU ne revient pas à exécuter un fragment shader GLSL. Documentation GPU PS1, primitives 3D ps2sdk.

Le contrat utile serait un sous-ensemble commun : nœuds, transforms, caméra, mesh, texture, matériau simple, animation et sprites. Les matériaux à shader arbitraire exigeraient une variante console écrite/préparée explicitement. Ne pas présenter ce backend comme compatible avec l’intégralité de Three ou de WebGL.

Préparer les assets sur le poste de développement : découpage de meshes, atlas/palettes, quantification, réduction du squelette et des influences, conversion de clips, textures et matériaux. Le build doit signaler extensions glTF obligatoires non gérées et dépassements de budgets. Garder sources originales et variantes générées reproductibles ; éviter de parser tout glTF et décompresser de grosses textures sur PS1.

Pour Canvas, réutiliser la géométrie CPU quand elle convient, puis envoyer triangles, sprites et glyphes au GPU. Le Canvas Zinc actuel possède déjà des limites : clipping par rectangle englobant, transformations incomplètes sur texte/images, ombres ignorées et compositing réduit à source-over. Les consoles ne figurent pas dans son manifest. Une API commune ne dispense donc pas d’une table opération par opération : support exact, approximation acceptée ou erreur. Masques complexes, filtres et mélanges doivent être précalculés ou déclarés indisponibles si le backend ne peut pas les reproduire.

4. Mapping de toute la vue applicative

Le mapping actuel déforme des couches image/pattern ; le présentateur GL dessine ensuite l’overlay gfx séparément. Il ne transforme donc pas automatiquement toute l’application. Son manifest déclare macOS et rpi1, pas Linux malgré le support Linux du display : alignement et tests nécessaires avant de l’annoncer.

Chemin proposé : scène 3D + Canvas + UI → texture de composition applicative → warp, masques, edge blend et couleur → sortie physique. Garder les pixels sur GPU ; pas de lecture CPU par frame pour relier 3D et mapping. Prévoir taille de rendu, gestion de profondeur/alpha, ordre des passes et espace colorimétrique explicites. Les ressources GL/ANGLE ne sont pas nécessairement partageables avec le backend GL existant : intégrer la composition dans un même contexte/backend ou valider un mécanisme d’interop, sans supposer un simple échange d’identifiants de texture.

« Toute la fenêtre » signifie ici le contenu rendu par Zinc. La barre de titre du système ou une WebView native extérieure au compositeur n’entre pas automatiquement dans cette texture. Un panneau technique de calibration peut volontairement rester hors transformation.

Les clics suivent la transformation inverse : homographie pour quatre coins, recherche du triangle et interpolation inverse pour un maillage. Définir les règles hors masque, en cas de recouvrement ou de maillage replié ; ne pas transmettre une position ambiguë sans politique. Tester le picking 3D après cette conversion. Sur plusieurs sorties, partager la composition si utile, mais mesurer chaque passe et les contraintes de synchronisation. Sur consoles, étudier d’abord les buffers et budgets : pas de promesse de mapping global gratuit.

5. Studio : prolonger ce qui existe, conserver la CLI

Le Studio actuel est déjà une application Zinc : graphes de comportements, inspector, scripts, assets, choix de cible, build/run via CLI, logs et aperçu distant. Il ne constitue pas encore un éditeur complet de scènes 3D, de matériaux et de timelines. Réutiliser cette base plutôt que construire un second système de projets.

L’objectif produit associe les usages Unity/Godot (scène, caméra, animation, Play), Qt (UI et déploiement embarqué) et outils créatifs (mapping, particules, contrôle en direct), selon les plugins choisis.

L’aperçu hôte vérifie interactions et contraintes déclarées ; il ne prédit pas le FPS d’un Pi. L’émulation teste une partie du comportement cible ; la validation des pilotes, de la mémoire, de la latence et du débit doit se faire sur appareil.

Le display distant actuel remplace l’afficheur. Pour examiner la vraie 3D GPU d’un appareil, prévoir une capture/transport optionnel de la sortie GPU sans substituer un autre renderer. Mesurer séparément capture, encodage et réseau. Laisser l’exécution continuer sans client Studio. Un contrôle réseau doit authentifier le client et limiter les opérations ; il reste un module de développement facultatif.

L’inspection actuelle ne fournit pas automatiquement des breakpoints source universels : Runtime.evaluate et le débogage diffèrent selon moteur. Publier séparément inspection UI, logs, captures, profilage et débogage source. Ne pas nommer « debugger complet » une simple vue distante.

Conserver une source de vérité commune au Studio et à la CLI. Dans le projet actuel, le graphe génère du code ; cela ne permet pas de reconvertir arbitrairement tout TypeScript en graphe. Documenter les frontières entre code généré et code utilisateur, préserver ce dernier à chaque sauvegarde. Ajouter les métadonnées visuelles sans rendre le Studio nécessaire au build. Ni éditeur, ni layout, ni GPU, ni audio ne deviennent des dépendances du core headless.

6. Ordre de validation proposé

1. Un mesh GPU et un shader utilisateur sur desktop, avec preuve du backend et comptage des ressources ; puis une scène Three amont, versions fixées.
2. glTF animé, lumières et particules indépendamment, puis Interactive Lab complet avec mesures reproductibles.
3. Profil light sur un vrai Pi 1/2 : shaders adaptés, mêmes interactions, limites documentées ; refuser le mode standard si absent.
4. Composition applicative GPU puis mapping global et coordonnées d’entrée corrigées ; mesurer le coût et la mémoire supplémentaires.
5. Une scène minimale PS1 et PS2 par primitives matérielles, avant de porter davantage de l’API Three/Canvas. Vérifier matériel et émulateur séparément.
6. Exposer les commandes et diagnostics validés dans le Studio, puis enrichir l’édition de scènes, d’UI et d’animations au rythme des capacités réelles.

Aucun chiffre de FPS ni niveau de compatibilité complet n’est promis avant ces essais. La première implémentation utile reste une preuve GPU étroite ; cette note définit la destination et les critères, pas une obligation de construire tous les sous-systèmes simultanément.

Edit this page on GitHub ↗