Deze pagina is vertaald door de Cloud Translation API.

Wat is er nieuw in WebGPU (Chrome 133)

François Beaufort

Gepubliceerd: 29 januari 2025

Aanvullende unorm8x4-bgra- en 1-component-vertexformaten

Het vertexformaat "unorm8x4-bgra" en de volgende 1-component vertexformaten zijn toegevoegd: "uint8" , "sint8" , "unorm8" , "snorm8" , "uint16" , "sint16" , "unorm16" , "snorm16" en "float16" . Het vertexformaat "unorm8x4-bgra" maakt het iets gemakkelijker om BGRA-gecodeerde vertexkleuren te laden met behoud van dezelfde shader. Bovendien kunt u met het 1-component vertexformaat alleen de benodigde gegevens opvragen, terwijl voorheen minstens twee keer zoveel gegevens nodig waren voor 8- en 16-bits gegevenstypen. Zie de chromestatus-pagina en issue 376924407 .

Sta toe dat onbekende limieten worden aangevraagd met een ongedefinieerde waarde.

Om de WebGPU API minder kwetsbaar te maken naarmate deze zich verder ontwikkelt, kunt u nu onbekende limieten met een undefined waarde aanvragen bij het aanvragen van een GPU-apparaat. Dit is bijvoorbeeld handig in de volgende applicatiecode, waar adapter.limits.someLimit undefined kan zijn als someLimit niet meer bestaat. Zie specificatie PR 4781 .

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Wijzigingen in de WGSL-uitlijningsregels

Het is niet langer mogelijk om een te kleine uitlijningswaarde voor een structlid op te geven, omdat nu vereist is dat @align(n) RequiredAlignOf deelt voor alle structs. Deze ingrijpende wijziging vereenvoudigt het gebruik van de WGSL-taal en maakt deze beter compatibel met Firefox en Safari. Voorbeeldcode die de verschillen tussen Tint-, Naga- en WebKit-compilers laat zien, is te vinden in de specificatie-PR .

WGSL-prestatieverbeteringen met discard-effect

Vanwege een aanzienlijke prestatievermindering die werd waargenomen bij het renderen van een complex schermruimte-reflectie-effect (SSR), gebruikt de implementatie van de discard-instructie de door het platform geleverde semantiek om, indien beschikbaar, de functie te degraderen tot een hulpfunctie. Dit verbetert de prestaties van shaders die discard gebruiken. Zie issue 372714384 .

Gebruik VideoFrame displaySize voor externe texturen.

Volgens de WebGPU-specificatie moeten de afmetingen displayWidth en displayHeight worden gebruikt als de schijnbare grootte van de GPUExternalTexture bij het importeren van een VideoFrame. Echter, de zichtbare grootte werd onjuist gebruikt, wat problemen veroorzaakte bij het gebruik van textureLoad() op een GPUExternalTexture. Dit is nu opgelost. Zie issue 377574981 .

Verwerk afbeeldingen met een niet-standaardoriëntatie met behulp van copyExternalImageToTexture.

De GPUQueue-methode copyExternalImageToTexture() wordt gebruikt om de inhoud van een afbeelding of canvas naar een textuur te kopiëren. Deze methode verwerkt nu correct afbeeldingen met een niet-standaardoriëntatie. Dit was voorheen niet het geval wanneer de bron een ImageBitmap was met imageOrientation "from-image" of een afbeelding met een niet-standaardoriëntatie. Zie probleem 384858956 .

Verbetering van de ontwikkelaarservaring

Het kan verrassend zijn wanneer adapter.limits hoge waarden weergeeft, terwijl je je niet realiseert dat je expliciet een hogere limiet moet aanvragen bij het toewijzen van een GPU-apparaat. Als je dit niet doet, kan dit later onverwacht tot limietoverschrijdingen leiden.

Om u te helpen, zijn de foutmeldingen uitgebreid met hints die aangeven dat u expliciet een hogere limiet moet aanvragen wanneer er geen limiet is opgegeven in requiredLimits bij het aanroepen requestDevice() . Zie probleem 42240683 .

Het volgende voorbeeld toont een verbeterd foutbericht dat wordt weergegeven in de DevTools-console wanneer een GPU-buffer wordt aangemaakt met een grootte die de standaard maximale buffergrootte van het apparaat overschrijdt.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);

⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Schakel de compatibiliteitsmodus in met featureLevel.

Het aanvragen van een GPU-adapter in de experimentele compatibiliteitsmodus is nu mogelijk door de gestandaardiseerde featureLevel optie in te stellen op "compatibility" . Alleen de tekenreeksen "core" (standaard) en "compatibility" zijn toegestaan. Zie het volgende voorbeeld en specificatie PR 4897 .

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

De optie featureLevel vervangt de niet-gestandaardiseerde optie compatibilityMode , terwijl het niet-gestandaardiseerde attribuut featureLevel het attribuut isCompatibilityMode vervangt.

Omdat het nog experimenteel is, moet je Chrome voorlopig uitvoeren met de vlag "Unsafe WebGPU Support" ingeschakeld via chrome://flags/#enable-unsafe-webgpu . Kijk op webgpureport.org om ermee te experimenteren.

Opschoning van experimentele subgroepfuncties

De verouderde experimentele subgroepfuncties "chromium-experimental-subgroups" en "chromium-experimental-subgroup-uniform-control-flow" zijn verwijderd. Zie probleem 377868468 .

De experimentele functie "subgroups" is momenteel alles wat je nodig hebt om met subgroepen te experimenteren . De experimentele functie "subgroups-f16" is verouderd en zal binnenkort worden verwijderd. Je kunt f16-waarden gebruiken met subgroepen wanneer je applicatie zowel de functies "shader-f16" als "subgroups" vereist. Zie issue 380244620 .

De limiet maxInterStageShaderComponents wordt afgeschaft.

De limiet maxInterStageShaderComponents is afgeschaft vanwege een combinatie van factoren:

Redundantie met maxInterStageShaderVariables : Deze limiet dient al een vergelijkbaar doel, namelijk het beheersen van de hoeveelheid gegevens die tussen shaderfasen wordt doorgegeven.
Kleine verschillen: Hoewel er kleine verschillen zijn in de manier waarop de twee limieten worden berekend, zijn deze verschillen gering en kunnen ze effectief worden beheerd binnen de maxInterStageShaderVariables -limiet.
Vereenvoudiging: Het verwijderen van maxInterStageShaderComponents stroomlijnt de shader-interface en vermindert de complexiteit voor ontwikkelaars. In plaats van twee afzonderlijke limieten met subtiele verschillen te beheren, kunnen ze zich concentreren op de beter benoemde en uitgebreidere maxInterStageShaderVariables .

Het is de bedoeling om deze functie volledig te verwijderen in Chrome 135. Zie het voornemen tot afschaffing en issue 364338810 .

Dawn-updates

Met wgpu::Device::GetAdapterInfo(adapterInfo) kunt u rechtstreeks adapterinformatie van een wgpu::Device verkrijgen. Zie probleem 376600838 .

De struct WGPUProgrammableStageDescriptor is hernoemd naar WGPUComputeState om de rekenstatus consistent te maken met de vertex- en fragmentstatussen. Zie issue 379059434 .

De enum-waarde wgpu::VertexStepMode::VertexBufferNotUsed is verwijderd. Een vertexbuffer-layout die niet in gebruik is, kan nu worden weergegeven met {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} . Zie issue 383147017 .

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