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

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

François Beaufort

Поддержка 16-битных значений с плавающей запятой в WGSL

В WGSL тип f16 представляет собой набор 16-битных значений с плавающей запятой в формате IEEE-754 binary16 (половинная точность). Это означает, что для представления числа с плавающей запятой используется 16 бит, в отличие от 32 бит для обычных чисел с плавающей запятой одинарной точности ( f32 ). Меньший размер может привести к значительному повышению производительности , особенно при обработке больших объемов данных.

Для сравнения, на устройстве Apple M1 Pro реализация f16 моделей Llama2 7B, использованная в демонстрационном чате WebLLM, значительно быстрее, чем реализация f32 , с улучшением скорости предварительного заполнения на 28% и улучшением скорости декодирования на 41%, как показано на следующих скриншотах.

Скриншот демонстрационных чатов WebLLM с моделями Llama2 7B f32 и f16. — Демонстрационные примеры чата WebLLM с моделями Llama2 7B `f32` (слева) и `f16` (справа).

Не все графические процессоры поддерживают 16-битные значения с плавающей запятой. Если функция "shader-f16" доступна в GPUAdapter , вы можете запросить GPUDevice с этой функцией и создать модуль шейдера WGSL, который использует тип данных с плавающей запятой половинной точности f16 . Этот тип допустим для использования в модуле шейдера WGSL только в том случае, если вы включите расширение WGSL f16 с помощью enable f16; В противном случае функция createShaderModule() выдаст ошибку проверки. См. следующий минимальный пример и проблему dawn:1510 .

const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("shader-f16")) {
  throw new Error("16-bit floating-point value support is not available");
}
// Explicitly request 16-bit floating-point value support.
const device = await adapter.requestDevice({
  requiredFeatures: ["shader-f16"],
});

const code = `
  enable f16;

  @compute @workgroup_size(1)
  fn main() {
    const c : vec3h = vec3<f16>(1.0h, 2.0h, 3.0h);
  }
`;

const shaderModule = device.createShaderModule({ code });
// Create a compute pipeline with this shader module
// and run the shader on the GPU...

В коде модуля шейдеров WGSL можно поддерживать как типы f16 , так и f32 используя alias зависящий от поддержки функции "shader-f16" как показано в следующем фрагменте кода.

const adapter = await navigator.gpu.requestAdapter();
const hasShaderF16 = adapter.features.has("shader-f16");

const device = await adapter.requestDevice({
  requiredFeatures: hasShaderF16 ? ["shader-f16"] : [],
});

const header = hasShaderF16
  ? `enable f16;
     alias min16float = f16;`
  : `alias min16float = f32;`;

const code = `
  ${header}

  @compute @workgroup_size(1)
  fn main() {
    const c = vec3<min16float>(1.0, 2.0, 3.0);
  }
`;

Расширяйте границы возможного

Максимальное количество байтов, необходимое для хранения одного сэмпла (пикселя или субпикселя) выходных данных конвейера рендеринга, со всеми цветовыми привязками, по умолчанию составляет 32 байта. Теперь можно запросить до 64 байтов, используя ограничение maxColorAttachmentBytesPerSample . См. следующий пример и проблему dawn:2036 .

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

if (adapter.limits.maxColorAttachmentBytesPerSample < 64) {
  // When the desired limit isn't supported, take action to either fall back to
  // a code path that does not require the higher limit or notify the user that
  // their device does not meet minimum requirements.
}

// Request highest limit of max color attachments bytes per sample.
const device = await adapter.requestDevice({
  requiredLimits: { maxColorAttachmentBytesPerSample: 64 },
});

На всех платформах увеличены ограничения maxInterStageShaderVariables и maxInterStageShaderComponents , используемые для межэтапного взаимодействия. Подробности см. в сообщении об ошибке dawn:1448 .

Для каждого этапа шейдера максимальное количество элементов компоновки групп привязки в рамках конвейерной компоновки, являющихся буферами хранения, по умолчанию составляет 8. Теперь можно запросить до 10, используя ограничение maxStorageBuffersPerShaderStage . См. проблему dawn:2159 .

Добавлено новое ограничение maxBindGroupsPlusVertexBuffers . Оно представляет собой максимальное количество слотов групп привязки и вершинных буферов, используемых одновременно, с учетом любых пустых слотов ниже наивысшего индекса. Значение по умолчанию — 24. См. проблему dawn:1849 .

Изменения в состоянии глубины-шаблона

Для улучшения удобства работы разработчиков атрибуты depthWriteEnabled и depthCompare , относящиеся к состоянию depth-stencil, больше не всегда требуются: depthWriteEnabled необходим только для форматов с глубиной, а depthCompare не требуется для форматов с глубиной, если он вообще не используется. См. проблему dawn:2132 .

Обновления информации об адаптере

Теперь при вызове функции requestAdapterInfo() , если пользователь включил флаг "WebGPU Developer Features" по адресу chrome://flags/#enable-webgpu-developer-features , доступны нестандартные атрибуты type и информации об адаптере backend type может быть "discrete GPU", "integrated GPU", "CPU" или "unknown". backend может быть "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" или "null". См. проблемы dawn:2112 и dawn:2107 .

Скриншот сайта https://webgpureport.org с отображением информации о бэкэнде и вводом данных в адаптер. — Информация об адаптере (бэкенд и тип) представлена на сайте https://webgpureport.org .

Необязательный параметр списка unmaskHints в функции requestAdapterInfo() был удален. См. проблему dawn:1427 .

Квантование запросов по временным меткам

Запросы с использованием временных меток позволяют приложениям измерять время выполнения команд GPU с точностью до наносекунды. Однако спецификация WebGPU делает запросы с использованием временных меток необязательными из-за опасений по поводу атак по времени . Команда Chrome считает, что квантование запросов с использованием временных меток обеспечивает хороший компромисс между точностью и безопасностью, уменьшая разрешение до 100 микросекунд. См. проблему dawn:1800 .

В Chrome пользователи могут отключить квантование временных меток, включив флаг "WebGPU Developer Features" по адресу chrome://flags/#enable-webgpu-developer-features . Обратите внимание, что этот флаг сам по себе не включает функцию "timestamp-query" . Ее реализация все еще экспериментальная и поэтому требует флага "Unsafe WebGPU Support" по адресу chrome://flags/#enable-unsafe-webgpu .

В Dawn добавлен новый переключатель для устройств под названием "timestamp_quantization", который включен по умолчанию. Следующий фрагмент кода показывает, как включить экспериментальную функцию "timestamp-query" без квантования временной метки при запросе устройства.

wgpu::DawnTogglesDescriptor deviceTogglesDesc = {};

const char* allowUnsafeApisToggle = "allow_unsafe_apis";
deviceTogglesDesc.enabledToggles = &allowUnsafeApisToggle;
deviceTogglesDesc.enabledToggleCount = 1;

const char* timestampQuantizationToggle = "timestamp_quantization";
deviceTogglesDesc.disabledToggles = &timestampQuantizationToggle;
deviceTogglesDesc.disabledToggleCount = 1;

wgpu::DeviceDescriptor desc = {.nextInChain = &deviceTogglesDesc};

// Request a device with no timestamp quantization.
myAdapter.RequestDevice(&desc, myCallback, myUserData);

Особенности весенней уборки

Экспериментальная функция "timestamp-query-inside-passes" была переименована в "chromium-experimental-timestamp-query-inside-passes", чтобы разработчикам было понятно, что эта функция является экспериментальной и пока доступна только в браузерах на основе Chromium. См. проблему dawn:1193 .

Экспериментальная функция "pipeline-statistics-query", которая была реализована лишь частично, была удалена, поскольку её разработка прекращена. См. проблему chromium:1177506 .

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