Se usó la API de Cloud Translation para traducir esta página.

Novedades de WebGPU (Chrome 120)

François Beaufort

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 los 32 bits del punto flotante de precisión simple convencional (f32). Este tamaño más pequeño puede generar mejoras significativas en el rendimiento, en especial 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 usan en la demostración 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 prellenado 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 los modelos Llama2 7B de f32 y f16. — Demostraciones de chat de WebLLM con los modelos de Llama2 7B `f32` (izquierda) y `f16` (derecha).

No todas las GPUs 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 media precisión f16. Este tipo solo es válido para usar en el módulo de sombreador WGSL si habilitas la extensión f16 de WGSL con enable f16;. De lo contrario, createShaderModule() generará un error de validación. Consulta el siguiente ejemplo mínimo y el 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 de 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 almacenar una muestra (píxel o subpíxel) de los datos de salida de la canalización de renderización, en todos los 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 emite 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 el problema dawn:1448 para obtener más detalles.

Para cada etapa del sombreador, la cantidad máxima de entradas de diseño de grupos 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 búfer de vértices y grupos de vinculación que se usan de forma simultánea, y se incluyen las ranuras vacías por debajo del índice más alto. Su valor predeterminado es 24. Consulta el problema dawn:1849.

Cambios en el estado de profundidad y stencil

Para mejorar la experiencia del desarrollador, los atributos de estado de profundidad y estencil depthWriteEnabled y depthCompare ya no siempre son necesarios: depthWriteEnabled solo se requiere para los formatos con profundidad, y depthCompare no se requiere para los formatos con profundidad si no se usa en absoluto. 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 "Funciones para desarrolladores de WebGPU" en chrome://flags/#enable-webgpu-developer-features. El valor de type puede ser "discrete GPU", "integrated GPU", "CPU" o "unknown". backend puede ser "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" o "null". Consulta los problemas dawn:2112 y dawn:2107.

Captura de pantalla de https://webgpureport.org que muestra información sobre el backend y el tipo en el adaptador. — Se muestran el backend y el tipo de adaptador en https://webgpureport.org.

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

Cuantificación de consultas de marcas de tiempo

Las consultas de marcas 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 marcas 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 marcas de tiempo proporciona un buen equilibrio entre precisión y seguridad, ya que reduce la resolución a 100 microsegundos. Consulta el problema dawn:1800.

En Chrome, los usuarios pueden inhabilitar la cuantificación de marcas de tiempo habilitando la marca "WebGPU Developer Features" 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 "Unsafe WebGPU Support" 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 marcas 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 que los desarrolladores sepan que esta función es experimental y, por el momento, solo está disponible en los navegadores basados en Chromium. Consulta el problema dawn:1193.

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