[deno] Fix some problems in the handling of device limits #8085

andyleiserson · 2025-08-11T23:04:31Z

Fix two problems with the handling of device limits:

Deno was raising a TypeError when a value was over the limit, but it should be an OperationError.
Requesting a limit value below WebGPU's default should ignore the requested value and substitute the default value of such limits.

Testing
Enables some CTS tests.

Squash or Rebase? Squash

Checklist

Run cargo fmt.
Run taplo format.
Run cargo clippy --tests. If applicable, add:
- --target wasm32-unknown-unknown
Run cargo xtask test to run tests.
If this contains user-facing changes, add a CHANGELOG.md entry.

Fixes gfx-rs#8084

andyleiserson · 2025-08-19T16:48:09Z

The limits,maxBindGroups test is failing on dx12 with out-of-memory errors, which may be a similar symptom as the intermittents we have seen with these tests in Firefox.

[fail] webgpu:api,validation,capability_checks,limits,maxBindGroups:setBindGroup,at_over:limitTest="atMaximum";testValueName="atLimit";encoderType="renderBundle" (60ms). Log:
  - EXCEPTION: OperationError: Not enough memory left.
    OperationError: Not enough memory left.
        at LimitTests.requestDeviceTracked (file:///D:/a/wgpu/wgpu/cts/out/common/framework/fixture.js:200:41)
        at LimitTests.requestDeviceWithLimits (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:447:19)
        at LimitTests._getDeviceWithSpecificLimit (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:493:31)
        at LimitTests._getDeviceWithRequestedMaximumLimit (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:556:17)
        at LimitTests.testDeviceWithRequestedMaximumLimits (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:640:40)
        at RunCaseSpecific.fn (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/maxBindGroups.spec.js:194:11)

ErichDonGubler

Mostly LGTM, though I have some questions I'd like to answer before merging.

ErichDonGubler · 2025-08-19T20:38:10Z

wgpu-types/src/lib.rs

+    /// This is not what you want to clamp a request that otherwise might be
+    /// asking for something beyond the supported limits.


suggestion: Modulo maybe some formatting:

Suggested change

/// This is not what you want to clamp a request that otherwise might be

/// asking for something beyond the supported limits.

/// You should not use this method to clamp a request that otherwise might

/// request resources beyond the supported limits.

I reworded to something different than your suggestion:

This function is not for clamping requests for values beyond the supported limits. For that purpose the desired function would be or_worse_values_from (which doesn't exist, but could be added if needed).

It may be that this comment is not generally useful. I tend to mix up min and max when I'm working quickly by writing max when I mean "enforce a maximum value" (which needs min). My motivation for the comment was that it's reasonable for somebody to think "a function to clamp at the maximum should exist", go looking for it, find only this function, and conclude this must be that function. Hence my use of the otherwise somewhat strange language "this is not what you want".

Hopefully my new text still addresses your concerns?

(I found the wording "should not use" strange, it's really "must not be used" or "don't use" -- it won't work. As for choice of better/worse/min/max, see #8084.)

ErichDonGubler · 2025-08-19T20:39:19Z

CHANGELOG.md

@@ -75,6 +75,7 @@ By @Vecvec in [#7913](https://github.com/gfx-rs/wgpu/pull/7913).
 - The function you pass to `Device::on_uncaptured_error()` must now implement `Sync` in addition to `Send`, and be wrapped in `Arc` instead of `Box`.
  In exchange for this, it is no longer possible for calling `wgpu` functions while in that callback to cause a deadlock (not that we encourage you to actually do that).
  By @kpreid in [#8011](https://github.com/gfx-rs/wgpu/pull/8011).
+- `wgpu` now requires that the requested device limits satisfy `min_subgroup_size <= max_subgroup_size`. By @andyleiserson in [#8085](https://github.com/gfx-rs/wgpu/pull/8085).


question: Does this not also apply to wgpu-core? 🤔

I'm not sure if it was on a different PR or I hallucinated it, but when I was revising I thought the suggestion was that specifying wgpu here was redundant and not a good use of precious changelog verbiage. Based on that I reworded it to "The limits requested for a device must now satisfy...".

To answer the question that you actually asked here, it applies to either wgpu or wgpu-core. I think the new text adequately reflects that.

ErichDonGubler · 2025-08-19T20:39:28Z

deno_webgpu/adapter.rs

-            serde_json::from_value(serde_json::to_value(descriptor.required_limits)?)?;
+        // When support for compatibility mode is added, this will need to look
+        // at whether the adapter is "compatibility-defaulting" or "core-defaulting",
+        // and choose the appropriate set of defaults.


suggestion: Could we link this to an issue, so an inquisitive person can follow along with compat development?

Filed and linked #8124.

ErichDonGubler · 2025-08-19T20:42:46Z

cts_runner/test.lst

@@ -19,6 +19,7 @@ webgpu:api,operation,render_pass,storeOp:render_pass_store_op,color_attachment_w
 webgpu:api,operation,render_pass,storeOp:render_pass_store_op,color_attachment_only:*
 webgpu:api,operation,render_pass,storeOp:render_pass_store_op,multiple_color_attachments:*
 webgpu:api,operation,render_pass,storeOp:render_pass_store_op,depth_stencil_attachment_only:*
+fails-if(dx12) webgpu:api,validation,capability_checks,limits,maxBindGroups:setBindGroup,*


question: Thread-ifying this top-level comment:

The limits,maxBindGroups test is failing on dx12 with out-of-memory errors, which may be a similar symptom as the intermittents we have seen with these tests in Firefox.

[fail] webgpu:api,validation,capability_checks,limits,maxBindGroups:setBindGroup,at_over:limitTest="atMaximum";testValueName="atLimit";encoderType="renderBundle" (60ms). Log: - EXCEPTION: OperationError: Not enough memory left. OperationError: Not enough memory left. at LimitTests.requestDeviceTracked (file:///D:/a/wgpu/wgpu/cts/out/common/framework/fixture.js:200:41) at LimitTests.requestDeviceWithLimits (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:447:19) at LimitTests._getDeviceWithSpecificLimit (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:493:31) at LimitTests._getDeviceWithRequestedMaximumLimit (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:556:17) at LimitTests.testDeviceWithRequestedMaximumLimits (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/limit_utils.js:640:40) at RunCaseSpecific.fn (file:///D:/a/wgpu/wgpu/cts/out/webgpu/api/validation/capability_checks/limits/maxBindGroups.spec.js:194:11)

Was this not already happening before? 🤔

The test was not in the wgpu CTS test list prior to this PR. I haven't specifically verified, but I assume that it would fail in cts_runner on dx12 due to the same (deno-specific) functional failures that this PR is addressing.

The OOM problem I do not think is new, but it may or may not have been possible to see it in cts_runner, given the other problems.

andyleiserson requested review from crowlKats and a team as code owners August 11, 2025 23:04

cwfitzgerald assigned crowlKats Aug 13, 2025

andyleiserson force-pushed the limits-operation-error branch from ad10cae to 9d2cb8d Compare August 15, 2025 18:01

This was referenced Aug 16, 2025

[deno] Enable additional vertex formats #8095

Merged

Fix initialization tracking for the destination of copyTextureToBuffer #8099

Open

[deno] Correct error type when a requested limit is too high

b500ca9

andyleiserson force-pushed the limits-operation-error branch from 9d2cb8d to b500ca9 Compare August 18, 2025 00:30

andyleiserson mentioned this pull request Aug 18, 2025

[deno] Requested limits are not clamped at the WebGPU defaults #8084

Closed

andyleiserson changed the title ~~[deno] Correct error type when a requested limit is too high~~ [deno] Fix some problems in the handling of device limits Aug 18, 2025

[deno] Clamp requested limits to the WebGPU defaults

03bca7d

Fixes gfx-rs#8084

andyleiserson force-pushed the limits-operation-error branch from b36e128 to 03bca7d Compare August 18, 2025 21:36

Disable test on dx12

b66d557

ErichDonGubler approved these changes Aug 19, 2025

View reviewed changes

crowlKats approved these changes Aug 20, 2025

View reviewed changes

Edits to comments and changelog from review

23bcc59

andyleiserson merged commit e7a99be into gfx-rs:trunk Aug 20, 2025
40 checks passed

andyleiserson deleted the limits-operation-error branch August 20, 2025 21:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[deno] Fix some problems in the handling of device limits #8085

[deno] Fix some problems in the handling of device limits #8085

Uh oh!

andyleiserson commented Aug 11, 2025 •

edited

Loading

Uh oh!

andyleiserson commented Aug 19, 2025

Uh oh!

ErichDonGubler left a comment

Uh oh!

ErichDonGubler Aug 19, 2025

Uh oh!

andyleiserson Aug 20, 2025 •

edited

Loading

Uh oh!

ErichDonGubler Aug 19, 2025

Uh oh!

andyleiserson Aug 20, 2025

Uh oh!

ErichDonGubler Aug 19, 2025

Uh oh!

andyleiserson Aug 20, 2025

Uh oh!

ErichDonGubler Aug 19, 2025

Uh oh!

andyleiserson Aug 20, 2025

Uh oh!

Uh oh!

Uh oh!

		/// This is not what you want to clamp a request that otherwise might be
		/// asking for something beyond the supported limits.

[deno] Fix some problems in the handling of device limits #8085

[deno] Fix some problems in the handling of device limits #8085

Uh oh!

Conversation

andyleiserson commented Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andyleiserson commented Aug 19, 2025

Uh oh!

ErichDonGubler left a comment

Choose a reason for hiding this comment

Uh oh!

ErichDonGubler Aug 19, 2025

Choose a reason for hiding this comment

Uh oh!

andyleiserson Aug 20, 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!

ErichDonGubler Aug 19, 2025

Choose a reason for hiding this comment

Uh oh!

andyleiserson Aug 20, 2025

Choose a reason for hiding this comment

Uh oh!

ErichDonGubler Aug 19, 2025

Choose a reason for hiding this comment

Uh oh!

andyleiserson Aug 20, 2025

Choose a reason for hiding this comment

Uh oh!

ErichDonGubler Aug 19, 2025

Choose a reason for hiding this comment

Uh oh!

andyleiserson Aug 20, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

andyleiserson commented Aug 11, 2025 •

edited

Loading

andyleiserson Aug 20, 2025 •

edited

Loading