Что нового в 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 значением при запросе графического устройства. Это полезно в следующем коде приложения, например, где 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, можно найти в спецификации PR .

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

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

Используйте VideoFrame displaySize для внешних текстур

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

Обработка изображений с ориентацией, отличной от стандартной, с помощью copyExternalImageToTexture

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

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

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

To help you, the error messages have been expanded with hints that tell you to explicitly request a higher limit when no limit was specified in requiredLimits when calling requestDevice() . See issue 42240683 .

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

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 .

Обновления Dawn

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

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

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

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

Что нового в WebGPU

Список всего, что было рассмотрено в серии « Что нового в WebGPU» .

Хром 140

Хром 139

Хром 138

Хром 137

Хром 136

Хром 135

Хром 134

Хром 133

Хром 132

Хром 131

Хром 130

Хром 129

Хром 128

Хром 127

Хром 126

Хром 125

Хром 124

Хром 123

Хром 122

Хром 121

Хром 120

Хром 119

Хром 118

Хром 117

Хром 116

Хром 115

Хром 114

Хром 113