Novedades de WebGPU (Chrome 120)

François Beaufort
François Beaufort
GitHub

Compatibilidad con valores de punto flotante de 16 bits en WGSL

En WGSL, el tipo f16 es el conjunto de valores de punto flotante de 16 bits del formato IEEE-754 binary16 (precisión media). Esto significa que usa 16 bits para representar un número de punto flotante, en lugar de 32 bits para el número de punto flotante convencional de precisión simple (f32). Este tamaño más pequeño puede generar mejoras significativas en el rendimiento, especialmente cuando se procesan grandes cantidades de datos.

A modo de comparación, en un dispositivo Apple M1 Pro, la implementación de f16 de los modelos Llama2 7B que se usa en la demo de chat de WebLLM es significativamente más rápida que la implementación de f32, con una mejora del 28% en la velocidad de prerelleno y una mejora del 41% en la velocidad de decodificación, como se muestra en las siguientes capturas de pantalla.

Captura de pantalla de las demostraciones de chat de WebLLM con modelos Llama2 7B de f32 y f16.
Demostraciones de chat de WebLLM con modelos Llama2 7B de f32 (izquierda) y f16 (derecha).

No todas las GPU admiten valores de punto flotante de 16 bits. Cuando la función "shader-f16" esté disponible en un GPUAdapter, ahora puedes solicitar un GPUDevice con esta función y crear un módulo de sombreador WGSL que aproveche el tipo de punto flotante de precisión media f16. Este tipo es válido para usar en el módulo de sombreador WGSL solo si habilitas la extensión f16 WGSL con enable f16;. De lo contrario, createShaderModule() generará un error de validación. Consulta el siguiente ejemplo mínimo y problema 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...

Es posible admitir los tipos f16 y f32 en el código del módulo del sombreador WGSL con un alias, según la compatibilidad con la función "shader-f16", como se muestra en el siguiente fragmento.

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

Supera los límites

La cantidad máxima de bytes necesarios para contener una muestra (píxel o subpíxel) de datos de salida de la canalización de renderización, en todos los archivos adjuntos de color, es de 32 bytes de forma predeterminada. Ahora es posible solicitar hasta 64 con el límite de maxColorAttachmentBytesPerSample. Consulta el siguiente ejemplo y 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 },
});

Se aumentaron los límites de maxInterStageShaderVariables y maxInterStageShaderComponents que se usan para la comunicación entre etapas en todas las plataformas. Consulta problema dawn:1448 para obtener más detalles.

Para cada etapa del sombreador, la cantidad máxima de entradas de diseño de grupo de vinculación en un diseño de canalización que son búferes de almacenamiento es de 8 de forma predeterminada. Ahora es posible solicitar hasta 10 con el límite de maxStorageBuffersPerShaderStage. Consulta el problema dawn:2159.

Se agregó un nuevo límite de maxBindGroupsPlusVertexBuffers. Consiste en la cantidad máxima de ranuras de grupo de vinculación y búfer de vértices que se usan de forma simultánea, y se cuentan las ranuras vacías debajo del índice más alto. Su valor predeterminado es 24. Consulta el problema dawn:1849.

Cambios en el estado del búfer de profundidad

Para mejorar la experiencia del desarrollador, ya no siempre se requieren los atributos de estado de la máscara de profundidad depthWriteEnabled y depthCompare: depthWriteEnabled solo es obligatorio para los formatos con profundidad, y depthCompare no es obligatorio para los formatos con profundidad si no se usan. Consulta el problema dawn:2132.

Actualizaciones de la información del adaptador

Los atributos de información del adaptador type y backend no estándar ahora están disponibles cuando se llama a requestAdapterInfo() si el usuario habilitó la marca "WebGPU Developer Features" en chrome://flags/#enable-webgpu-developer-features. type puede ser “GPU discreta”, “GPU integrada”, “CPU” o “desconocida”. backend es "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" o "null". Consulta problema dawn:2112 y problema dawn:2107.

Captura de pantalla de https://webgpureport.org que muestra el backend y el tipo de información del adaptador.
El backend y el tipo de información del adaptador se muestran en https://webgpureport.org.

Se quitó el parámetro de lista opcional unmaskHints en requestAdapterInfo(). Consulta el problema dawn:1427.

Cuantización de consultas de marca de tiempo

Las consultas de marca de tiempo permiten que las aplicaciones midan el tiempo de ejecución de los comandos de la GPU con precisión de nanosegundos. Sin embargo, la especificación de WebGPU hace que las consultas de marca de tiempo sean opcionales debido a las preocupaciones sobre los ataques de sincronización. El equipo de Chrome cree que la cuantificación de las consultas de marca de tiempo proporciona un buen compromiso entre precisión y seguridad, ya que reduce la resolución a 100 microsegundos. Consulta problema dawn:1800.

En Chrome, los usuarios pueden inhabilitar la cuantización de la marca de tiempo habilitando la marca “Funciones para desarrolladores de WebGPU” en chrome://flags/#enable-webgpu-developer-features. Ten en cuenta que esta marca por sí sola no habilita la función "timestamp-query". Su implementación aún es experimental y, por lo tanto, requiere la marca "Compatibilidad no segura con WebGPU" en chrome://flags/#enable-unsafe-webgpu.

En Dawn, se agregó un nuevo interruptor de dispositivo llamado "timestamp_quantization", que está habilitado de forma predeterminada. En el siguiente fragmento, se muestra cómo permitir la función experimental "timestamp-query" sin cuantificación de marca de tiempo cuando se solicita un dispositivo.

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

Funciones de limpieza de primavera

Se cambió el nombre de la función experimental "timestamp-query-inside-passes" a "chromium-experimental-timestamp-query-inside-passes" para aclarar a los desarrolladores que esta función es experimental y, por el momento, solo está disponible en navegadores basados en Chromium. Consulta el problema dawn:1193.

Se quitó la función experimental "pipeline-statistics-query", que solo se implementó de forma parcial, porque ya no se está desarrollando. Consulta el problema chromium:1177506.

Esto solo abarca algunos de los aspectos más destacados. Consulta la lista exhaustiva de confirmaciones.

Novedades de WebGPU

Una lista de todo lo que se analizó en la serie Novedades de WebGPU.

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