Novidades da WebGPU (Chrome 133)

François Beaufort
François Beaufort
GitHub

Publicado em: 29 de janeiro de 2025

Formatos de vértice unorm8x4-bgra e de 1 componente 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" facilita um pouco mais o carregamento de cores de vértice codificadas em BGRA, mantendo o mesmo shader. Além disso, o formato de vértice de um componente permite solicitar apenas os dados necessários, quando antes era preciso 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 evolui, agora é possível solicitar limites desconhecidos com o valor undefined ao solicitar um dispositivo de GPU. Isso é útil no seguinte código de aplicativo, 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 todas as structs. Essa mudança incompatível simplifica o uso da linguagem WGSL e a torna mais compatível com Firefox e Safari. Confira um exemplo de código que mostra as diferenças entre os compiladores Tint, Naga e WebKit na PR de especificação.

Ganhos de performance da WGSL com descarte

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

Usar displaySize do VideoFrame para texturas externas

As dimensões displayWidth e displayHeight devem ser usadas como o tamanho aparente do GPUExternalTexture ao importar um VideoFrame de acordo com a especificação WebGPU. No entanto, o tamanho visível foi usado incorretamente, causando problemas ao tentar usar textureLoad() em um 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 não 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 maior ao pedir um dispositivo de GPU. Se isso não for feito, os limites poderão ser atingidos inesperadamente mais tarde.

Para ajudar você, as mensagens de erro foram expandidas com dicas que informam para solicitar explicitamente 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 melhorada 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 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 o PR 4897 da especificação.

// 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 não padronizada compatibilityMode, enquanto o atributo não padronizado featureLevel substitui o atributo isCompatibilityMode.

Como ainda está em fase experimental, por enquanto, você precisa executar o Chrome com a flag "Unsafe WebGPU Support" em chrome://flags/#enable-unsafe-webgpu. Acesse webgpureport.org para testar.

Limpeza de recursos experimentais de subgrupo

Os recursos experimentais obsoletos de subgrupo "chromium-experimental-subgroups" e "chromium-experimental-subgroup-uniform-control-flow" são removidos. Consulte o problema 377868468.

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

Descontinuar o limite maxInterStageShaderComponents

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 as fases do shader.
  • Pequenas discrepâncias: embora haja pequenas diferenças na forma como os dois limites são calculados, elas são pequenas e podem ser gerenciadas de maneira eficaz dentro do limite de maxInterStageShaderVariables.
  • Simplificação: a remoção de maxInterStageShaderComponents simplifica a interface do shader e reduz a complexidade para os desenvolvedores. Em vez de gerenciar dois limites separados com diferenças sutis, eles podem se concentrar no maxInterStageShaderVariables, que tem um nome mais adequado e é mais abrangente.

A meta é remover totalmente esse recurso no Chrome 135. Consulte intenção de descontinuar e problema 364338810.

Atualizações do amanhecer

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

A struct 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 enumeração wgpu::VertexStepMode::VertexBufferNotUsed foi removido. Um layout de buffer de vértice 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 commits.

Novidades no WebGPU

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

Chrome 140

Chrome 139

Chrome 138

Chrome 137

Chrome 136

Chrome 135

Chrome 134

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