Nowości w WebGPU (Chrome 133)

François Beaufort
François Beaufort
GitHub

Data publikacji: 29 stycznia 2025 r.

Dodatkowe formaty wierzchołków unorm8x4-bgra i 1-komponentowe

Dodano "unorm8x4-bgra"format wierzchołka i te formaty wierzchołków z 1 komponentem: "uint8", "sint8", "unorm8", "snorm8", "uint16", "sint16", "unorm16", "snorm16" i "float16". Format wierzchołka "unorm8x4-bgra" nieco ułatwia wczytywanie kolorów wierzchołków zakodowanych w formacie BGRA przy zachowaniu tego samego shadera. Dodatkowo format wierzchołka 1-elementowego umożliwia żądanie tylko niezbędnych danych, podczas gdy wcześniej w przypadku 8- i 16-bitowych typów danych wymagana była co najmniej dwukrotnie większa ilość. Zobacz wpis na chromestatus i problem 376924407.

Zezwalanie na wysyłanie próśb o nieznane limity z niezdefiniowaną wartością

Aby interfejs WebGPU API był mniej podatny na błędy w miarę jego rozwoju, możesz teraz podczas wysyłania żądania urządzenia GPU poprosić o nieznane limity, podając wartość undefined. Jest to przydatne np. w tym kodzie aplikacji, gdzie adapter.limits.someLimit może być undefined, jeśli someLimit już nie istnieje. Zobacz specyfikację PR 4781.

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Zmiany w regułach wyrównywania WGSL

Nie można już podać zbyt małej wartości wyrównania dla elementu struktury, ponieważ teraz wymagane jest, aby @align(n) dzieliło RequiredAlignOf dla wszystkich struktur. Ta zmiana upraszcza korzystanie z języka WGSL i zwiększa jego zgodność z przeglądarkami Firefox i Safari. Przykładowy kod pokazujący różnice między kompilatorami Tint, Naga i WebKit znajdziesz w specyfikacji PR.

Wzrost wydajności WGSL dzięki instrukcji discard

Ze względu na znaczny spadek wydajności podczas renderowania złożonego efektu odbić w przestrzeni ekranu (SSR) implementacja instrukcji discard korzysta z semantyki dostarczanej przez platformę w celu obniżenia poziomu do wywołania pomocniczego, gdy jest to możliwe. Zwiększa to wydajność shaderów, które używają funkcji discard. Zobacz problem 372714384.

Używanie parametru displaySize w przypadku tekstur zewnętrznych

Wymiary displayWidth i displayHeight powinny być używane jako widoczny rozmiar obiektu GPUExternalTexture podczas importowania obiektu VideoFrame zgodnie ze specyfikacją WebGPU. Jednak nieprawidłowo użyto widocznego rozmiaru, co powodowało problemy podczas próby użycia textureLoad() w obiekcie GPUExternalTexture. Problem został już rozwiązany. Zobacz problem 377574981.

Obsługa obrazów o orientacji innej niż domyślna za pomocą funkcji copyExternalImageToTexture

Metoda copyExternalImageToTexture() GPUQueue służy do kopiowania zawartości obrazu lub obszaru roboczego do tekstury. Obecnie prawidłowo obsługuje obrazy o orientacji innej niż domyślna. Wcześniej tak nie było, gdy źródłem była wartość ImageBitmap z imageOrientation "from-image" lub obraz z orientacją inną niż domyślna. Zobacz problem 384858956.

Ulepszanie środowiska programistycznego

Wartość adapter.limits może być zaskakująco wysoka, ale nie zdajesz sobie sprawy, że podczas żądania urządzenia GPU musisz wyraźnie poprosić o wyższy limit. Jeśli tego nie zrobisz, możesz później nieoczekiwanie osiągnąć limity.

Aby Ci pomóc, rozszerzyliśmy komunikaty o błędach o wskazówki, które informują, że w przypadku braku limitu określonego w requiredLimits podczas wywoływania requestDevice() należy wyraźnie poprosić o wyższy limit. Zobacz problem 42240683.

Poniższy przykład pokazuje ulepszony komunikat o błędzie rejestrowany w konsoli Narzędzi deweloperskich podczas tworzenia bufora GPU o rozmiarze przekraczającym domyślny limit maksymalnego rozmiaru bufora urządzenia.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);

⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Włączanie trybu zgodności za pomocą parametru featureLevel

Żądanie adaptera GPU w eksperymentalnym trybie zgodności jest teraz możliwe przez ustawienie standardowej opcji featureLevel na "compatibility". Dozwolone są tylko ciągi "core" (wartość domyślna) i "compatibility". Zapoznaj się z tym przykładem i specyfikacją PR 4897.

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

Opcja featureLevel zastępuje niestandaryzowaną opcję compatibilityMode, a niestandaryzowany atrybut featureLevel zastępuje atrybut isCompatibilityMode.

Ponieważ jest to wciąż funkcja eksperymentalna, musisz na razie uruchamiać Chrome z flagą „Unsafe WebGPU Support” (Niebezpieczna obsługa WebGPU) pod adresem chrome://flags/#enable-unsafe-webgpu. Aby wypróbować tę technologię, odwiedź stronę webgpureport.org.

Czyszczenie funkcji eksperymentalnej podgrupy

Wycofane funkcje podgrup eksperymentalnych "chromium-experimental-subgroups" i "chromium-experimental-subgroup-uniform-control-flow" zostaną usunięte. Zobacz problem 377868468.

"subgroups" Funkcja eksperymentalna jest teraz wszystkim, czego potrzebujesz podczas eksperymentowania z podgrupami. "subgroups-f16" Funkcja eksperymentalna została wycofana i wkrótce zostanie usunięta. Wartości f16 możesz stosować w przypadku podgrup, gdy aplikacja wysyła żądania dotyczące funkcji "shader-f16" i "subgroups". Zobacz problem 380244620.

Wycofanie limitu maxInterStageShaderComponents

Limit maxInterStageShaderComponents został wycofany z kilku powodów:

  • Nadmiarowość z maxInterStageShaderVariables: ten limit służy już do podobnego celu, czyli kontrolowania ilości danych przekazywanych między etapami shadera.
  • Niewielkie rozbieżności: chociaż sposób obliczania tych 2 limitów nieco się różni, różnice te są niewielkie i można nimi skutecznie zarządzać w ramach limitu maxInterStageShaderVariables.
  • Uproszczenie: usunięcie maxInterStageShaderComponents upraszcza interfejs shadera i zmniejsza złożoność dla programistów. Zamiast zarządzać 2 osobnymi limitami, które różnią się od siebie w niewielkim stopniu, mogą skupić się na bardziej odpowiednim i wszechstronnym limicie maxInterStageShaderVariables.

Planujemy całkowite usunięcie tej funkcji w Chrome 135. Zobacz intencję wycofania i problem 364338810.

Aktualizacje o świcie

wgpu::Device::GetAdapterInfo(adapterInfo) umożliwia uzyskanie informacji o adapterze bezpośrednio z wgpu::Device. Zobacz problem 376600838.

Struktura WGPUProgrammableStageDescriptor została zmieniona na WGPUComputeState, aby stan obliczeń był zgodny ze stanami wierzchołków i fragmentów. Zobacz problem 379059434.

Wartość wyliczeniowa wgpu::VertexStepMode::VertexBufferNotUsed została usunięta. Układ bufora wierzchołków, który nie jest używany, można teraz oznaczyć symbolem {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0}. Zobacz problem 383147017.

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

Nowości w WebGPU

Lista wszystkich tematów omówionych w serii Nowości w WebGPU.

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