Novità di WebGPU (Chrome 120)

François Beaufort
François Beaufort
GitHub

Supporto per valori in virgola mobile a 16 bit in WGSL

In WGSL, il tipo f16 è l'insieme di valori in rappresentazione in virgola mobile a 16 bit del formato IEEE-754 binary16 (mezza precisione). Significa che utilizza 16 bit per rappresentare un numero in rappresentazione in virgola mobile, anziché 32 bit per la rappresentazione in virgola mobile a precisione singola convenzionale (f32). Queste dimensioni più ridotte possono portare a miglioramenti significativi delle prestazioni, soprattutto quando si elaborano grandi quantità di dati.

Per confronto, su un dispositivo Apple M1 Pro, l'implementazione di f16 dei modelli Llama2 7B utilizzati nella demo di chat WebLLM è notevolmente più veloce dell'implementazione di f32, con un miglioramento del 28% della velocità di precompilazione e del 41% della velocità di decodifica, come mostrato negli screenshot seguenti.

Screenshot delle demo di chat WebLLM con i modelli Llama2 7B f32 e f16.
Demo di chat WebLLM con i modelli Llama2 7B f32 (a sinistra) e f16 (a destra).

Non tutte le GPU supportano valori in virgola mobile a 16 bit. Quando la funzionalità "shader-f16" è disponibile in un GPUAdapter, ora puoi richiedere un GPUDevice con questa funzionalità e creare un modulo shader WGSL che sfrutta il tipo di rappresentazione in virgola mobile a mezza precisione f16. Questo tipo è valido per l'utilizzo nel modulo shader WGSL solo se abiliti l'f16estensione WGSL con enable f16; In caso contrario, createShaderModule() genererà un errore di convalida. Vedi il seguente esempio minimo e il 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...

È possibile supportare sia i tipi f16 che f32 nel codice del modulo shader WGSL con un alias a seconda del supporto della funzionalità "shader-f16", come mostrato nel seguente snippet.

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

Superare i limiti

Il numero massimo di byte necessari per contenere un campione (pixel o subpixel) dei dati di output della pipeline di rendering, in tutti gli allegati di colore, è 32 byte per impostazione predefinita. Ora è possibile richiedere fino a 64 utilizzando il limite maxColorAttachmentBytesPerSample. Vedi l'esempio seguente e 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 },
});

I limiti di maxInterStageShaderVariables e maxInterStageShaderComponents utilizzati per la comunicazione tra le fasi sono stati aumentati su tutte le piattaforme. Per i dettagli, vedi issue dawn:1448.

Per ogni fase dello shader, il numero massimo di voci di layout del gruppo di binding in un layout della pipeline che sono buffer di archiviazione è 8 per impostazione predefinita. Ora è possibile richiedere fino a 10 utilizzando il limite maxStorageBuffersPerShaderStage. Vedi problema dawn:2159.

È stato aggiunto un nuovo limite di maxBindGroupsPlusVertexBuffers. È costituito dal numero massimo di slot di gruppi di binding e buffer dei vertici utilizzati contemporaneamente, contando gli slot vuoti sotto l'indice più alto. Il valore predefinito è 24. Vedi issue dawn:1849.

Modifiche allo stato di profondità-stencil

Per migliorare l'esperienza degli sviluppatori, gli attributi depthWriteEnabled e depthCompare dello stato di profondità-stencil non sono più sempre obbligatori: depthWriteEnabled è obbligatorio solo per i formati con profondità e depthCompare non è obbligatorio per i formati con profondità se non viene utilizzato. Vedi problema dawn:2132.

Aggiornamenti delle informazioni sull'adattatore

Gli attributi delle informazioni sull'adattatore type e backend non standard sono ora disponibili quando viene chiamato requestAdapterInfo() se l'utente ha attivato il flag "Funzionalità per sviluppatori WebGPU" all'indirizzo chrome://flags/#enable-webgpu-developer-features. type può essere "GPU discreta", "GPU integrata", "CPU" o "sconosciuto". Il valore di backend è "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" o "null". Vedi issue dawn:2112 e issue dawn:2107.

Screenshot di https://webgpureport.org con informazioni su backend e tipo nell'adattatore.
Backend e tipo di informazioni sull'adattatore visualizzati su https://webgpureport.org.

Il parametro di elenco unmaskHints facoltativo in requestAdapterInfo() è stato rimosso. Vedi issue dawn:1427.

Quantizzazione delle query con timestamp

Le query sui timestamp consentono alle applicazioni di misurare il tempo di esecuzione dei comandi della GPU con una precisione al nanosecondo. Tuttavia, la specifica WebGPU rende facoltative le query sui timestamp a causa di problemi di attacco temporale. Il team di Chrome ritiene che la quantizzazione delle query di timestamp offra un buon compromesso tra precisione e sicurezza, riducendo la risoluzione a 100 microsecondi. Vedi problema alba:1800.

In Chrome, gli utenti possono disattivare la quantizzazione dei timestamp attivando il flag "Funzionalità per sviluppatori WebGPU" all'indirizzo chrome://flags/#enable-webgpu-developer-features. Tieni presente che questo flag da solo non attiva la funzionalità "timestamp-query". La sua implementazione è ancora sperimentale e pertanto richiede il flag "Unsafe WebGPU Support" (Supporto WebGPU non sicuro) all'indirizzo chrome://flags/#enable-unsafe-webgpu.

In Dawn è stato aggiunto un nuovo pulsante di attivazione/disattivazione del dispositivo chiamato "timestamp_quantization", che è abilitato per impostazione predefinita. Il seguente snippet mostra come consentire la funzionalità sperimentale "timestamp-query" senza quantizzazione del timestamp quando richiedi 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);

Funzionalità per le pulizie di primavera

La funzionalità sperimentale "timestamp-query-inside-passes" è stata rinominata "chromium-experimental-timestamp-query-inside-passes" per comunicare chiaramente agli sviluppatori che questa funzionalità è sperimentale e disponibile al momento solo nei browser basati su Chromium. Vedi issue dawn:1193.

La funzionalità sperimentale "pipeline-statistics-query", implementata solo parzialmente, è stata rimossa perché non è più in fase di sviluppo. Vedi issue chromium:1177506.

Questi sono solo alcuni dei punti salienti. Consulta l'elenco completo dei commit.

Novità di WebGPU

Un elenco di tutti gli argomenti trattati nella serie Novità di WebGPU.

Chrome 155-156

Chrome 153-154

Chrome 151-152

Chrome 149-150

Chrome 147-148

Chrome 146

Chrome 145

Chrome 144

Chrome 143

Chrome 142

Chrome 141

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