Compatibilidade com valores de ponto flutuante de 16 bits na WGSL
Na WGSL, o tipo f16
(link em inglês) é o conjunto de valores de ponto flutuante de 16 bits do formato IEEE-754 binary16 (meia precisão). Isso significa que ele usa 16 bits para representar um número de ponto flutuante, em oposição a 32 bits para um ponto flutuante de precisão única convencional (f32
). Esse tamanho menor pode gerar melhorias significativas de desempenho, especialmente ao processar grandes quantidades de dados.
Para comparar, em um dispositivo Apple M1 Pro, a implementação de f16
dos modelos Llama2 7B usados na demonstração de chat do WebLLM é significativamente mais rápida do que a implementação do f32
, com uma melhoria de 28% na velocidade de preenchimento automático e de 41% na velocidade de decodificação, conforme mostrado nas capturas de tela a seguir.
![Captura de tela das demonstrações de chat do WebLLM com modelos f32 e f16 Llama2 7B.](https://developer.chrome.google.cn/static/blog/new-in-webgpu-120/image/webllm-chat-demos.png?authuser=6&hl=pt)
f32
(à esquerda) e f16
(à direita).Nem todas as GPUs são compatíveis com valores de ponto flutuante de 16 bits. Quando o recurso "shader-f16"
estiver disponível em um GPUAdapter
, será possível solicitar um GPUDevice
com esse recurso e criar um módulo de shader da WGSL que use o tipo de ponto flutuante de meia precisão f16
. Esse tipo só será válido para uso no módulo de sombreador da WGSL se você ativar a extensão f16
WGSL com enable f16;
. Caso contrário, createShaderModule() vai gerar um erro de validação. Confira o exemplo mínimo a seguir e o problema dawn:1510 (link em inglês).
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...
É possível oferecer suporte aos tipos f16
e f32
no código do módulo de sombreador da WGSL com um alias
, dependendo do suporte ao recurso "shader-f16"
, conforme mostrado no snippet a seguir.
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);
}
`;
Supere os limites
Por padrão, o número máximo de bytes necessários para armazenar uma amostra (pixel ou subpixel) de dados de saída do pipeline de renderização em todos os anexos coloridos é de 32 bytes. Agora é possível solicitar até 64 usando o limite maxColorAttachmentBytesPerSample
. Confira o exemplo a seguir e o problema dawn:2036 (link em inglês).
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 },
});
Os limites de maxInterStageShaderVariables
e maxInterStageShaderComponents
usados para a comunicação entre estágios foram aumentados em todas as plataformas. Consulte o problema dawn:1448 para saber mais.
Para cada estágio do shader, o número máximo de entradas de layout do grupo de vinculação em um layout de pipeline que são buffers de armazenamento é 8 por padrão. Agora é possível solicitar até 10 usando o limite maxStorageBuffersPerShaderStage
. Consulte o problema dawn:2159.
Um novo limite de maxBindGroupsPlusVertexBuffers
foi adicionado. Ele consiste no número máximo de slots de buffer de vértice e grupo de vinculação usados simultaneamente, contando os slots vazios abaixo do índice mais alto. O valor padrão é 24. Consulte o problema dawn:1849 (link em inglês).
Alterações no estado de profundidade do estêncil
Para melhorar a experiência do desenvolvedor, os atributos de estado de estêncil depthWriteEnabled
e depthCompare
não são mais sempre necessários: depthWriteEnabled
é necessário apenas para formatos com profundidade, e depthCompare
não é necessário para formatos com profundidade, caso não sejam usados. Consulte o problema dawn:2132.
Atualizações de informações do adaptador
Os atributos de informações do adaptador type
e backend
não padrão agora estão disponíveis ao chamar requestAdapterInfo() quando o usuário ativa os "Recursos do desenvolvedor WebGPU". sinalização às chrome://flags/#enable-webgpu-developer-features
. O type
pode ser "GPU discreta", "GPU integrada", "CPU" ou "desconhecida". O backend
é "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" ou "null". Consulte issue dawn:2112 e issue dawn:2107.
![Captura de tela de https://webgpureport.org mostrando back-end e tipo de informações do adaptador.](https://developer.chrome.google.cn/static/blog/new-in-webgpu-120/image/webgpureport.png?authuser=6&hl=pt)
O parâmetro da lista unmaskHints
opcional em requestAdapterInfo() foi removido. Consulte o problema dawn:1427.
Quantização de consultas de carimbo de data/hora
As consultas de carimbo de data/hora permitem que os aplicativos meçam o tempo de execução dos comandos da GPU com precisão de nanossegundos. No entanto, a especificação da WebGPU torna as consultas de carimbo de data/hora opcionais devido a preocupações de ataque de tempo. A equipe do Chrome acredita que a quantização de consultas de carimbo de data/hora oferece um bom meio-termo entre precisão e segurança, reduzindo a resolução para 100 microssegundos. Consulte o problema dawn:1800.
No Chrome, os usuários podem desativar a quantização de carimbo de data/hora ativando os "Recursos para desenvolvedores WebGPU". flag em chrome://flags/#enable-webgpu-developer-features
. Essa sinalização por si só não ativa o recurso "timestamp-query"
. Sua implementação ainda é experimental e, portanto, exige o "Suporte à WebGPU não segura" em chrome://flags/#enable-unsafe-webgpu
.
No Dawn, uma nova alternância de dispositivo chamada "timestamp_quantization" foi adicionado e é ativado por padrão. O snippet a seguir mostra como permitir o teste "timestamp-query" experimental sem quantização de carimbo de data/hora ao solicitar um dispositivo.
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);
Recursos para fazer faxina
A técnica experimental "timestamp-query-inside-passes" foi renomeado como "chromium-experimental-timestamp-query-inside-passes". para deixar claro para os desenvolvedores que, por enquanto, esse recurso é experimental e está disponível apenas em navegadores baseados no Chromium. Consulte o problema dawn:1193 (link em inglês).
A ferramenta experimental "pipeline-statistics-query" , que foi apenas parcialmente implementado, foi removido porque não está mais sendo desenvolvido. Consulte issue chromium:1177506.
Isso cobre apenas alguns dos principais destaques. Confira a lista completa de confirmações (link em inglês).
Novidades da WebGPU
Uma lista de tudo o que foi abordado na série O que há de novo na WebGPU.
Chrome 127
- Suporte experimental para OpenGL ES no Android
- Atributo de informações do GPUAdapter
- Melhorias na interoperabilidade do WebAssembly
- Erros aprimorados do codificador de comando
- Atualizações do amanhecer
Chrome 126
- Aumentar o limite de maxTextureArrayLayers
- Otimização do upload de buffer para back-end do Vulkan
- Melhorias no tempo de compilação do sombreador
- Os buffers de comando enviados precisam ser exclusivos
- Atualizações do amanhecer
Chrome 125
- Subgrupos (recurso em desenvolvimento)
- Renderizar uma fração de textura 3D
- Atualizações do amanhecer
Chrome 124
- Texturas de armazenamento somente leitura e leitura/gravação
- Suporte aos service workers e workers compartilhados
- Novos atributos de informações do adaptador
- Correções de bugs
- Atualizações do amanhecer
Chrome 123
- Suporte para funções integradas do DP4a na WGSL
- Parâmetros de ponteiro irrestritos na WGSL
- Sintaxe de açúcar para desreferenciar compostos na WGSL (link em inglês)
- Estado somente leitura separado para aspectos de estêncil e de profundidade
- Atualizações do amanhecer
Chrome 122
- Expandir o alcance com o modo de compatibilidade (recurso em desenvolvimento)
- Aumentar o limite de maxVertexAttributes
- Atualizações do amanhecer
Chrome 121
- Suporte à WebGPU no Android
- Usar DXC em vez de FXC para compilação de sombreador no Windows
- Consultas de carimbo de data/hora em passagens de computação e renderização
- Pontos de entrada padrão para módulos de sombreador
- Suporte a display-p3 como espaço de cores GPUExternalTexture
- Informações sobre heaps de memória
- Atualizações do amanhecer
Chrome 120
- Suporte para valores de ponto flutuante de 16 bits na WGSL
- Supere os limites
- Mudanças no estado de profundidade do estêncil
- Atualizações de informações sobre os adaptadores
- Quantização de consultas de carimbo de data/hora
- Recursos para fazer faxina
Chrome 119
- Texturas flutuantes filtráveis de 32 bits
- Formato de vértice unorm10-10-10-2
- Formato de textura rgb10a2uint
- Atualizações do amanhecer
Chrome 118
- Compatibilidade de HTMLImageElement e ImageData em
copyExternalImageToTexture()
- Suporte experimental à textura de armazenamento somente leitura e leitura-gravação
- Atualizações do amanhecer
Chrome 117
- Não definir buffer de vértice
- Cancelar configuração do grupo de vinculação
- Silenciar erros da criação de pipeline assíncrono quando o dispositivo for perdido
- Atualizações da criação do módulo de sombreador SPIR-V
- Como melhorar a experiência do desenvolvedor
- Pipelines em cache com layout gerado automaticamente
- Atualizações do amanhecer
Chrome 116
- Integração com WebCodecs
- Dispositivo perdido retornado pelo GPUAdapter
requestDevice()
- Manter a reprodução de vídeo suave se
importExternalTexture()
for chamado - Conformidade com especificações
- Como melhorar a experiência do desenvolvedor
- Atualizações do amanhecer
Chrome 115
- Extensões de idiomas da WGSL compatíveis
- Suporte experimental para Direct3D 11
- Receber uma GPU discreta por padrão com alimentação CA
- Como melhorar a experiência do desenvolvedor
- Atualizações do amanhecer
Chrome 114
- Otimizar o JavaScript
- getCurrentTexture() em uma tela não configurada gera InvalidStateError
- Atualizações da WGSL
- Atualizações do amanhecer