-
Notifications
You must be signed in to change notification settings - Fork 930
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cts_runner and deno_webgpu crate #1859
Conversation
7011fe2
to
6a4b00e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for doing this!
My main concern here is the amount of duplicated code. If it was possible to auto-generate, say, texture formats from a single place, that would help quite a bit. I guess if it was possible, you'd already be doing something like this...
Another question is - what is Deno's plan here? Would you include the whole wgpu
as a sub-module? That's quite a bit of code!
Finally, this marked as WIP. What is missing?
It is possible, and we are considering it. WebGPU has by far the largest API surface of the web APIs we implement (so many types!), so we are sorta pushing this into the future. At some point I want to properly auto generate much JS boilerplate from WebIDL. The same could probably be done for all the enums in
So this gets a little complicated. We have two constraints that we are dealing with from the Deno side:
I propose we do the following:
I want to make sure this implementation can run at least 1 CTS test correctly. Actual CTS infra can be set up in a follow up. |
Looks to be ready now, thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Results from talking about this on a call:
- the TS bindings can be moved out
- build script can be removed
- still want to get the first CTS test running before landing
cts_runner binaries are now not portable anymore. Also startup will now print a bunch of cargo:rerun-if-changed=. This will be fixed in deno_core.
And got CTS working (with these changes to cts: gpuweb/cts#734)
|
Due to the removal of build.rs, startup will now print a bunch of cargo:rerun-if-changed= lines. This is a bug in deno_core, which I'll get fixed soon. Just an aesthetic thing, so shouldn't prevent this PR from landing. |
Ok, this is wonderful. Looks like we are all set now? |
Yup, I think so! |
This PR is a WIP.
@kvark and I discussed how
wgpu
could run tests against cts. CTS is built on the JS API. gfx-rs/wgpu only has a Rust API. One possible solution that was suggested is to use Deno's implementation of WebGPU JS API.Deno implements the glue bindings between the WebGPU JS API, and the Rust wgpu-core.
The PR adds the
deno_webgpu
crate from denoland/deno, and a simple cts_runner runtime which only purpose is to run CTS tests.To try ou the cts runner with a basic compute example: