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 binary16 IEEE-754 (precisión media). Significa que usa 16 bits para representar un número de punto flotante, en comparación con 32 bits para el punto flotante de precisión simple convencional (f32
). Este tamaño más pequeño puede generar mejoras de rendimiento significativas, en especial cuando se procesan grandes cantidades de datos.
A modo de comparación, en un dispositivo Apple M1 Pro, la implementación f16
de los modelos Llama2 7B que se usó en la demostración del chat de WebGL es significativamente más rápida que la implementación de f32
, con una mejora del 28% en la velocidad de autocompletar y del 41% en la velocidad de decodificación, como se muestra en las siguientes capturas de pantalla.
![Captura de pantalla de demostraciones de chat de WebLLM con los modelos f32 y f16 Llama2 7B.](https://developer.chrome.google.cn/static/blog/new-in-webgpu-120/image/webllm-chat-demos.png?authuser=8&hl=es)
f32
(izquierda) y f16
(derecha) Llama2 7B.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 una GPUDevice
con esta función y crear un módulo de sombreador WGSL que aproveche el tipo de punto flotante con 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 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 contener una muestra (píxel o subpíxel) de 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 maxColorAttachmentBytesPerSample
. Consulta el siguiente ejemplo y el problema 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 grupos de vinculaciones 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 maxStorageBuffersPerShaderStage
. Consulta 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 vinculaciones que se usan de forma simultánea, y se cuentan las ranuras vacías por debajo del índice más alto. Su valor predeterminado es 24. Consulta problema dawn:1849.
Cambios en el estado de la plantilla de profundidad
Para mejorar la experiencia del desarrollador, ya no se requieren los atributos de estado de la plantilla de profundidad depthWriteEnabled
y depthCompare
: depthWriteEnabled
es obligatorio solo para formatos con profundidad, y depthCompare
no se requiere para formatos con profundidad si no se usa en absoluto. Consulta 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() cuando el usuario habilitó las “Funciones para desarrolladores de WebGPU”. marca 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 los problema dawn:2112 y problema dawn:2107.
![Captura de pantalla de https://webgpureport.org que muestra el backend y el tipo de información sobre el adaptador.](https://developer.chrome.google.cn/static/blog/new-in-webgpu-120/image/webgpureport.png?authuser=8&hl=es)
Se quitó el parámetro de lista opcional unmaskHints
de requestAdapterInfo(). Consulta problema dawn:1427.
Cuantización de consultas con 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 una precisión de nanosegundos. Sin embargo, la especificación de WebGPU hace que las consultas de marca de tiempo sean opcionales debido a problemas de ataque de tiempo. El equipo de Chrome cree que la cuantificación de las consultas de marcas de tiempo proporciona un buen equilibrio entre la precisión y la seguridad, ya que se reduce la resolución a 100 microsegundos. Consulta problema dawn:1800.
En Chrome, los usuarios pueden inhabilitar la cuantización de marcas de tiempo habilitando las “Funciones para desarrolladores de WebGPU” flag 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 de la "Compatibilidad no segura con WebGPU" en chrome://flags/#enable-unsafe-webgpu
.
Durante el amanecer, un nuevo botón de activación del dispositivo llamado "timestamp_quantization". se agregó y está habilitado de forma predeterminada. En el siguiente fragmento, se muestra cómo permitir la “consulta de marca de tiempo” experimental sin cuantizació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 = ×tampQuantizationToggle;
deviceTogglesDesc.disabledToggleCount = 1;
wgpu::DeviceDescriptor desc = {.nextInChain = &deviceTogglesDesc};
// Request a device with no timestamp quantization.
myAdapter.RequestDevice(&desc, myCallback, myUserData);
Características de la limpieza de primavera
La operación experimental "timestamp-query-inside-passes" Se cambió el nombre de la función a "chromium-experimental-timestamp-query-inside-passes" para aclararles a los desarrolladores que esta función es experimental y que, por el momento, solo está disponible en navegadores con Chromium. Consulta problema dawn:1193.
La consulta experimental “pipeline-statistics-query” La función, que solo se implementó de forma parcial, se eliminó porque ya no se desarrolla. Consulta el problema chromium:1177506.
Esto abarca solo algunos de los aspectos más destacados. Consulta la lista exhaustiva de confirmaciones.
Novedades de WebGPU
Una lista de todo lo que se ha abordado en la serie Novedades de WebGPU.
Chrome 127
- Compatibilidad experimental con OpenGL ES en Android
- Atributo de información de GPUAdapter
- Mejoras en la interoperabilidad de WebAssembly
- Mejoras en los errores del codificador de comandos
- Actualizaciones del amanecer
Chrome 126
- Aumenta el límite de maxTextureArrayLayers
- Optimización de carga de búfer para el backend de Vulkan
- Mejoras en el tiempo de compilación del sombreador
- Los búferes de comandos enviados deben ser únicos
- Actualizaciones del amanecer
Chrome 125
- Subgrupos (función en desarrollo)
- Cómo renderizar una porción de textura 3D
- Actualizaciones del amanecer
Chrome 124
- Texturas de almacenamiento de solo lectura y de lectura y escritura
- Asistencia para service workers y trabajadores compartidos
- Nuevos atributos de información del adaptador
- Correcciones de errores
- Actualizaciones del amanecer
Chrome 123
- Compatibilidad con funciones integradas de la DP4a en WGSL
- Parámetros de puntero no restringido en WGSL
- Azúcar de sintaxis para desreferenciar compuestos en WGSL
- Separa el estado de solo lectura para los aspectos de esténcil y profundidad
- Actualizaciones del amanecer
Chrome 122
- Expande el alcance con el modo de compatibilidad (función en desarrollo)
- Aumenta el límite de maxVertexAttributes
- Actualizaciones del amanecer
Chrome 121
- Compatibilidad con WebGPU en Android
- Usa DXC en lugar de FXC para compilar sombreadores en Windows
- Consultas de marcas de tiempo en los pases de procesamiento y renderización
- Puntos de entrada predeterminados a los módulos de sombreadores
- Compatibilidad con display-p3 como espacio de color GPUExternalTexture
- Información sobre los montón de memoria
- Actualizaciones del amanecer
Chrome 120
- Compatibilidad con valores de punto flotante de 16 bits en WGSL
- Supera los límites
- Cambios en el estado de la plantilla de profundidad
- Actualizaciones de la información de los adaptadores
- Cuantización de consultas de marcas de tiempo
- Funciones de la limpieza de primavera
Chrome 119
- Texturas flotantes de 32 bits filtrables
- formato de vértice unorm10-10-10-2
- Formato de textura RGB10a2uint
- Actualizaciones del amanecer
Chrome 118
- Compatibilidad con ImageData y HTMLImageElement en
copyExternalImageToTexture()
- Compatibilidad experimental para texturas de almacenamiento de lectura y escritura y de solo lectura
- Actualizaciones del amanecer
Chrome 117
- Se anuló la configuración del búfer de vértices
- Anular el grupo de vinculaciones
- Silencia errores de la creación de una canalización asíncrona cuando se pierde el dispositivo
- Actualizaciones de la creación de módulos sombreadores SPIR-V
- Mejora la experiencia de los desarrolladores
- Almacenamiento de canalizaciones en caché con diseño generado automáticamente
- Actualizaciones del amanecer
Chrome 116
- Integración de WebCodecs
- Dispositivo perdido que devuelve GPUAdapter
requestDevice()
- Mantener la reproducción de video fluida si se llama a
importExternalTexture()
- Cumplimiento de las especificaciones
- Mejora la experiencia de los desarrolladores
- Actualizaciones del amanecer
Chrome 115
- Extensiones de idioma WGSL compatibles
- Compatibilidad experimental con Direct3D 11
- Obtén una GPU discreta de forma predeterminada con la alimentación de CA
- Mejora la experiencia de los desarrolladores
- Actualizaciones del amanecer
Chrome 114
- Optimiza JavaScript
- getCurrentTexture() en el lienzo no configurado arroja una InvalidStateError
- Actualizaciones de WGSL
- Actualizaciones del amanecer