Open kvark opened 4 years ago
Part of the task here is figuring out how to test this. Being able to run gfx_ocean is one of the goals.
Copied from https://github.com/gfx-rs/gfx/pull/3231#issuecomment-619543057 :
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.
Also see https://github.com/webgpu-native/webgpu-headers/issues/47 as highly relevant to the way we get async functions.
We need a backend developed to use https://github.com/gfx-rs/wgpu-rs , should be called
gfx-backend-wgpu
.The purpose of this backend would solely be targeting the web: native capabilities of wgpu are not beneficial here. Even though today wgpu-rs doesn't target the web, we can already establish the gfx-rs backend so that we are ready when the time comes.
In terms of difficulty, I expect the logic to be similar to gfx-backend-metal. Of course, we don't expect it to perform as well as targeting the backends directly.