search

gfx-rs / gfx

[maintenance mode] A low-overhead Vulkan-like GPU API for Rust.
http://gfx-rs.github.io/
Apache License 2.0
5.35k stars 548 forks source link

wgpu backend #3027

Open kvark opened 4 years ago

kvark commented 4 years ago

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.

kvark commented 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.

kvark commented 4 years ago

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.

kvark commented 4 years ago

Also see https://github.com/webgpu-native/webgpu-headers/issues/47 as highly relevant to the way we get async functions.