Add WebGPU backend

[GabrielMajeri]

This PR adds a WebGPU backend for gfx-hal, making some progress towards #3027.

I've currently gotten the backend to compile. Further additions will come in future PRs.

[monocodus]

This is an autogenerated code review, only first 25 of 88 new suggestions are shown

The .monocodus config not found in your repo. Default config is used.
Check config documentation here

[monocodus]

This is an autogenerated code review, new suggestions: 7

The .monocodus config not found in your repo. Default config is used.
Check config documentation here

[kvark]

Oh wow, you are attacking this task, this is great news!
Please note that #3027 doesn't explain clearly how this needs to be done. We didn't understand all the details ourselves. So let me at least try to do a better job here.

So the main goal of this backend is to target the Web. This means, we don't care in particular about wgpu-core or even wgpu-native (even though that one could go through emscripten to the Web). Instead, we care about the path that wgpu-rs uses for the Web backend, which is web-sys.

Now, if you just try to link to wgpu-rs, you'll be forced to deal with the fact that this is meant to be used by the end users and not intermediate layers. The API can be restrictive, making this backend impossible. Therefore, I believe the only sensible path for gfx-backend-wgpu is to link to web-sys directly and calling the web methods, without linking to any of the wgpu ecosystem crates at all.

Does that make sense? @grovesNL can correct if I said this wrong.

[GabrielMajeri]

Yeah, makes sense. I will look into switching to web-sys.

The only problem I've encountered so far, is that some of the WebGPU APIs are async (for example requesting a device). How do we expose that through the gfx-hal API?

[kvark]

That's one of the architectural blockers to resolve, it could be a serious issue.
I wonder if we can just have an executor blocking on that? I.e. to start, just have an executor being a part of the backend, and call block_on on the wasm_bindgen_futures::JsFuture that is supposed to be async.
@grovesNL ^

[grovesNL]

@kvark we won't be able to use block_on on the web (e.g. rustwasm/wasm-bindgen#1733 (comment))

[GabrielMajeri]

Does this mean we'll have to modify the gfx-hal API to be async?

[kvark]

No, we aren't going to modify gfx-hal API here.
We need to figure out what to...

[grovesNL]

I'm not sure of the best way to handle this, some options could be:

• modify gfx-hal's API
• expose async functions as a feature specific to WebGPU, so we'd have separate entry points specific to WebGPU
• work with promises/futures internally in most functions/types, so functions are implemented behind promise chains (e.g. device_promise.then(device => device.xyz()))
• try to find some way to yield the browser temporarily at the Rust level (like async/await itself does internally), similar to Emscripten's Asyncify https://emscripten.org/docs/porting/emscripten-runtime-environment.html#using-asyncify-to-yield-to-the-browser

Maybe there are other ways to handle this?

[GabrielMajeri]

The easiest solution for now seems to be to expose separate entry points specific for WebGPU (at least temporarily, until a better solution is proposed).

I could make the open function panic when called, telling people to instead use open_async or something like that on WASM.

Would that be acceptable?

[monocodus]

This is an autogenerated code review, new suggestions: 20

The .monocodus config not found in your repo. Default config is used.
Check config documentation here

[monocodus]

This is an autogenerated code review, new suggestions: 21

The .monocodus config not found in your repo. Default config is used.
Check config documentation here

[kvark]

@GabrielMajeri this would let you to proceed and get something working. Similar to how we have OpenGL API somewhat working but requiring application changes for a while (but no more). When we find a proper solution for async, we wouldn't need to scrap a lot of code, so there is nothing to lose if we go this direction here.

[GabrielMajeri]

@kvark Alright, I've started work on that. Would it be OK to get this merged as-is (since its just boilerplate code), and add instance creation in the next PR, for easier review?

[kvark]

Yeah, as long as CI is happy :)

[GabrielMajeri]

Ok! I've looked at the logs for the failing build. It seems to be an ICE on nightly:

error: internal compiler error: src/librustc_mir/interpret/validity.rs:396:
Unexpected error during ptr inbounds test: cannot read from foreign (extern) static DefId(0:40 ~ dispatch[5c52]::ffi[0]::[0]::_dispatch_queue_attr_concurrent[0])

I'll see if it's already reported.

[kvark]

@GabrielMajeri also, let's please rename this to gfx-backend-webgpu in folder "webgpu". This matches "vulkan" and "metal" better, since they aren't "vk" and "mtl". We also don't want to confuse people with the idea that this is going through wgpu library, since we are going to target the Web directly.

[monocodus]

This is an autogenerated code review, new suggestions: 20

The .monocodus config not found in your repo. Default config is used.
Check config documentation here

[GabrielMajeri]

@kvark Noted, renamed everything from wgpu to webgpu.

[kvark]

I'm disabling monocodus warnings in #3234. Sorry about the mess it makes!

[kvark]

bors try

[bors]

try

Build failed:

• continuous-integration/travis-ci/push

[kvark]

Looks like the nightly failure will be fixed in the next nightly...

[kvark]

bors try

[bors]

try

Build failed:

• continuous-integration/travis-ci/push

[kvark]

@GabrielMajeri sorry, looks like it needs to be updated now that Mesh shaders have landed. It should be fairly straightforward though. Would you mind rebasing and updating it?

error[E0046]: not all trait items implemented, missing: `draw_mesh_tasks`, `draw_mesh_tasks_indirect`, `draw_mesh_tasks_indirect_count`
   --> src/backend/webgpu/src/command.rs:134:1

[GabrielMajeri]

No problem, fixed now.

[kvark]

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push