Co nowego w WebGPU (Chrome 120)

François Beaufort
François Beaufort
GitHub

Obsługa 16-bitowych wartości zmiennoprzecinkowych w WGSL

W WGSL typ f16 to zbiór 16-bitowych wartości zmiennoprzecinkowych formatu IEEE-754 binarnego (połowa precyzji). Oznacza to, że do reprezentowania liczby zmiennoprzecinkowej używa się 16 bitów, a nie 32 bitów w przypadku konwencjonalnej liczby zmiennoprzecinkowej pojedynczej precyzji (f32). Taki mniejszy rozmiar może prowadzić do znacznego zwiększenia wydajności, zwłaszcza w przypadku przetwarzania dużych ilości danych.

Dla porównania: na urządzeniach Apple M1 Pro implementacja modeli Llama2 7B używanych w demonstracji czatu WebLLM odbywa się znacznie szybciej niż implementacja f32, zapewniając o 28% większą szybkość wstępnego uzupełniania i o 41% większą szybkość dekodowania, jak pokazano na poniższych zrzutach ekranu.f16

Zrzut ekranu z prezentacjami czatu WebLLM z modelami F32 i F16 Llama2 7B.
Prezentacje czatu WebLLM z modelami f32 (po lewej) i f16 (po prawej) Llama2 7B.

Nie wszystkie GPU obsługują 16-bitowe wartości zmiennoprzecinkowe. Gdy funkcja "shader-f16" jest dostępna w GPUAdapter, możesz teraz wysłać żądanie GPUDevice z tą funkcją i utworzyć moduł cieniowania WGSL, który korzysta z połowiowej dokładności typu zmiennoprzecinkowego f16. Tego typu można używać w module cieniowania WGSL tylko wtedy, gdy włączysz rozszerzenie f16 WGSL za pomocą enable f16;. W przeciwnym razie createShaderModule() wygeneruje błąd weryfikacji. Zobacz ten minimalny przykład i problem świt: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...

W kodzie modułu cieniowania WGSL możesz obsługiwać zarówno typy f16, jak i f32 z parametrem alias w zależności od obsługi funkcji "shader-f16", jak pokazano w tym fragmencie kodu.

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

Przekraczaj granice

Maksymalna liczba bajtów niezbędnych do przechowywania 1 próbki (piksela lub subpiksela) danych wyjściowych renderowania potoku dla wszystkich załączników w kolorze, domyślnie wynosi 32 bajty. Teraz za pomocą limitu maxColorAttachmentBytesPerSample możesz przesłać prośbę o maksymalnie 64. Zobacz ten przykład i problem świt: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 },
});

Zwiększyliśmy limity maxInterStageShaderVariables i maxInterStageShaderComponents używane w komunikacji międzyetapowej na wszystkich platformach. Szczegółowe informacje znajdziesz w artykule o problemie dawno:1448.

Na każdym etapie cieniowania maksymalna liczba wpisów układu grup powiązań w układzie potoku, które są buforami pamięci masowej, wynosi domyślnie 8. Teraz za pomocą limitu maxStorageBuffersPerShaderStage możesz przesłać prośbę o maksymalnie 10. Zobacz problem: świt:2159.

Dodano nowy limit maxBindGroupsPlusVertexBuffers. Składa się z maksymalnej liczby używanych jednocześnie przedziałów grupy powiązań i bufora wierzchołków, przy czym wszystkie puste przedziały są liczone poniżej najwyższego indeksu. Jej wartość domyślna to 24. Zobacz problem: świt:1849.

Zmiany stanu szablonu głębi

Ze względu na wygodę programistów atrybuty głębi szablonu depthWriteEnabled i depthCompare nie zawsze są już wymagane: element depthWriteEnabled jest wymagany tylko w przypadku formatów z głębokością, a element depthCompare nie jest wymagany w przypadku formatów z głębią, jeśli nie jest używany w ogóle. Zobacz problem: świt:2132.

Aktualizacje informacji o karcie

Niestandardowe atrybuty informacji o adapterze type i backend są teraz dostępne po wywołaniu funkcji requestAdapterInfo(), gdy użytkownik włączy „Funkcje dla programistów WebGPU”. flagę o chrome://flags/#enable-webgpu-developer-features. type może mieć wartość „oddzielny GPU”, „zintegrowany GPU”, „CPU” lub „nieznany”. backend to „WebGPU”, „D3D11”, „D3D12”, „metal”, „vulkan”, „openGL”, „openGLES” lub „null”. Zobacz problem o świcie:2112 i wydanie świt:2107.

Zrzut ekranu strony https://webgpureport.org przedstawiający backend i wpisanie informacji o adaperze.
Informacje o karcie i typ karty wyświetlane na stronie https://webgpureport.org.

Opcjonalny parametr listy unmaskHints w funkcji requestAdapterInfo() został usunięty. Zobacz problem: świt:1427.

Kwantyzacja zapytań dotyczących sygnatury czasowej

Zapytania dotyczące sygnatury czasowej pozwalają aplikacjom mierzyć czas wykonywania poleceń GPU z dokładnością do nanosekund. Specyfikacja WebGPU sprawia jednak, że zapytania dotyczące sygnatury czasowej są opcjonalne ze względu na potencjalne problemy z atakami czasowymi. Zespół Chrome uważa, że kwantyzacja zapytań dotyczących sygnatury czasowej stanowi dobry kompromis między precyzją a bezpieczeństwem, ponieważ ogranicza rozdzielczość do 100 mikrosekund. Zobacz problem świt:1800.

W Chrome użytkownicy mogą wyłączyć kwantyzację sygnatur czasowych, włączając „Funkcje dla programistów WebGPU”. flag na chrome://flags/#enable-webgpu-developer-features. Pamiętaj, że to oznaczenie nie włącza funkcji "timestamp-query". Implementacja jego działania jest nadal w fazie eksperymentalnej i dlatego wymaga „niebezpiecznej obsługi WebGPU”. flaga na chrome://flags/#enable-unsafe-webgpu.

O świcie nowy przełącznik urządzeń o nazwie „timestamp_quantization” została dodana i jest domyślnie włączona. Fragment kodu poniżej pokazuje, jak zezwolić na eksperymentalne zapytanie „timestamp-query” bez kwantyzacji sygnatury czasowej przy wysyłaniu żądania urządzenia.

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

Funkcje sprzątania wiosną

Eksperymentalna „timestamp-query-inside-passes” funkcja została zmieniona na „chromium-experimental-timestamp-query-inside-passes” , aby wyjaśnić deweloperom, że ta funkcja jest eksperymentalna i obecnie jest dostępna tylko w przeglądarkach opartych na Chromium. Zobacz problem: świt:1193.

Eksperymentalne zapytanie „pipeline-statistics-query” Funkcja, która była jedynie częściowo wdrożona, została usunięta, ponieważ nie jest już rozwijana. Zobacz problem chromium:1177506.

To tylko niektóre z najważniejszych informacji. Zapoznaj się z pełną listą zatwierdzeń.

Co nowego w WebGPU

Lista wszystkiego, co zostało omówione w serii Co nowego w WebGPU.

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