Dans cet article
Dimension est mon workspace Rust pour mes expériences en mathématiques et en infographie. Le point de départ est mathlib : la bibliothèque expose le stockage matriciel, des solveurs numériques et les transformations utilisées côté CPU par le module de rendu.
Architecture
Vue générale des composants et des échanges vérifiés dans le dépôt.
flowchart LR
subgraph group_data["Linear Algebra Data"]
node_matrix["Matrices<br/>[matrix.rs]"]
node_vector["Vectors<br/>[vector.rs]"]
node_storage[("Matrix Storage<br/>[dense_storage.rs]")]
node_operators["Operators<br/>[operators.rs]"]
end
subgraph group_compute["Compute Backends"]
node_cpu["CPU Dispatch<br/>[mod.rs]"]
node_parallel["Parallel CPU<br/>[parallel.rs]"]
node_sequential["Sequential CPU<br/>[sequential.rs]"]
node_simd["SIMD CPU<br/>[simd.rs]"]
node_executor["Execution<br/>[executor.rs]"]
node_gpu["GPU Compute<br/>[mod.rs]"]
node_pipelines["GPU Pipelines<br/>[pipelines.rs]"]
node_shaders["GPU Shaders<br/>[shaders.rs]"]
end
subgraph group_algorithms["Numerical Algorithms"]
node_linear["Linear Solvers<br/>[solve.rs]"]
node_decomposition["Decomposition<br/>[svd.rs]"]
node_optimization["Optimization<br/>[linesearch.rs]"]
node_graph["Graph Algorithms<br/>[mod.rs]"]
end
subgraph group_domains["Math Domains"]
node_math3d["3D Math<br/>[math3d.rs]"]
node_transforms["Transforms<br/>[mod.rs]"]
node_ml["ML and Statistics<br/>[mod.rs]"]
node_noise["Noise<br/>[mod.rs]"]
end
node_application(("Application"))
node_api["Public API<br/>[lib.rs]"]
node_application -->|"uses"| node_api
node_api -->|"exports"| node_matrix
node_api -->|"exports"| node_vector
node_api -->|"exports"| node_storage
node_api -->|"exposes"| node_operators
node_api -->|"exports"| node_linear
node_api -->|"exports"| node_decomposition
node_api -->|"exports"| node_optimization
node_api -->|"exports"| node_graph
node_api -->|"exports"| node_math3d
node_api -->|"exports"| node_transforms
node_api -->|"exports"| node_ml
node_api -->|"exposes"| node_noise
node_cpu -->|"dispatches"| node_parallel
node_cpu -->|"dispatches"| node_sequential
node_cpu -->|"dispatches"| node_simd
node_pipelines -->|"uses shaders"| node_shaders
class node_matrix,node_vector,node_storage,node_operators toneBlue
class node_cpu,node_parallel,node_sequential,node_simd,node_executor,node_gpu,node_pipelines,node_shaders toneAmber
class node_linear,node_decomposition,node_optimization,node_graph,node_api toneMint
class node_math3d,node_transforms,node_ml,node_noise toneRose
class node_application toneIndigoUn espace de travail mathématique en Rust centré sur mathlib. Les applications construisent des vecteurs, matrices et cubes, puis appliquent des opérations numériques, géométriques et analytiques avant de rejoindre les modules de rendu.
- Composants
- 22
- Connexions
- 17
- Liens appuyés par le code ou le README
- 16/17
Version texte du diagramme
- Application ou démo → Données et transformations mathlib
- Données et transformations mathlib → Hiérarchie de scène et caméra
- Hiérarchie de scène et caméra → Ressources et passes wgpu
- Ressources et passes wgpu → Fenêtre native ou canevas web
L’application fournit la géométrie et les transformations. La scène organise les entités et les caméras; le moteur prépare le travail GPU pour une fenêtre native ou un canevas web. Ce parcours de rendu ne signifie pas que tous les calculs numériques passent sur le GPU.
Lire le parcours du code, composant par composant.
Commencer par le stockage
mathlib/src/lib.rs expose du stockage dense et des formats creux comme CRS et CCS. L’API comprend aussi des matrices, des vecteurs, des vues et des sous-matrices. Ces choix interviennent avant le premier dessin : ils déterminent comment le code représente et transmet ses données.
Le même point d’entrée expose les décompositions LU, Cholesky et SVD, ainsi que la recherche de racines et l’intégration numérique. Les fonctions GPU sont optionnelles. L’abstraction d’exécution représente un choix de conception ; elle ne constitue pas une mesure de gain de vitesse. Je ne présente pas de comparaison de performance ici.
Suivre une transformation dans la scène
render/src/lib.rs décrit un moteur wgpu qui utilise mathlib pour les transformations CPU et les calculs de caméra. Il expose notamment World, EntityId, Transform, les caméras et les cibles de rendu.
La scène représente les relations parent-enfant dans un arbre. Une transformation locale s’inscrit donc dans une hiérarchie : déplacer un parent modifie le repère dans lequel ses enfants sont rendus. La sérialisation est optionnelle, sous la fonctionnalité serde.
La couche plateforme prend en charge les fenêtres natives et les cibles WebAssembly avec canvas. Séparer cette couche du code de scène et des calculs permet de partager des composants, sans pour autant prouver un comportement identique sur chaque GPU ou navigateur.
Lire le workspace au-delà du README
Le Cargo.toml racine contient des crates de rendu, géométrie, collision, cinématique, physique, réseau, parsing et calcul neuronal, en plus de mathlib. Le README reste centré sur les mathématiques. Le manifeste et les points d’entrée des modules donnent une vue plus complète de la structure actuelle.
Ce code reste exploratoire. Pour justifier un résultat de performance, il faudrait un benchmark reproductible avec la taille des données et le matériel utilisé. Le dépôt montre pour l’instant comment je relie les calculs numériques à mes travaux d’infographie.