Эта страница переведена с помощью Cloud Translation API.

Что нового в WebGPU (Chrome 133)

François Beaufort

Опубликовано: 29 января 2025 г.

Дополнительные форматы unorm8x4-bgra и 1-компонентные вершинные форматы

Добавлены формат вершин "unorm8x4-bgra" и следующие однокомпонентные форматы вершин: "uint8" , "sint8" , "unorm8" , "snorm8" "uint16" "sint16" "unorm16" "snorm16" и "float16" . Формат вершин "unorm8x4-bgra" немного упрощает загрузку цветов вершин, закодированных в BGRA, при сохранении того же шейдера. Кроме того, однокомпонентный формат вершин позволяет запрашивать только необходимые данные, тогда как ранее для 8- и 16-битных типов данных требовалось как минимум вдвое больше данных. См. запись в chromestatus и проблему 376924407 .

Разрешить запрос неизвестных лимитов с неопределенным значением.

Чтобы сделать API WebGPU менее уязвимым по мере его развития, теперь можно запрашивать неизвестные ограничения с undefined значением при запросе устройства GPU. Это полезно, например, в следующем коде приложения, где adapter.limits.someLimit может быть undefined если someLimit больше не существует. См. спецификацию PR 4781 .

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

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

Изменения в правилах выравнивания WGSL

Теперь невозможно указать слишком малое значение выравнивания для члена структуры, поскольку требуется, чтобы @align(n) делило RequiredAlignOf для всех структур. Это критическое изменение упрощает использование языка WGSL и делает его более совместимым с Firefox и Safari. Примеры кода, демонстрирующие различия между компиляторами Tint, Naga и WebKit, можно найти в запросе на слияние спецификации .

Повышение производительности WGSL за счет отбрасывания

В связи со значительным снижением производительности, наблюдаемым при рендеринге сложного эффекта экранных отражений (SSR), реализация оператора discard использует предоставляемую платформой семантику для понижения уровня до вызова вспомогательной функции, если таковая доступна. Это повышает производительность шейдеров, использующих discard. См. проблему 372714384 .

Используйте параметр `videoFrame displaySize` для внешних текстур.

Согласно спецификации WebGPU, размеры displayWidth и displayHeight должны использоваться в качестве видимого размера GPUExternalTexture при импорте VideoFrame. Однако ранее некорректно использовался видимый размер, что вызывало проблемы при попытке использовать textureLoad() для GPUExternalTexture. Теперь это исправлено. См. проблему 377574981 .

Обработка изображений с нестандартной ориентацией осуществляется с помощью функции copyExternalImageToTexture.

Метод copyExternalImageToTexture() GPUQueue используется для копирования содержимого изображения или холста в текстуру. Теперь он корректно обрабатывает изображения с ориентацией, отличной от стандартной. Ранее это было невозможно, когда источником был ImageBitmap с imageOrientation "from-image" или изображение с ориентацией, отличной от стандартной. См. проблему 384858956 .

Улучшение опыта разработчиков

Высокие значения в параметре adapter.limits могут вызывать удивление, но вы можете не осознавать, что при запросе на использование графического процессора необходимо явно указать более высокий лимит. В противном случае это может привести к неожиданному превышению лимитов в дальнейшем.

Чтобы помочь вам, сообщения об ошибках были дополнены подсказками, указывающими на необходимость явного запроса более высокого лимита, если в параметре requiredLimits при вызове requestDevice() лимит не был указан. См. проблему 42240683 .

В следующем примере показано улучшенное сообщение об ошибке, регистрируемое в консоли DevTools при создании буфера GPU с размером, превышающим установленный по умолчанию максимальный размер буфера устройства.

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]).

Включите режим совместимости с помощью featureLevel

Теперь можно запросить графический адаптер в экспериментальном режиме совместимости , установив стандартизированный параметр featureLevel в значение "compatibility" . Допускаются только значения "core" (по умолчанию) и "compatibility" . См. следующий пример и спецификацию 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.
}

Параметр featureLevel заменяет нестандартизированный параметр compatibilityMode , а нестандартизированный атрибут featureLevel заменяет атрибут isCompatibilityMode .

Поскольку это пока экспериментальная функция, вам необходимо запустить Chrome с флагом "Unsafe WebGPU Support" по адресу chrome://flags/#enable-unsafe-webgpu . Чтобы поэкспериментировать с ней, посетите webgpureport.org .

Очистка характеристик экспериментальной подгруппы

Удалены устаревшие функции экспериментальных подгрупп "chromium-experimental-subgroups" и "chromium-experimental-subgroup-uniform-control-flow" . См. выпуск 377868468 .

Экспериментальная функция "subgroups" — это всё, что вам сейчас нужно для экспериментов с подгруппами . Экспериментальная функция "subgroups-f16" устарела и скоро будет удалена. Вы можете использовать значения f16 с подгруппами, если ваше приложение запрашивает как "shader-f16" , так и функцию "subgroups" . См. проблему 380244620 .

Устаревшее ограничение maxInterStageShaderComponents

Ограничение maxInterStageShaderComponents устарело по ряду причин:

Избыточность с maxInterStageShaderVariables : это ограничение уже выполняет аналогичную функцию, контролируя объем данных, передаваемых между этапами шейдера.
Незначительные расхождения: Хотя существуют небольшие различия в способе расчета двух ограничений, эти различия незначительны и могут быть эффективно устранены в рамках ограничения maxInterStageShaderVariables .
Упрощение: Удаление maxInterStageShaderComponents упрощает интерфейс шейдера и снижает сложность для разработчиков. Вместо управления двумя отдельными ограничениями с незначительными различиями, они могут сосредоточиться на более подходящем и всеобъемлющем параметре maxInterStageShaderVariables .

Цель состоит в том, чтобы полностью удалить его в Chrome 135. См. намерение объявить его устаревшим и проблему 364338810 .

Утренние обновления

Функция wgpu::Device::GetAdapterInfo(adapterInfo) позволяет получить информацию об адаптере непосредственно из объекта wgpu::Device . См. проблему 376600838 .

Структура WGPUProgrammableStageDescriptor была переименована в WGPUComputeState , чтобы обеспечить согласованность состояния вычислений с состояниями вершин и фрагментов. См. проблему 379059434 .

Значение перечисления wgpu::VertexStepMode::VertexBufferNotUsed удалено. Теперь расположение вершинного буфера, которое не используется, можно выразить с помощью {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} . См. проблему 383147017 .

Здесь описаны лишь некоторые из ключевых моментов. Ознакомьтесь с полным списком изменений .