WebGPU 'core-features-and-limits'

explainer.md

WebGPU 'core-features-and-limits' explainer

TL;DR

'core-features-and-limits' is a string that appears in a list of feature strings on a WebGPU adapter and device. It signifies that the adapter/device supports "core" WebGPU. As "core" WebGPU is the only version of WebGPU currently shipping, all implementations of WebGPU are currently required to include 'core-features-and-limits' in their list of supported features.

This is what the spec says today, and what's shipping in Safari, Firefox, and Chrome (behind a flag). In the future, when compatibility mode ships, an adapter/device may not have this feature to signify it is a compatibility mode adapter/device and not a core adapter/device.

Explainer

Chrome (and Firefox) are attempting to ship a "compatibility mode" that runs on older hardware at some point in the future.

The way WebGPU works today

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

This might fail on a system that can't support full "core" webgpu but, in the future, could support "compatibility mode"

The way you request compatibility mode (has not shipped)

const adapter = await navigator.gpu.requestAdapter({ featureLevel: 'compatibility' });
const device = await adapter.requestDevice();

A UA is free to ignore that featureLevel: 'compatibility' parameter and return a "core" adapter/device. This is because a core device is 100% backward compatible with a compatibility device.

A developer might want to design their app so that they can support compatibility mode, but, if core mode exists they want to use more features. To do this they request compatibility mode as above but then check for and, if it exists, request 'core-features-and-limits'

const adapter = await navigator.gpu.requestAdapter({ featureLevel: 'compatibility' });
const hasCore = adapter.features.has('core-features-and-limits');
const device = await adapter.requestDevice({
  requiredFeatures: [
    ...(hasCore ? ['core-features-and-limits'] : []),
  ],
});

In this case, if they see 'core-features-and-limits' then they have a "core" adapter/device. Even without having shipped compatibility mode, a core adapter/device is supposed to always show this feature. Even if you don't request it at all, it's supposed to show the feature on both the adapter and device.

Chrome doesn't currently report this 'core-features-and-limits' yet (without flags). There is the ideal way to distiguish between a core vs compatibility adapter/device. (.)

The hope is, Chrome ships this in stable without a flag ASAP (137 if possible, 138). Then, 1 or 2 versions later, compatibility mode ships.

As it is, developers can test this code with flags, but they can't use it in shipping apps because it returns false for hasCore on current chrome as 'core-feature-and-limits' is behind a flag.

(.) Without this feature developers have 2 options

1. Try to create a core webgpu adapter. It it fails, try to create a compatibility adapter.
2. Try to create a compatibility adapter which may return a core adapter. Then try to cause some operation that generates an error in compatibility mode but not in core mode.

Both of these are are not ideal