Tessera Engine

Les frontières sont imposées par les dossiers autant que par les interfaces. Seule Platform parle à SDL3 ; seul RHI/D3D12/ inclut les headers Direct3D. Render décide quoi dessiner sans enregistrer de commandes GPU. ECS, Jobs et Scene n’incluent ni Render/ ni RHI/ ; Assets et Project restent aussi indépendants du rendu.

Les bibliothèques d’import et de compression appartiennent exclusivement à Tools/TesseraCooker. Le runtime consomme les données préparées sans dépendances d’authoring. Des recherches d’includes vérifient ces règles, mais la compilation fournit une preuve plus forte : Tessera.NoD3D12.sln compile moteur et éditeur avec un backend nul et une interface SDL_Renderer. Un type D3D12 qui fuit casse cette solution ; ses builds produisent zéro objet Dx*.obj.

Chaque worker possède un deque Chase-Lev : il empile et dépile sans verrou tandis que les workers inactifs volent à l’autre extrémité. Un worker qui attend un job exécute d’autres tâches sur sa pile courante. Le test avec un seul worker vérifie que les dépendances progressent. Les threads externes au pool attendent passivement ; leur participation créerait deux producteurs pour un deque qui n’en accepte qu’un.

Les jobs ont une affinité AnyWorker, LongRunning ou MainThread. Deux compteurs séparent le travail de la frame du travail long, pour empêcher la compilation de shaders de prolonger l’attente de la frame. Dans la comparaison enregistrée, la frame la plus lente pendant une recompilation est passée de 803 ms à 18,75 ms. Une FrameArena par worker fournit la mémoire temporaire ; ParallelFor sur 1 048 576 éléments a produit le résultat sériel sans allocation sur le heap.

Trois défauts de concurrence sont apparus pendant le développement, dont un uniquement avec la fenêtre de l’éditeur visible. Un watchdog nommant l’étape bloquée a aidé à l’isoler. Le passage du vol par lot au vol par élément a transféré ce coût au thread inactif. Un large graphe de travail réel a mesuré 94,7% d’occupation des workers.

Le cooker utilise le même système : compresser une texture 2048² a pris 311,8 s avec un thread et 9,7 s avec 24. Tracy et une timeline intégrée exposent l’activité CPU/GPU et le travail par worker. Ce sont des mesures précises du projet, pas des garanties générales de débit.

Les mesh shaders ne sont pas implémentés dans le renderer. Le pipeline existant laisse ce chemin ouvert : les slots de la root signature canonique sont visibles à tous les stages, les pipelines utilisent le pipeline state stream, DXC reconnaît ms et as à partir du Shader Model 6.5 et la détection de capacités interroge leur prise en charge par le GPU.

Un test a créé un pipeline de mesh shader avec cette root signature. Cela vérifie la compatibilité, pas un chemin de rendu livré. meshoptimizer est choisi mais pas intégré. Le plan prévoit que le cooker génère les meshlets dans un nouveau chunk .tmesh ; les anciens fichiers conserveront le chemin vertex traditionnel en son absence. Les contrats du conteneur et du pipeline rendent cette extension possible.

Chaque passe déclare lectures et écritures, types d’accès et stages GPU. Le graphe voit la frame entière et déduit ordre et barrières de ces déclarations. Il n’enregistre jamais de commandes. L’exécuteur D3D12 lit l’ordre d’exécution et les barrières par passe, puis enregistre le travail correspondant.

La compilation construit les dépendances sur le dernier écrivain précédent, rejette les cycles avec un plan vide, retire les producteurs inutilisés, choisit les files, calcule les durées de vie transitoires et génère les barrières lors des changements de rôle des ressources. Ressources exportées et effets de bord déclarés préservent le travail requis ; importer une ressource ne protège pas son producteur de la suppression.

L’ordre d’utilisation diffère de la durée de vie avec compute optionnel : les positions du plan ne décrivent pas les exécutions qui se chevauchent. Le graphe fournit les intervalles ; le propriétaire des heaps décide l’aliasing et demande ses barrières. Mon allocateur regroupe par durée de vie, exigence qui a motivé le rejet de l’approche par taille du D3D12 Memory Allocator évalué. Huit ressources volontairement échelonnées utilisaient 2 688 KB au lieu de 10 752 KB, soit 4,00× de réduction et le minimum pour ce test.

Le graphe forward fourni a été exporté depuis Sample.tscn le 6 octobre 2026. Dans cette configuration enregistrée, 20 passes produisent 15 barrières. Six passes d’occlusion/ray tracing désactivées ouvrent seulement des scopes vides : une passe sans écritures n’est pas un producteur inutilisé et n’est pas automatiquement supprimée. La transition SceneColor avant ToneMapPass est déduite du passage de render target à lecture shader. Les comptes varient avec le chemin de shading et les effets activés.

Reset() efface les données de frame en conservant la capacité des vecteurs ; les handles de ressources du graphe expirent alors. L’export Graphviz et le panneau de l’éditeur exposent le plan ; --rendergraph-self-test exécute 242 vérifications sans GPU.

Dear ImGui docking garde l’éditeur en C++, dans le processus du moteur. La Lobby ouvre un projet sans lancer une autre application. Le Content Browser dispose de miniatures rendues, d’un cache disque à invalidation automatique et d’imports en arrière-plan. Les fenêtres mesh/prefab proposent des previews GPU ; l’éditeur de textures isole les canaux et regroupe ORM. Les propriétés d’assets exposent directement les chunks binaires.

Hierarchy, Inspector, transforms ImGuizmo, undo/redo, prefabs, tags et couleurs d’assets accompagnent l’édition des scènes. Le Material Graph est une vue en lecture seule dérivée du .tmat ; son câblage n’est pas éditable. Les widgets de graphes viennent du GraphEditor d’ImGuizmo.

Play, Pause, Stop et Simulate partagent les snapshots : Stop restaure le monde capturé et vérifie un hash identique. Les scènes d’authoring utilisent JSON pour des diffs Git lisibles, puis sont préparées en binaire pour le runtime. Profiling, Render Graph, ECS Diagnostics et Console permettent d’inspecter les systèmes en exécution depuis l’éditeur.

Je suis revenu à Sharpmake après CMake afin qu’un générateur définisse les builds IDE et ligne de commande. Sharpmake et vcpkg produisent deux solutions en Debug, Development, Profile et Shipping : huit builds locaux, tous avec avertissements traités en erreurs. Les vérifications post-build contrôlent les DLLs runtime et les arborescences de shaders répliquées.

Les tests sans fenêtre comprennent 4 883 vérifications ECS, 242 du render graph et 837 du cooker. Des sondes en ligne de commande exercent les fonctions individuellement ; un harness compare temps et compteurs à une baseline. Les diffs d’images contre la version précédente exigent zéro pixel de scène différent pour les critères d’acceptation des refactorings décrits ici.

Ces nombres viennent des relevés du projet utilisés pour cette étude. Ils documentent la méthode et les scénarios mesurés, sans représenter une nouvelle exécution du dépôt privé par ce site. Build alternatif, audits de replay et comparaisons d’images vérifient des modes de défaillance qu’un build normal réussi ne suffirait pas à révéler.