Deze pagina is vertaald door de Cloud Translation API.

Wat is er nieuw in WebGPU (Chrome 120)

François Beaufort

Ondersteuning voor 16-bits drijvende-kommawaarden in WGSL

In WGSL is het f16 type de set van 16-bits drijvende-kommawaarden van het IEEE-754 binary16-formaat (halfprecisie). Dit betekent dat het 16 bits gebruikt om een drijvende-kommawaarde weer te geven, in tegenstelling tot 32 bits voor conventionele drijvende-kommawaarden met enkelvoudige precisie ( f32 ). Deze kleinere omvang kan leiden tot aanzienlijke prestatieverbeteringen , met name bij het verwerken van grote hoeveelheden data.

Ter vergelijking: op een Apple M1 Pro-apparaat is de f16 implementatie van de Llama2 7B-modellen die in de WebLLM-chatdemo worden gebruikt, aanzienlijk sneller dan de f32 implementatie, met een verbetering van 28% in de voorvulsnelheid en een verbetering van 41% in de decodeersnelheid, zoals te zien is in de volgende schermafbeeldingen.

Screenshot van WebLLM-chatdemo's met de Llama2 7B-modellen f32 en f16. — WebLLM-chatdemonstraties met de Llama2 7B-modellen `f32` (links) en `f16` (rechts).

Niet alle GPU's ondersteunen 16-bits drijvende-kommawaarden. Wanneer de functie "shader-f16" beschikbaar is in een GPUAdapter , kunt u nu een GPUDevice met deze functie aanvragen en een WGSL-shadermodule maken die gebruikmaakt van het halfprecisie drijvende-kommatype f16 . Dit type is alleen geldig voor gebruik in de WGSL-shadermodule als u de f16 WGSL-extensie inschakelt met enable f16; Anders genereert createShaderModule() een validatiefout. Zie het volgende minimale voorbeeld en issue 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...

Het is mogelijk om zowel f16 als f32 typen te ondersteunen in de WGSL-shadermodulecode met een alias , afhankelijk van de ondersteuning van de "shader-f16" -functie, zoals in het volgende codefragment wordt getoond.

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);
  }
`;

Verleg de grenzen

Het maximale aantal bytes dat nodig is om één sample (pixel of subpixel) van de uitvoergegevens van de renderpipeline op te slaan, voor alle kleurbijlagen, is standaard 32 bytes. Het is nu mogelijk om tot 64 bytes aan te vragen door de limiet maxColorAttachmentBytesPerSample te gebruiken. Zie het volgende voorbeeld en issue 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 },
});

De limieten maxInterStageShaderVariables en maxInterStageShaderComponents die worden gebruikt voor communicatie tussen de verschillende fases zijn op alle platforms verhoogd. Zie issue dawn:1448 voor meer informatie.

Voor elke shaderfase is het maximale aantal bind group layout entries over een pipeline layout die storage buffers zijn, standaard 8. Het is nu mogelijk om tot 10 aan te vragen door de limiet maxStorageBuffersPerShaderStage te gebruiken. Zie issue dawn:2159 .

Er is een nieuwe limiet voor maxBindGroupsPlusVertexBuffers toegevoegd. Deze limiet bestaat uit het maximale aantal bind- en vertexbuffer-slots dat gelijktijdig gebruikt kan worden, inclusief eventuele lege slots onder de hoogste index. De standaardwaarde is 24. Zie issue dawn:1849 .

Wijzigingen in de diepte-sjabloonstatus

Om de ontwikkelaarservaring te verbeteren, zijn de attributen depthWriteEnabled en depthCompare van de depth-stencilstatus niet langer altijd vereist: depthWriteEnabled is alleen vereist voor formaten met diepte, en depthCompare is niet vereist voor formaten met diepte als deze helemaal niet worden gebruikt. Zie issue dawn:2132 .

Updates van adapterinformatie

Niet-standaard type en backend -adapterinformatie-attributen zijn nu beschikbaar bij het aanroepen van requestAdapterInfo() wanneer de gebruiker de vlag "WebGPU Developer Features" heeft ingeschakeld via chrome://flags/#enable-webgpu-developer-features . Het type kan "discrete GPU", "integrated GPU", "CPU" of "unknown" zijn. De backend kan "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" of "null" zijn. Zie issue dawn:2112 en issue dawn:2107 .

Screenshot van https://webgpureport.org met backend- en type-in-adapterinformatie. — Adapterinformatie, backend en type worden weergegeven op https://webgpureport.org .

De optionele parameter unmaskHints in de lijst in `requestAdapterInfo()` is verwijderd. Zie issue dawn:1427 .

Tijdstempelquery's kwantisering

Met behulp van tijdstempelquery's kunnen applicaties de uitvoeringstijd van GPU-opdrachten met nanosecondeprecisie meten. De WebGPU-specificatie maakt tijdstempelquery's echter optioneel vanwege de risico's op timingaanvallen . Het Chrome-team is van mening dat het kwantificeren van tijdstempelquery's een goed compromis biedt tussen precisie en beveiliging, door de resolutie te verlagen naar 100 microseconden. Zie issue dawn:1800 .

In Chrome kunnen gebruikers tijdstempelkwantisatie uitschakelen door de vlag "WebGPU Developer Features" in te schakelen via chrome://flags/#enable-webgpu-developer-features . Houd er rekening mee dat deze vlag op zichzelf de "timestamp-query" -functie niet inschakelt. De implementatie hiervan is nog experimenteel en vereist daarom de vlag "Unsafe WebGPU Support" via chrome://flags/#enable-unsafe-webgpu .

In Dawn is een nieuwe apparaatschakelaar genaamd "timestamp_quantization" toegevoegd, die standaard is ingeschakeld. Het volgende codefragment laat zien hoe u de experimentele "timestamp-query"-functie zonder tijdstempelkwantisering kunt inschakelen bij het opvragen van een apparaat.

wgpu::DawnTogglesDescriptor deviceTogglesDesc = {};

const char* allowUnsafeApisToggle = "allow_unsafe_apis";
deviceTogglesDesc.enabledToggles = &allowUnsafeApisToggle;
deviceTogglesDesc.enabledToggleCount = 1;

const char* timestampQuantizationToggle = "timestamp_quantization";
deviceTogglesDesc.disabledToggles = &timestampQuantizationToggle;
deviceTogglesDesc.disabledToggleCount = 1;

wgpu::DeviceDescriptor desc = {.nextInChain = &deviceTogglesDesc};

// Request a device with no timestamp quantization.
myAdapter.RequestDevice(&desc, myCallback, myUserData);

Kenmerken van de voorjaarsschoonmaak

De experimentele functie "timestamp-query-inside-passes" is hernoemd naar "chromium-experimental-timestamp-query-inside-passes" om ontwikkelaars duidelijk te maken dat deze functie experimenteel is en voorlopig alleen beschikbaar is in browsers die op Chromium gebaseerd zijn. Zie issue dawn:1193 .

De experimentele functie "pipeline-statistics-query", die slechts gedeeltelijk was geïmplementeerd, is verwijderd omdat de ontwikkeling ervan is stopgezet. Zie issue chromium:1177506 .

Dit is slechts een greep uit de belangrijkste hoogtepunten. Bekijk de volledige lijst met commits .