wgpu
v23.0.0 (2024-10-25)
wgpu est une API graphique multiplateforme, sûre et pure-rust. Il fonctionne nativement sur Vulkan, Metal, D3D12 et OpenGL; et en plus de WebGL2 et WebGpu sur Wasm.
L'API est basée sur la norme WebGPU. Il sert de cœur de l'intégration WebGPU dans Firefox et Deno.
Le référentiel héberge les bibliothèques suivantes:
Les binaires suivants:
naga .cts_runner - WEBGPU CONFORMANCE TEST SUITE RUNNER Utilisation de deno_webgpu .player - Application autonome pour rejouer les traces d'API.Pour un aperçu de tous les composants de l'écosystème GFX-RS, voir la situation dans son ensemble.
Des exemples de rouille peuvent être trouvés à WGPU / Exemples. Vous pouvez exécuter les exemples sur natif avec cargo run --bin wgpu-examples <example> . Voir la liste des exemples.
Pour exécuter les exemples dans un navigateur, exécutez cargo xtask run-wasm . Ouvrez ensuite http://localhost:8000 dans votre navigateur, et vous pouvez choisir un exemple à exécuter. Naturellement, afin d'afficher l'un des exemples basés sur WebGPU, vous devez vous assurer que votre navigateur le prend en charge.
Si vous recherchez un tutoriel WGPU, regardez ce qui suit:
Pour utiliser WGPU en C / C ++, vous avez besoin de WGPU natif.
Si vous recherchez un tutoriel WGPU C ++, regardez ce qui suit:
Si vous souhaitez utiliser WGPU dans d'autres langues, il existe de nombreuses liaisons aux natifs WGPU à partir de langues telles que Python, D, Julia, Kotlin, etc. Voir la liste.
Nous avons l'espace matriciel avec quelques pièces différentes qui forment la communauté WGPU:
Nous avons un wiki qui sert de base de connaissances.
| API | Fenêtre | Linux / Android | macOS / iOS | Web (wasm) |
|---|---|---|---|---|
| Vulkan | ✅ | ✅ | ? | |
| Métal | ✅ | |||
| Dx12 | ✅ | |||
| Opengl | ? (GL 3.3+) | ? (Gl es 3.0+) | ? | ? (Webgl2) |
| Webgpu | ✅ |
✅ = support de première classe
? = Support de dépassement / meilleur effort
? = Nécessite la couche de traduction d'angle (GL ES 3.0 uniquement)
? = Nécessite la couche de traduction MOLTENVK
= Non pris en charge, bien que ouvert aux contributions
WGPU prend en charge les shaders dans WGSL, SPRI-V et GLSL. HLSL et GLSL ont tous deux des compilateurs pour cibler Spir-V. Toutes ces langues de shader peuvent être utilisées avec n'importe quel backend car nous gérons toutes les conversions. De plus, la prise en charge de ces entrées de shader ne disparaît pas.
Bien que WebGPU ne prenne en charge aucun langage d'ombrage autre que WGSL, nous convertirons automatiquement vos shaders non WGSL si vous utilisez WebGPU.
WGSL est toujours pris en charge par défaut, mais les fonctionnalités GLSL et Spir-V ont besoin de compiler dans la prise en charge.
Notez que la spécification WGSL est toujours en cours de développement, de sorte que le projet de spécification ne décrit pas exactement ce que wgpu prend en charge. Voir ci-dessous pour plus de détails.
Pour activer les shaders Spir-V, activez la fonction spirv de WGPU. Pour activer les shaders GLSL, activez la fonction glsl de WGPU.
L'angle est une couche de traduction des GLES aux autres backends développés par Google. Nous prenons en charge l'exécution de notre backend GLES3 dessus afin d'atteindre la prise en charge des plates-formes DX11, qui ne sont pas accessibles autrement. Pour fonctionner avec l'angle, la fonction "angle" doit être activée et les bibliothèques d'angle placées dans un emplacement visible à l'application. Ces binaires peuvent être téléchargés à partir d'artefacts à angle GFBuild, une compilation manuelle peut être nécessaire sur les Mac avec Apple Silicon.
Sur Windows, vous devez généralement les copier dans le répertoire de travail, dans le même répertoire que l'exécutable ou quelque part sur votre chemin. Sur Linux, vous pouvez les signaler en utilisant un environnement LD_LIBRARY_PATH .
En raison de personnes à charge complexes, nous avons deux politiques de MSRV:
d3d12 , naga , wgpu-core , wgpu-hal et MSRV de wgpu-types sont de 1,76 , mais peuvent être inférieurs au reste de l'espace de travail à l'avenir. Il est appliqué sur CI (dans "/.github/workflows/ci.yml") avec les variables CORE_MSRV et REPO_MSRV . Cette version ne peut être mise à niveau que dans les sorties de rupture, bien que nous soyons publiés une version de rupture tous les trois mois.
Les caisses naga , wgpu-core , wgpu-hal et wgpu-types ne devraient jamais nécessiter de MSRV avant le MSRV de Firefox pour les constructions nocturnes, comme déterminé par la valeur de MINIMUM_RUST_VERSION dans python/mozboot/mozboot/util.py
Tous les tests et les exemples d'infrastructures partagent le même ensemble de variables d'environnement qui déterminent sur quel backend / GPU il fonctionnera.
WGPU_ADAPTER_NAME avec une sous-chaîne du nom de l'adaptateur que vous souhaitez utiliser (Ex. 1080 correspondra à NVIDIA GeForce 1080ti ).WGPU_BACKEND avec une liste séparée par des virgules que vous souhaitez utiliser ( vulkan , metal , dx12 ou gl ).WGPU_POWER_PREF avec la préférence de puissance pour choisir lorsqu'un nom d'adaptateur spécifique n'est pas spécifié ( high , low ou none )WGPU_DX12_COMPILER AVEC LE COMPILATEUR DE SHADER DX12 que vous souhaitez utiliser ( dxc ou fxc , notez que dxc exige que dxil.dll et dxcompiler.dll soient dans le répertoire de travail, sinon il retombera à fxc )WGPU_GLES_MINOR_VERSION avec le numéro de version mineur OpenGL ES 3 à demander ( 0 , 1 , 2 ou automatic ).WGPU_ALLOW_UNDERLYING_NONCOMPLIANT_ADAPTER AVEC UN BOOLEAN SI les pilotes non conformes sont énumérés ( 0 pour False, 1 pour true). Lorsque vous exécutez le CTS, utilisez les variables DENO_WEBGPU_ADAPTER_NAME , DENO_WEBGPU_BACKEND , DENO_WEBGPU_POWER_PREFERENCE .
Nous avons plusieurs méthodes de test, chacune testant différentes qualités sur WGPU. Nous exécutons automatiquement nos tests sur CI. L'état actuel des tests CI:
| Plate-forme / backend | Tests | Notes |
|---|---|---|
| Windows / DX12 | ✔️ | Utilisation de Warp |
| Windows / OpenGL | ✔️ | Utilisation de llvmpipe |
| MacOS / métal | ✔️ | Utilisation de Hardware Runner |
| Linux / Vulkan | ✔️ | Utilisation de Lavapipe |
| Linux / OpenGL ES | ✔️ | Utilisation de llvmpipe |
| Chrome / webgl | ✔️ | Utilisation de SwiftShader |
| Chrome / webgpu | pas configuré |
Nous utilisons un outil appelé cargo nextest pour exécuter nos tests. Pour l'installer, exécutez cargo install cargo-nextest .
Pour exécuter la suite de tests:
cargo xtask test
Pour exécuter la suite de tests sur WebGL (actuellement incomplète):
cd wgpu
wasm-pack test --headless --chrome --no-default-features --features webgl --workspace
Cela exécutera automatiquement les tests à l'aide d'un navigateur emballé. Supprimez --headless pour exécuter les tests avec le navigateur que vous souhaitez sur http://localhost:8000 .
Si vous êtes un utilisateur et que vous souhaitez aider à contribuer à WGPU, nous avons toujours besoin de plus d'aide pour rédiger des cas de test.
WebGPU comprend une suite de tests de conformité pour valider que les implémentations fonctionnent correctement. Nous pouvons exécuter ce CTS contre WGPU.
Pour exécuter le CTS, vous devez d'abord le vérifier:
git clone https://github.com/gpuweb/cts.git
cd cts
# works in bash and powershell
git checkout $(cat ../cts_runner/revision.txt)
Pour exécuter un ensemble donné de tests:
# Must be inside the `cts` folder we just checked out, else this will fail
cargo run --manifest-path ../Cargo.toml -p cts_runner --bin cts_runner -- ./tools/run_deno --verbose "<test string>"
Pour trouver la liste complète des tests, rendez-vous à la visionneuse CTS en ligne.
La liste des tests CTS actuellement activées peut être trouvée ici.
La caisse wgpu est censée être une traduction de rouille idiomatique de l'API WebGPU. Cette spécification, ainsi que son langage d'ombrage, WGSL, sont toutes deux toujours dans la phase de "projet de travail", et bien que les contours généraux soient stables, les détails changent fréquemment. Jusqu'à ce que la spécification soit stabilisée, la caisse wgpu et la version de WGSL qu'il implémente diffèrent probablement de ce qui est spécifié, car l'implémentation se rattrape.
Le WGSL comprend exactement les supports wgpu dépend de la façon dont vous l'utilisez:
Lors de l'exécution de code natif, wgpu utilise la caisse NAGA pour traduire le code WGSL dans le langage d'ombrage de l'API GPU native de votre plateforme. Naga a une étape importante pour rattraper la spécification WGSL, mais en général, il n'y a pas de résumé à jour des différences entre NAGA et la spécification WGSL.
Lors de l'exécution dans un navigateur Web (par compilation vers WebAssembly) sans la fonctionnalité "webgl" activée, wgpu s'appuie sur la propre implémentation WebGPU du navigateur. Les shaders WGSL sont simplement transmis au navigateur, ce qui détermine les fonctionnalités WGSL que vous pouvez utiliser.
Lors de l'exécution dans un navigateur Web avec la fonction "webgl" de wgpu activée, wgpu utilise NAGA pour traduire les programmes WGSL en GLSL. Cela utilise la même version de Naga que si vous exécutiez wgpu que le code natif.
WGPU utilise les systèmes de coordonnées de D3D et du métal:
| Rendre | Texture |
|---|---|
 |  |
