Novità di WebGPU (Chrome 120)

François Beaufort
François Beaufort
GitHub

Supporto per valori con virgola mobile a 16 bit in WGSL

In WGSL, il tipo f16 è l'insieme di valori in virgola mobile a 16 bit del formato binari16 (metà precisione) di IEEE-754. Significa che utilizza 16 bit per rappresentare un numero in virgola mobile, a differenza dei 32 bit per la rappresentazione in virgola mobile convenzionale a precisione singola (f32). Queste dimensioni ridotte possono portare a miglioramenti significativi delle prestazioni, soprattutto durante l'elaborazione di grandi quantità di dati.

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

Screenshot di demo chat WebLLM con modelli f32 e f16 Llama2 7B.
Demo chat WebLLM con 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 GPUAdapter, ora puoi richiedere un GPUDevice con questa funzionalità e creare un modulo Shar WGSL che sfrutta il tipo con virgola mobile a mezza precisione f16. Questo tipo può essere utilizzato nel modulo Shar WGSL solo se abiliti l'estensione WGSL f16 con enable f16;. In caso contrario, createShaderModule() genererà un errore di convalida. Vedi il seguente esempio minimo e il problema issue 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 entrambi i tipi f16 e f32 nel codice del modulo Shar WGSL con un valore 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);
  }
`;

Supera i limiti

Per impostazione predefinita, il numero massimo di byte necessari per contenere un campione (pixel o sottopixel) di dati di output della pipeline di rendering in tutti i collegamenti di colori è 32 byte. Ora è possibile effettuare richieste fino a 64 utilizzando il limite di 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 le comunicazioni tra le fasi sono stati aumentati su tutte le piattaforme. Per informazioni dettagliate, vedi issue dawn:1448.

Per ogni fase del mapping, per impostazione predefinita il numero massimo di voci di layout dei gruppi di associazione nel layout di una pipeline che sono buffer di archiviazione è 8. Ora è possibile richiedere fino a 10 richieste utilizzando il limite di maxStorageBuffersPerShaderStage. Vedi issue dawn:2159.

È stato aggiunto un nuovo limite per maxBindGroupsPlusVertexBuffers. Consiste nel numero massimo di slot di bind group e vertex buffer utilizzati contemporaneamente, contando tutti gli slot vuoti al di sotto dell'indice più alto. Il suo valore predefinito è 24. Vedi issue dawn:1849.

Modifiche allo stato dello stampino per profondità

Per migliorare l'esperienza degli sviluppatori, gli attributi stato profondità depthWriteEnabled e depthCompare non sono sempre più obbligatori: il valore depthWriteEnabled è obbligatorio solo per i formati con profondità, mentre depthCompare non lo è per i formati con profondità se non vengono utilizzati affatto. Vedi issue dawn:2132.

Aggiornamenti delle informazioni sull'adattatore

Gli attributi relativi alle informazioni sull'adattatore type e backend non standard sono ora disponibili chiamando requestAdapterInfo() se l'utente ha attivato le "Funzionalità per sviluppatori WebGPU" segnalazione alle chrome://flags/#enable-webgpu-developer-features. type può essere "GPU discreta", "GPU integrata", "CPU" o "sconosciuto". backend è "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" o "null". Vedi issue dawn:2112 e issue dawn:2107.

Screenshot di https://webgpureport.org che mostra il backend e digita le informazioni sull&#39;adattatore.
Tipo e backend delle informazioni dell'adattatore mostrati su https://webgpureport.org.

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

quantizzazione delle query con timestamp

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

In Chrome, gli utenti possono disattivare la quantizzazione dei timestamp attivando le "Funzionalità per sviluppatori WebGPU" flag alle 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 "supporto di WebGPU non sicuro" per chrome://flags/#enable-unsafe-webgpu.

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

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

La query sperimentale "pipeline-statistics-query" che è stata implementata solo parzialmente, è stata rimossa perché non è più in fase di sviluppo. Consulta il problema chromium:1177506.

Descrive 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 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