Compat-ify samples (more difficult). #495

SenorBlanco · 2025-03-13T20:19:41Z

These samples required changes beyond requesting compatibility mode.

a-buffer

requires storage buffers in fragment stage (issue 19)
depth texture binding cannot be used in textureLoad() (issue 16)
- bind as texture_2d<f32> (and unfilterable-float sampleType) instead
interpolate(flat) not supported (issue 17)
- use interpolate(flat, either) instead

bitonicSort

requires storage buffers in fragment stage (issue 19)

cubemap

textureBindingViewDimension must be specified for cubemap sampling (issue 1)

deferredRendering

depth texture binding cannot be used in textureLoad() (issue 16)
- bind as texture_2d<f32> (and unfilterable-float sampleType) instead
requires storage buffers in fragment stage (issue 19)

reversedZ

depth texture binding cannot be used in textureLoad() (issue 16)
- bind as texture_2d<f32> (and unfilterable-float sampleType) instead

samplerParameters

requires storage buffers in vertex stage (issue 18)

skinnedMesh

requires storage buffers in vertex stage (issue 18)

textRenderingMsdf

requires storage buffers in vertex stage (issue 18)
requires storage buffers in fragment stage (issue 19)

videoUploading

no additional changes required (missed this one in the first pass)

wireframe

requires storage buffers in vertex stage (issue 18)

These samples required changes beyond requesting compatibility mode. a-buffer * requires storage buffers in fragment stage (issue 19) * depth texture binding cannot be used in textureLoad() (issue 16) * bind as texture_2d<f32> (and unfilterable-float sampleType) instead * interpolate(flat) not supported (issue 17) * use interpolate(flat, either) instead bitonicSort * requires storage buffers in fragment stage (issue 19) cubemap * textureBindingViewDimension must be specified for cubemap sampling (issue 1) deferredRendering * depth texture binding cannot be used in textureLoad() (issue 16) * bind as texture_2d<f32> (and unfilterable-float sampleType) instead * requires storage buffers in fragment stage (issue 19) reversedZ * depth texture binding cannot be used in textureLoad() (issue 16) * bind as texture_2d<f32> (and unfilterable-float sampleType) instead samplerParameters * requires storage buffers in vertex stage (issue 18) skinnedMesh * requires storage buffers in vertex stage (issue 18) textRenderingMsdf * requires storage buffers in vertex stage (issue 18) * requires storage buffers in fragment stage (issue 19) videoUploading * no additional changes required (missed this one in the first pass) wireframe * requires storage buffers in vertex stage (issue 18)

greggman

See comments. The pattern in the PR would be okay in say 6 months but it doesn't work today.

greggman · 2025-03-13T20:37:12Z

sample/a-buffer/main.ts

+const adapter = await navigator.gpu?.requestAdapter({
+  featureLevel: 'compatibility',
+});
+const device = await adapter?.requestDevice({
+  requiredLimits: { maxStorageBuffersInFragmentStage: 2 },
+});


@kainino0x pointed out this will fail on current chrome/firefox/safari

To make it work requires only adding it IF maxStorageBuffersInFragmentStage exists on adapter.limits because otherwise it's an unknown limit and will fail device creation.

There's a bunch of solutions - they all have trade offs.

Here's one

Suggested change

const adapter = await navigator.gpu?.requestAdapter({

featureLevel: 'compatibility',

});

const device = await adapter?.requestDevice({

requiredLimits: { maxStorageBuffersInFragmentStage: 2 },

});

const adapter = await navigator.gpu?.requestAdapter({

featureLevel: 'compatibility',

});

const { maxStorageBuffersInFragmentStage } = adapter.limits;

// Note: maxStorageBuffersInFragmentStage may be undefined in old browsers

// but that's ok as it will fail this check and old browser only support core

// which always has enough storage buffers in fragment shaders.

if (maxStorageBuffersInFragmentStage < 2) {

fail('maxStorageBuffersInFragmentStage < 2'); // export from util.ts

}

const device = await adapter?.requestDevice({

requiredLimits: { maxStorageBuffersInFragmentStage },

);

Note: I'm not sure that example is acceptable nor not since it's not requesting 2, it's requesting max. The more I have to deal with features and limits the more think you should just always get max limits. It's much easier to deal with.

const adapter = await navigator.gpu?.requestAdapter({ featureLevel: 'compatibility', }); const device = await adapter.requestDevice({ requiredFeatures: adapter.features, requiredLimits: objLikeToObj(adapter.limits), // need a helper ATM }); if (device.limits.maxStorageBuffersInFragmentStage < 2) { fail('I can has no running'); }

It's way simpler than the summersault of checking for in adapter and applying in device but it's not the intent of the spec. 😕

function objLikeToObj(objLike) { const obj = {}; for (const key of objLike) { obj[key] = objLike[key]; } return obj; }

Thanks.

const { maxStorageBuffersInFragmentStage } = adapter.limits;

gave me:

(!) [plugin typescript] sample/a-buffer/main.ts (20:9): @rollup/plugin-typescript TS2339: Property 'maxStorageBuffersInFragmentStage' does not exist on type 'GPUSupportedLimits'. /home/senorblanco/src/webgpu-samples/sample/a-buffer/main.ts:20:9

I used

if ('maxStorageBuffersInFragmentStage' in adapter.limits) {

instead. LMK if that's kosher.

Note: I'm not sure that example is acceptable nor not since it's not requesting 2, it's requesting max. The more I have to deal with features and limits the more think you should just always get max limits. It's much easier to deal with.

It is easier, but I think it's dangerous, in that it turns WebGPU into OpenGL: you could write some code that runs fine on your machine (with above-average limits), but won't run elsewhere (with default limits). I'd prefer to request the minimum that the sample actually needs.

const { maxStorageBuffersInFragmentStage } = adapter.limits;

It gets an error because the types need to be updated

npm install --save-dev @webgpu/types@latest

sample/bitonicSort/utils.ts

sample/deferredRendering/main.ts

sample/samplerParameters/main.ts

sample/skinnedMesh/main.ts

sample/textRenderingMsdf/main.ts

This will prevent breakage on WebGPU implementations that don't support those limits yet.

greggman · 2025-03-14T00:58:35Z

sample/a-buffer/main.ts

+if ('maxStorageBuffersInFragmentStage' in adapter.limits) {
+  limits = { maxStorageBuffersInFragmentStage: 2 };
+}
+const device = await adapter?.requestDevice({


This code will just throw if maxStorageBuffersInFragmentStage < 2 and the user gets a blank screen. Given we surface other errors I think it would be good to surface something, which is why I suggested something like

if (maxStorageBuffersInFragmentStage < 2) { fail('maxStorageBuffersInFragmentStage < 2); // export from util.ts }

Good catch, thanks. I thought the samples were checking for requestDevice() failure, but I see they're not.

I've implemented better limit checking. LMK what you think.

requestDevice never fails (never turns null/undefined) so "if called correctly" there's nothing to check

greggman

lgtm! one nit.

greggman · 2025-03-17T19:53:27Z

sample/util.ts

+  if (limit in adapter.limits) {
+    const limitKey = limit as keyof GPUSupportedLimits;
+    const limitValue = adapter.limits[limitKey] as number;
+    if (limitValue < requiredValue) {


nit: some limits are minXXX instead of maxXXX. Up to you if you want if it now or wait for someone to stumble on it.

Renamed QuitIfLimitNotMet() -> QuitIfLimitLessThan(). Someone else can make the GreaterThan flavour if desired.

Implement a "quitIfLimitNotMet()" helper that tests for the existence of a limit in adapter.limits, checks that it meets a certain value, and errors if not. If successful, it will add the limit to a GPURequiredLimits object.

SenorBlanco requested review from greggman and kainino0x March 13, 2025 20:21

SenorBlanco force-pushed the enable-compat-difficult branch from 48ef20c to a6c3e5f Compare March 13, 2025 20:26

SenorBlanco force-pushed the enable-compat-difficult branch from a6c3e5f to a5044b8 Compare March 13, 2025 20:30

greggman requested changes Mar 13, 2025

View reviewed changes

Only require limits if we know they exist.

02db960

This will prevent breakage on WebGPU implementations that don't support those limits yet.

SenorBlanco force-pushed the enable-compat-difficult branch from 0fedee7 to 02db960 Compare March 13, 2025 23:35

greggman reviewed Mar 14, 2025

View reviewed changes

SenorBlanco force-pushed the enable-compat-difficult branch 3 times, most recently from fbba277 to 378e878 Compare March 17, 2025 19:06

SenorBlanco requested a review from greggman March 17, 2025 19:08

greggman approved these changes Mar 17, 2025

View reviewed changes

SenorBlanco force-pushed the enable-compat-difficult branch 5 times, most recently from 2c2744e to c9770d4 Compare March 17, 2025 20:21

Implement better limit checking.

85eb241

Implement a "quitIfLimitNotMet()" helper that tests for the existence of a limit in adapter.limits, checks that it meets a certain value, and errors if not. If successful, it will add the limit to a GPURequiredLimits object.

SenorBlanco force-pushed the enable-compat-difficult branch from c9770d4 to 85eb241 Compare March 17, 2025 20:22

SenorBlanco merged commit 50fdb54 into webgpu:main Mar 17, 2025
1 check passed

SenorBlanco deleted the enable-compat-difficult branch March 21, 2025 20:04

Compat-ify samples (more difficult). #495

Compat-ify samples (more difficult). #495

Uh oh!

Conversation

SenorBlanco commented Mar 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

greggman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greggman Mar 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

greggman Mar 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greggman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

SenorBlanco commented Mar 13, 2025 •

edited

Loading

greggman Mar 13, 2025 •

edited

Loading

greggman Mar 14, 2025 •

edited

Loading