Novidades da WebGPU (Chrome 133)

François Beaufort
François Beaufort
GitHub

Publicado em 29 de janeiro de 2025

Formatos de vértice de 1 componente e unorm8x4-bgra adicionais

O formato de vértice "unorm8x4-bgra" e os seguintes formatos de vértice de um componente foram adicionados: "uint8", "sint8", "unorm8", "snorm8", "uint16", "sint16", "unorm16", "snorm16" e "float16". O formato de vértice "unorm8x4-bgra" torna um pouco mais conveniente carregar cores de vértice codificadas em BGRA, mantendo o mesmo sombreador. Além disso, o formato de vértice de um componente permite solicitar apenas os dados necessários, quando antes era necessário pelo menos o dobro para tipos de dados de 8 e 16 bits. Consulte a entrada do chromestatus e o problema 376924407.

Permitir que limites desconhecidos sejam solicitados com valor indefinido

Para tornar a API WebGPU menos frágil à medida que ela evolui, agora é possível solicitar limites desconhecidos com o valor undefined ao solicitar um dispositivo de GPU. Isso é útil no código do aplicativo abaixo, por exemplo, em que adapter.limits.someLimit pode ser undefined se someLimit não existir mais. Consulte spec PR 4781.

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

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

Mudanças nas regras de alinhamento do WGSL

Não é mais possível fornecer um valor de alinhamento muito pequeno para um membro de struct, já que agora é necessário que @align(n) divida RequiredAlignOf para todos os structs. Essa mudança importante simplifica o uso da linguagem WGSL e a torna mais compatível com o Firefox e o Safari. Confira um exemplo de código mostrando as diferenças entre os compiladores Tint, Naga e WebKit no spec PR.

Ganhos de desempenho do WGSL com descarte

Devido a uma queda significativa no desempenho observada ao renderizar um efeito complexo de reflexos de tela (SSR, na sigla em inglês), a implementação da instrução de descarte usa a semântica fornecida pela plataforma para rebaixar para uma invocação de auxiliar quando disponível. Isso melhora o desempenho dos sombreadores que usam descarte. Consulte o problema 372714384.

Usar displaySize de VideoFrame para texturas externas

As dimensões displayWidth e displayHeight precisam ser usadas como o tamanho aparente da GPUExternalTexture ao importar um VideoFrame de acordo com a especificação da WebGPU. No entanto, o tamanho visível foi usado incorretamente, causando problemas ao tentar usar textureLoad() em uma GPUExternalTexture. Isso já foi corrigido Consulte o problema 377574981.

Processar imagens com orientações não padrão usando copyExternalImageToTexture

O método copyExternalImageToTexture() GPUQueue é usado para copiar o conteúdo de uma imagem ou tela para uma textura. Agora, ele processa corretamente imagens com orientações não padrão. Isso não acontecia antes, quando a origem era um ImageBitmap com imageOrientation "from-image" ou uma imagem com uma orientação diferente do padrão. Consulte o problema 384858956.

Melhorar a experiência do desenvolvedor

Pode ser surpreendente quando adapter.limits mostra valores altos, mas você não percebe que precisa solicitar explicitamente um limite mais alto ao solicitar um dispositivo de GPU. Se isso não for feito, pode haver um limite inesperado mais tarde.

Para ajudar você, as mensagens de erro foram expandidas com dicas que informam a solicitação explícita de um limite maior quando nenhum limite foi especificado em requiredLimits ao chamar requestDevice(). Consulte o problema 42240683.

O exemplo a seguir mostra uma mensagem de erro aprimorada registrada no console do DevTools ao criar um buffer de GPU com um tamanho que excede o limite máximo padrão do dispositivo.

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]).

Ativar o modo de compatibilidade com o featureLevel

Agora é possível solicitar um adaptador de GPU no modo de compatibilidade experimental definindo a opção padronizada featureLevel como "compatibility". As strings "core" (padrão) e "compatibility" são os únicos valores permitidos. Confira o exemplo a seguir e a especificação 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.
}

A opção featureLevel substitui a opção compatibilityMode não padronizada, enquanto o atributo featureLevel não padronizado substitui o atributo isCompatibilityMode.

Como ainda é experimental, é necessário executar o Chrome com a flag "Unsafe WebGPU Support" em chrome://flags/#enable-unsafe-webgpu por enquanto. Confira o webgpureport.org para testar.

Limpeza de recursos de subgrupos experimentais

Os recursos descontinuados do subgrupo experimental "chromium-experimental-subgroups" e "chromium-experimental-subgroup-uniform-control-flow" foram removidos. Consulte o problema 377868468.

O recurso experimental "subgroups" é tudo o que você precisa agora para fazer experimentos com subgrupos. O recurso experimental "subgroups-f16" foi descontinuado e será removido em breve. É possível usar valores f16 com subgrupos quando o aplicativo solicitar recursos "shader-f16" e "subgroups". Consulte o problema 380244620.

O limite maxInterStageShaderComponents foi descontinuado

O limite de maxInterStageShaderComponents foi descontinuado devido a uma combinação de fatores:

  • Redundância com maxInterStageShaderVariables: esse limite já tem uma finalidade semelhante, controlando a quantidade de dados transmitidos entre os estágios do sombreador.
  • Discrepâncias menores: embora haja pequenas diferenças na forma como os dois limites são calculados, essas diferenças são pequenas e podem ser gerenciadas de forma eficaz dentro do limite de maxInterStageShaderVariables.
  • Simplificação: a remoção de maxInterStageShaderComponents simplifica a interface do sombreador e reduz a complexidade para os desenvolvedores. Em vez de gerenciar dois limites separados com diferenças sutis, eles podem se concentrar no maxInterStageShaderVariables mais abrangente e com nome mais apropriado.

O objetivo é removê-lo completamente no Chrome 135. Consulte intenção de descontinuação e problema 364338810.

Atualizações do Dawn

O wgpu::Device::GetAdapterInfo(adapterInfo) permite que você receba informações do adaptador diretamente de um wgpu::Device. Consulte o problema 376600838.

A estrutura WGPUProgrammableStageDescriptor foi renomeada como WGPUComputeState para tornar o estado de computação consistente com os estados de vértice e fragmento. Consulte o problema 379059434.

O valor de tipo enumerado wgpu::VertexStepMode::VertexBufferNotUsed foi removido. Um layout de buffer de vértices que não é usado agora pode ser expresso com {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0}. Consulte o problema 383147017.

Isso abrange apenas alguns dos principais destaques. Confira a lista completa de confirmações.

Novidades na WebGPU

Uma lista de tudo o que foi abordado na série O que há de novo na WebGPU.

Chrome 133

Chrome 132

Chrome 131

Chrome 130

Chrome 129

Chrome 128

Chrome 127

Chrome 126

Chrome 125

Chrome 124

Chrome 123

Chrome 122

Chrome 121

Chrome 120

Chrome 119

Chrome 118

Chrome 117

Chrome 116

Chrome 115

Chrome 114

Chrome 113