Skip to content

[deno] Resolve CTS OOMs in CI#8930

Merged
andyleiserson merged 2 commits intogfx-rs:trunkfrom
andyleiserson:jj-push-zprv
Jan 27, 2026
Merged

[deno] Resolve CTS OOMs in CI#8930
andyleiserson merged 2 commits intogfx-rs:trunkfrom
andyleiserson:jj-push-zprv

Conversation

@andyleiserson
Copy link
Copy Markdown
Contributor

@andyleiserson andyleiserson commented Jan 26, 2026

Two changes to enable some CTS suites that would previously OOM in CI:

  • Because the GPUQueue object was lazily constructed the first time the queue was accessed from JS, if JS never accessed the queue at all, the GPUQueue was never created, and thus never dropped, causing queues (and devices, since the queue has a reference to the device) to leak.
  • Associate external memory with the devices in v8, to encourage garbage collection. Unlike extra memory for the command buffers, it required a substantial amount of external memory (16 MB for each dx12 device) to resolve the OOMs. 16 MB for each dx12 device seems reasonable, but I don't know if we might want to make this value platform-specific or do the external memory tracking only in cts_runner.

Testing
Enables CTS tests that weren't working before, although it's not directed coverage for the changes.

Squash or Rebase? Rebase

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.

Comment on lines +165 to +168
// Associate external memory with the device to encourage V8 to garbage
// collect devices promptly.
scope
.adjust_amount_of_external_allocated_memory(DEVICE_EXTERNAL_MEMORY_SIZE);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I wonder if we could do that in servo too.

Copy link
Copy Markdown
Member

@ErichDonGubler ErichDonGubler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, though I'm concerned that I don't know enough about the Deno side to say that this is okay. I think it's easier to start with this good approximation that solves real problems, and then work towards refining this. So, my disposition is to merge first, ask @crowlKats if this is okay later…except that we may build a nontrivial amount of expected passes for tests that we might have to revert later.

I'll approve to unblock, and let other discussion decide how to proceed from here.

Comment on lines +58 to +60
webgpu:api,validation,capability_checks,limits,maxInterStageShaderVariables:createRenderPipeline,at_over:limitTest="atDefault";*
webgpu:api,validation,capability_checks,limits,maxInterStageShaderVariables:createRenderPipeline,at_over:limitTest="atMaximum";*
webgpu:api,validation,capability_checks,limits,maxInterStageShaderVariables:createRenderPipeline,at_over:limitTest="betweenDefaultAndMaximum";*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Is it feasible to simplify to …:createRenderPipeline,at_over:*?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately no, there are still failing cases when limitTest is underDefault and overMaximum (this is noted on line 57).

Filed #8945 for that.

@ErichDonGubler ErichDonGubler self-assigned this Jan 26, 2026
@crowlKats
Copy link
Copy Markdown
Collaborator

crowlKats commented Jan 26, 2026

I am forwarding this to someone else at Deno since I am unfamiliar with the memory related APIs. I'll let you know once I have a response.

Copy link
Copy Markdown
Collaborator

@crowlKats crowlKats left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its an all-ok from our side

Enable some tests that previously OOMed in CI.
@andyleiserson andyleiserson merged commit 965b7cb into gfx-rs:trunk Jan 27, 2026
61 of 62 checks passed
@andyleiserson andyleiserson deleted the jj-push-zprv branch January 27, 2026 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants