Prise en charge des valeurs à virgule flottante 16 bits dans WGSL
En WGSL, le type f16
est l'ensemble des valeurs à virgule flottante 16 bits du format binaire 16 IEEE-754 (demi-précision). Cela signifie qu'il utilise 16 bits pour représenter un nombre à virgule flottante, contre 32 bits pour la virgule flottante à simple précision classique (f32
). Cette taille réduite peut entraîner une amélioration significative des performances, en particulier lors du traitement de grandes quantités de données.
À titre de comparaison, sur un appareil Apple M1 Pro, l'implémentation f16
des modèles Llama2 7B utilisés dans la démonstration par chat WebLLM est beaucoup plus rapide que l'implémentation f32
, avec une amélioration de 28% de la vitesse de préremplissage et de 41% de la vitesse de décodage, comme illustré sur les captures d'écran suivantes.
![Capture d'écran de démonstrations du chat WebLLM avec les modèles f32 et f16 Llama2 7B](https://developer.chrome.com/static/blog/new-in-webgpu-120/image/webllm-chat-demos.png?authuser=6&hl=fr)
f32
(à gauche) et f16
(à droite) Llama2 7BTous les GPU ne sont pas compatibles avec les valeurs à virgule flottante 16 bits. Lorsque la fonctionnalité "shader-f16"
est disponible dans un GPUAdapter
, vous pouvez désormais demander un GPUDevice
avec cette fonctionnalité et créer un module de nuanceur WGSL qui exploite le type à virgule flottante à demi-précision f16
. Ce type ne peut être utilisé dans le module de nuanceur WGSL que si vous activez l'extension WGSL f16
avec enable f16;
. Sinon, createShaderModule() générera une erreur de validation. Consultez l'exemple minimal suivant et le problème dawn:1510.
const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("shader-f16")) {
throw new Error("16-bit floating-point value support is not available");
}
// Explicitly request 16-bit floating-point value support.
const device = await adapter.requestDevice({
requiredFeatures: ["shader-f16"],
});
const code = `
enable f16;
@compute @workgroup_size(1)
fn main() {
const c : vec3h = vec3<f16>(1.0h, 2.0h, 3.0h);
}
`;
const shaderModule = device.createShaderModule({ code });
// Create a compute pipeline with this shader module
// and run the shader on the GPU...
Il est possible de prendre en charge les types f16
et f32
dans le code du module de nuanceur WGSL avec un alias
selon la compatibilité de la fonctionnalité "shader-f16"
, comme indiqué dans l'extrait suivant.
const adapter = await navigator.gpu.requestAdapter();
const hasShaderF16 = adapter.features.has("shader-f16");
const device = await adapter.requestDevice({
requiredFeatures: hasShaderF16 ? ["shader-f16"] : [],
});
const header = hasShaderF16
? `enable f16;
alias min16float = f16;`
: `alias min16float = f32;`;
const code = `
${header}
@compute @workgroup_size(1)
fn main() {
const c = vec3<min16float>(1.0, 2.0, 3.0);
}
`;
Repoussez les limites
Par défaut, le nombre maximal d'octets nécessaires pour contenir un échantillon (pixel ou sous-pixel) de données de sortie du pipeline de rendu pour toutes les pièces jointes de couleur est de 32 octets. Il est désormais possible d'en demander jusqu'à 64 en utilisant la limite de maxColorAttachmentBytesPerSample
. Consultez l'exemple suivant et le problème dawn:2036.
const adapter = await navigator.gpu.requestAdapter();
if (adapter.limits.maxColorAttachmentBytesPerSample < 64) {
// When the desired limit isn't supported, take action to either fall back to
// a code path that does not require the higher limit or notify the user that
// their device does not meet minimum requirements.
}
// Request highest limit of max color attachments bytes per sample.
const device = await adapter.requestDevice({
requiredLimits: { maxColorAttachmentBytesPerSample: 64 },
});
Les limites de maxInterStageShaderVariables
et maxInterStageShaderComponents
utilisées pour la communication entre les étapes ont été augmentées sur toutes les plates-formes. Pour en savoir plus, consultez le problème dawn:1448.
Pour chaque étape du nuanceur, le nombre maximal d'entrées de mise en page de groupes de liaisons sur une mise en page de pipeline qui sont des tampons de stockage est de 8 par défaut. Il est désormais possible d'en demander jusqu'à 10 en utilisant la limite de maxStorageBuffersPerShaderStage
. Voir issue dawn:2159
Une nouvelle limite de maxBindGroupsPlusVertexBuffers
a été ajoutée. Il correspond au nombre maximal d'emplacements de groupe de liaisons et de tampon de sommet utilisés simultanément, en comptant tous les emplacements vides en dessous de l'index le plus élevé. Sa valeur par défaut est 24. Voir issue dawn:1849.
Modifications apportées à l'état du stencil de profondeur
Pour améliorer l'expérience développeur, les attributs état du stencil de profondeur depthWriteEnabled
et depthCompare
ne sont plus toujours obligatoires: depthWriteEnabled
n'est obligatoire que pour les formats avec profondeur, et depthCompare
n'est pas obligatoire pour les formats avec profondeur s'ils ne sont pas utilisés du tout. Voir issue dawn:2132.
Mises à jour des informations sur l'adaptateur
Les attributs d'informations sur les adaptateurs type
et backend
non standards sont désormais disponibles lors de l'appel de requestAdapterInfo() lorsque l'utilisateur a activé les "Fonctionnalités pour les développeurs WebGPU". l'indicateur à chrome://flags/#enable-webgpu-developer-features
. La valeur type
peut être "GPU discret", "GPU intégré", "Processeur" ou "Inconnu". backend
est "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" ou "null". Voir issue dawn:2112 et issue dawn:2107.
![Capture d'écran de https://webgpureport.org montrant le backend et les informations sur l'adaptateur.](https://developer.chrome.com/static/blog/new-in-webgpu-120/image/webgpureport.png?authuser=6&hl=fr)
Le paramètre de liste unmaskHints
facultatif dans requestAdapterInfo() a été supprimé. Voir issue dawn:1427.
Quantification des requêtes d'horodatage
Les requêtes d'horodatage permettent aux applications de mesurer le temps d'exécution des commandes GPU avec une précision de la nanoseconde. Cependant, la spécification WebGPU rend les requêtes de code temporel facultatives en raison de problèmes d'attaques temporelles. L'équipe Chrome estime que la quantification des requêtes avec horodatage offre un bon compromis entre précision et sécurité, car elle réduit la résolution à 100 microsecondes. Voir issue dawn:1800
Dans Chrome, les utilisateurs peuvent désactiver la quantification de code temporel en activant les "Fonctionnalités pour les développeurs WebGPU" flag à chrome://flags/#enable-webgpu-developer-features
. Notez que cet indicateur seul n'active pas la fonctionnalité "timestamp-query"
. Son implémentation en est encore au stade expérimental et nécessite donc l'assistance "Unsafe WebGPU". l'indicateur à chrome://flags/#enable-unsafe-webgpu
.
Dans Dawn, un nouveau bouton d'activation/de désactivation de l'appareil appelé "timestamp_quantization" a été ajoutée et est activée par défaut. L'extrait de code suivant vous montre comment autoriser la requête expérimentale "timestamp-query" sans quantification de code temporel lors de la demande d'un appareil.
wgpu::DawnTogglesDescriptor deviceTogglesDesc = {};
const char* allowUnsafeApisToggle = "allow_unsafe_apis";
deviceTogglesDesc.enabledToggles = &allowUnsafeApisToggle;
deviceTogglesDesc.enabledToggleCount = 1;
const char* timestampQuantizationToggle = "timestamp_quantization";
deviceTogglesDesc.disabledToggles = ×tampQuantizationToggle;
deviceTogglesDesc.disabledToggleCount = 1;
wgpu::DeviceDescriptor desc = {.nextInChain = &deviceTogglesDesc};
// Request a device with no timestamp quantization.
myAdapter.RequestDevice(&desc, myCallback, myUserData);
Fonctionnalités de nettoyage de printemps
La requête expérimentale "timestamp-query-inside-passes" La fonctionnalité a été renommée "chromium-experimental-timestamp-query-inside-passes" pour indiquer clairement aux développeurs que cette fonctionnalité est expérimentale et disponible uniquement dans les navigateurs basés sur Chromium pour le moment. Voir issue dawn:1193.
La requête expérimentale "pipeline-statistics-query" qui n'a été que partiellement implémentée, a été supprimée, car elle n'est plus en cours de développement. Consultez le problème chromium:1177506.
Cette présentation ne porte que sur certains points clés. Consultez la liste exhaustive des commits.
Nouveautés de WebGPU
Liste de tous les sujets abordés dans la série Nouveautés de WebGPU
Chrome 127
- Compatibilité expérimentale avec OpenGL ES sur Android
- Attribut d'informations GPUAdapter
- Améliorations de l'interopérabilité de WebAssembly
- Amélioration des erreurs liées à l'encodeur de commande
- Informations sur l'aube
Chrome 126
- Augmentation de la limite maxTextureArrayLayers
- Optimisation de l'importation de tampon pour le backend Vulkan
- Amélioration du temps de compilation des nuanceurs
- Les tampons de commande envoyés doivent être uniques
- Informations sur l'aube
Chrome 125
- Sous-groupes (fonctionnalité en cours de développement)
- Effectuer le rendu d'une tranche de texture 3D
- Informations sur l'aube
Chrome 124
- Textures de stockage en lecture seule et en lecture/écriture
- Assistance pour les service workers et les workers partagés
- Nouveaux attributs d'informations sur l'adaptateur
- Corrections de bugs
- Informations sur l'aube
Chrome 123
- Fonctions intégrées DP4a dans WGSL
- Paramètres de pointeur sans restriction dans WGSL
- Syntaxe sucré pour déréférencer les composites dans WGSL
- État de lecture seule distinct pour les aspects de pochoir et de profondeur
- Informations sur l'aube
Chrome 122
- Élargir la couverture avec le mode de compatibilité (fonctionnalité en développement)
- Augmenter la limite maximale de VertexAttributes
- Informations sur l'aube
Chrome 121
- Compatibilité avec WebGPU sur Android
- Utiliser DXC au lieu de FXC pour la compilation du nuanceur sous Windows
- Requêtes d'horodatage dans les passes de calcul et de rendu
- Points d'entrée par défaut des modules de nuanceurs
- Prise en charge de display-p3 en tant qu'espace colorimétrique GPUExternalTexture
- Informations sur les tas de mémoire
- Informations sur l'aube
Chrome 120
- Compatibilité avec les valeurs à virgule flottante 16 bits dans WGSL
- Repoussez les limites
- Modifications apportées à l'état de profondeur au stencil
- Mises à jour des informations sur l'adaptateur
- Quantification des requêtes d'horodatage
- Fonctionnalités de nettoyage de printemps
Chrome 119
- Textures de float 32 bits filtrables
- Format de sommet unorm10-10-10-2
- rgb10a2uint format de texture
- Informations sur l'aube
Chrome 118
- Compatibilité avec HTMLImageElement et ImageData dans
copyExternalImageToTexture()
- Compatibilité expérimentale avec les textures de stockage en lecture/écriture et en lecture seule
- Informations sur l'aube
Chrome 117
- Tampon de sommets non défini
- Désactiver le groupe de liaisons
- Couper le son des erreurs liées à la création d'un pipeline asynchrone en cas de perte de l'appareil
- Modifications apportées à la création du module de nuanceur SPIR-V
- Améliorer l'expérience des développeurs
- Mettre en cache des pipelines avec une mise en page générée automatiquement
- Informations sur l'aube
Chrome 116
- Intégration de WebCodecs
- Appareil perdu renvoyé par GPUAdapter
requestDevice()
- Maintenir une lecture vidéo fluide si
importExternalTexture()
est appelé - Conformité des spécifications
- Améliorer l'expérience des développeurs
- Informations sur l'aube
Chrome 115
- Extensions de langage WGSL compatibles
- Compatibilité expérimentale avec Direct3D 11
- Utiliser un GPU distinct par défaut sur secteur
- Améliorer l'expérience des développeurs
- Informations sur l'aube
Chrome 114
- Optimiser JavaScript
- getCurrentTexture() sur un canevas non configuré génère InvalidStateError
- Informations concernant WGSL
- Informations sur l'aube