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

Dodano format wierzchołka "unorm8x4-bgra" oraz następujące formaty wierzchołka 1-elementowego: "uint8", "sint8", "unorm8", "snorm8", "uint16", "sint16", "unorm16", "snorm16" i "float16". Format wierzchołka "unorm8x4-bgra" ułatwia wczytywanie kolorów wierzchołka 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 typów danych 8- i 16-bitowych wymagana była co najmniej dwukrotnie większa ilość danych. Zobacz informacje na stronie chromestatus oraz problem 376924407.

Zezwalanie na żądanie nieznanych limitów z nieokreśloną wartością

Aby interfejs WebGPU API był mniej podatny na błędy w trakcie rozwoju, możesz teraz poprosić o nieznane limity z wartością undefined podczas żądania urządzenia z procesorem graficznym. Jest to przydatne w przypadku kodu aplikacji, gdy 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 dopasowania WGSL

Nie można już podawać zbyt małej wartości wyrównania dla elementu struktury, ponieważ wymagane jest teraz, aby @align(n) dzieliło RequiredAlignOf we wszystkich strukturach. Ta zmiana usprawnia 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.

Zwiększenie wydajności WGSL dzięki odrzuceniu

Ze względu na znaczny spadek wydajności podczas renderowania złożonego efektu odbić w przestrzeni ekranu (SSR) implementacja instrukcji discard używa semantyki udostępnianej przez platformę, aby w razie możliwości wywołać pomocniczą funkcję. Zwiększa to wydajność shaderów, które używają discard. Zobacz problem 372714384.

Używanie rozmiaru displaySize obiektu VideoFrame do tekstur zewnętrznych

Wymiary displayWidth i displayHeight powinny być używane jako pozorny rozmiar zewnętrznej tekstury GPU podczas importowania ramki wideo zgodnie ze specyfikacją WebGPU. Jednak widoczny rozmiar został użyty nieprawidłowo, co spowodowało problemy podczas próby użycia textureLoad() w zewnętrznej teksturze GPU. 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. Teraz poprawnie obsługuje obrazy o niestandardowych orientacjach. Wcześniej było inaczej, gdy źródło było obrazem ImageBitmap z imageOrientation "from-image" lub obrazem o orientacji innej niż domyślna. Zobacz problem 384858956.

Ulepszenie środowiska programisty

Może być zaskakujące, że adapter.limits pokazuje wysokie wartości, ale nie wiesz, że musisz wyraźnie poprosić o wyższy limit podczas żądania urządzenia z procesorem graficznym. Jeśli tego nie zrobisz, możesz nieoczekiwanie przekroczyć limity później.

Aby Ci pomóc, rozszerzyliśmy komunikaty o błędach o wskazówki, które informują o konieczności wyraźnego podania wyższego limitu, gdy w wywołaniu requestDevice() nie został określony żaden limit w parametrye requiredLimits. Zobacz problem 42240683.

W tym przykładzie pokazano ulepszony komunikat o błędzie zarejestrowany w konsoli Narzędzi deweloperskich podczas tworzenia bufora GPU o rozmiarze przekraczającym domyślny limit urządzenia dla maksymalnego rozmiaru bufora.

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ą atrybutu featureLevel

Żądanie adaptera GPU w eksperymentalnym trybie zgodności jest teraz możliwe dzięki ustawieniu standardowej opcji featureLevel na "compatibility". Dozwolone są tylko ciągi tekstowe "core" (domyślny) 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 niestandardową opcję compatibilityMode, a niestandardowy atrybut featureLevel zastępuje atrybut isCompatibilityMode.

Jest to funkcja eksperymentalna, więc na razie musisz uruchomić Chrome z flagą „Unsafe WebGPU Support” (Niebezpieczne wsparcie WebGPU) ustawioną na chrome://flags/#enable-unsafe-webgpu. Aby się z nim zapoznać, wejdź na stronę webgpureport.org.

Oczyszczanie eksperymentalnych funkcji podgrupy

Wycofane zostały eksperymentalne funkcje podgrupy "chromium-experimental-subgroups" i "chromium-experimental-subgroup-uniform-control-flow". Zobacz problem 377868468.

Funkcja eksperymentalna "subgroups" to wszystko, czego potrzebujesz do eksperymentowania z podgrupami. Funkcja eksperymentalna "subgroups-f16" została wycofana i wkrótce zostanie usunięta. Wartości f16 możesz używać z podgrupami, gdy aplikacja prosi o funkcje "shader-f16" i "subgroups". Zobacz problem 380244620.

Wycofanie limitu maxInterStageShaderComponents

Limit maxInterStageShaderComponents został wycofany z powodu kilku czynników:

  • Redundancja z poziomem maxInterStageShaderVariables: ten limit służy już do podobnego celu, czyli do kontrolowania ilości danych przekazywanych między etapami shadera.
  • Niewielkie rozbieżności: chociaż istnieją niewielkie różnice w sposobie obliczania tych 2 limitów, są one niewielkie i można skutecznie zarządzać nimi w ramach limitu maxInterStageShaderVariables.
  • Upraszczanie: usunięcie maxInterStageShaderComponents upraszcza interfejs shadera i ułatwia pracę deweloperom. Zamiast zarządzać 2 osobnymi limitami o niewielkich różnicach, mogą skupić się na bardziej odpowiednim i pełniejszym maxInterStageShaderVariables.

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

Aktualizacje świtu

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

Struktura WGPUProgrammableStageDescriptor została przemianowana na WGPUComputeState, aby stan obliczeń był spójny ze stanami wierzchołka i fragmentu. 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 wyrazić za pomocą {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0}. Zobacz problem 383147017.

Obejmuje to tylko niektóre najważniejsze informacje. Zapoznaj się z pełną listą commitów.

Co nowego w WebGPU

Lista wszystkich tematów omawianych w cyklu Co nowego w WebGPU.

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