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

Франсуа Бофор
François Beaufort

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

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

Добавлены формат вершин "unorm8x4-bgra" и следующие однокомпонентные форматы вершин: "uint8" , "sint8" , "unorm8" , "snorm8" , "uint16" , "sint16" , "unorm16" , "snorm16" . "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), реализация оператора сброса использует семантику, предоставляемую платформой, для понижения уровня до вспомогательного вызова, если он доступен. Это повышает производительность шейдеров, использующих сброс. См. выпуск 372714384 .

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

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

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

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

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

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

Чтобы помочь вам, сообщения об ошибках были дополнены подсказками, которые советуют вам явно запрашивать более высокий предел, если предел не был указан в requiredLimits при вызове requestDevice() . См. выпуск 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» по адресу 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 .

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

Что нового в WebGPU

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

Хром 133

Хром 132

Хром 131

Хром 130

Хром 129

Хром 128

Хром 127

Хром 126

Хром 125

Хром 124

Хром 123

Хром 122

Хром 121

Хром 120

Хром 119

Хром 118

Хром 117

Хром 116

Хром 115

Хром 114

Хром 113