Nowości w WebGPU (Chrome 155–156)

Rozszerzenie fragment_depth w WGSL

W przypadku renderowania z dużą ilością geometrii optymalizacje early-Z są najlepszym przyjacielem deweloperów. Zapewniają one ogromny wzrost wydajności, umożliwiając GPU odrzucanie ukrytych pikseli przed uruchomieniem kosztownych fragmentów kodu cieniowania. Jeśli zrasteryzowana głębia nie przejdzie testu głębi, GPU całkowicie pomija cieniowanie fragmentów, pod warunkiem że cieniowanie nie ma innych efektów ubocznych.

Jeśli chcesz dowiedzieć się, jak sprzęt radzi sobie z tym problemem, przeczytaj doskonały artykuł MJP na temat tego, kiedy należy wyłączyć Early-Z.

Chociaż niestandardowe manipulowanie głębią jest przydatne, robienie tego w programie do cieniowania fragmentów wiąże się z ukrytym kosztem. Zapisywanie w @builtin(frag_depth) w programie do cieniowania fragmentów zwykle wymusza na sterownikach wyłączenie optymalizacji early-Z dla całego wywołania rysowania. Dzieje się tak, ponieważ heurystyka sterownika nie może zagwarantować, że obliczona głębokość wyjściowa cieniowania jest zgodna z głębokością interpolowaną przez rasteryzator.

Aby rozwiązać ten problem, rozszerzenie WGSL fragment_depth umożliwia określenie nazwy trybu głębi less lub greater w @builtin(frag_depth), aby wyraźnie określić, jak zapisana głębia ma się do głębi interpolowanej. Dzięki temu GPU może bezpiecznie stosować optymalizacje early-Z.

To rozszerzenie języka można wykryć w języku JavaScript za pomocą navigator.gpu.wgslLanguageFeatures. Zalecamy użycie dyrektywy requires, aby zasygnalizować możliwość braku przenośności z requires fragment_depth; na początku kodu cieniowania WGSL. Zobacz ten przykład i zamiar wdrożenia.

if (!navigator.gpu.wgslLanguageFeatures.has("fragment_depth")) {
  throw new Error(`WGSL fragment depth is not available`);
}

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

const shaderModule = device.createShaderModule({ code: `
  requires fragment_depth;

  @fragment
  fn main() -> @builtin(frag_depth, less) f32 {
    // Explicitly states that the output fragment depth is less than early-Z depth,
    // allowing the GPU to safely preserve early-Z optimizations.
    return 0.0f;
  }`,
});

Niewyrównana kompresja tekstur

Funkcja GPU „texture-compression-unaligned” umożliwia tworzenie skompresowanych tekstur o wymiarach, które nie są wielokrotnościami liczb całkowitych rozmiaru bloku (np. 4 x 4 w przypadku formatów BC, ETC2 i ASTC). Wcześniej WebGPU wymagał, aby rozmiary tekstur były ściśle dopasowane do tych granic bloków. Dzięki temu, że nie trzeba uzupełniać ani skalować tekstur, aby dopasować je do wyrównania bloków, ta funkcja zachowuje oryginalną wierność kompresji bez wprowadzania zniekształceń skalowania. Zobacz zamiar wysłania.

Poniższy fragment kodu sprawdza, czy adapter obsługuje niespójną kompresję tekstur, i jeśli jest dostępna, żąda urządzenia z tą funkcją.

const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("texture-compression-unaligned")) {
  throw new Error("Texture compression unaligned support is not available");
}
// Explicitly request texture compression unaligned support.
const device = await adapter.requestDevice({
  requiredFeatures: ["texture-compression-unaligned"],
});

Dziękujemy zewnętrznemu współtwórcy Ignacio Castaño z zespołu spark.js za pracę nad tą funkcją, specyfikacją i zestawem testów zgodności.

Przestrzenie barw srgb-linear i display-p3-linear

Dzięki dodaniu wstępnie zdefiniowanych przestrzeni barw „srgb-linear” i „display-p3-linear” kontekst obszaru roboczego WebGPU może teraz renderować bezpośrednio w linearnych przestrzeniach barw o rozszerzonym zakresie, aby obsługiwać wyświetlacze o szerokiej gamie kolorów. Te przestrzenie barw zachowują liniową zależność między wartościami pikseli a luminancją fizyczną. Dzięki temu idealnie nadają się do renderowania fizycznego światła w grach, a także do zadań związanych z przetwarzaniem przestrzennym, takich jak antyaliasing, interpolacja i dziesiątkowanie. Zobacz zamiar udostępnienia i przykładową prośbę o pociągnięcie nr 574 dotyczącą cząsteczek (HDR).

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

const canvas = document.querySelector("canvas");
const context = canvas.getContext("webgpu");

context.configure({
  device,
  format: "rgba16float",
  colorSpace: "display-p3-linear",
});

Dodatkowy format wierzchołków snorm10-10-10-2

Format wierzchołka „snorm10-10-10-2” to spakowany format 32-bitowy zawierający 4 znormalizowane wartości ze znakiem: 3 komponenty 10-bitowe (r, g, b) i 1 komponent 2-bitowy (a). Dzięki temu formatowi możesz efektywnie przechowywać atrybuty, takie jak wektory normalne 3D z dodatkowym 2-bitowym skalarem lub flagą wyrównania, oszczędzając przy tym przepustowość pamięci. Zobacz specyfikację PR 6491.

Obsługa f16 w systemie Linux w przypadku NVIDIA

Opcjonalna funkcja „shader-f16”, która zapewnia obsługę 16-bitowych wartości zmiennoprzecinkowych w WGSL, jest teraz obsługiwana w systemie Linux w przypadku najnowszych sterowników GPU NVIDIA. Zobacz problem chromium:42251215.

Aktualizacje Dawn

Teraz możesz wysłać zapytanie o identyfikator LUID podstawowego adaptera DXGIAdapter dla danego adaptera GPU, używając struktury WGPUAdapterPropertiesD3D. Zobacz problem chromium:562849566.

Oto kilka najważniejszych informacji. Zapoznaj się z pełną listą zatwierdzeń.

Co nowego w WebGPU

Lista wszystkich tematów omówionych w serii Nowości w 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