Is there any chance that I can choose to enable what backend will be compiled into the binary?

[xhebox]

Is your feature request related to a problem? Please describe.
I've tried gfx-hal, and that is good library. But wgpu is much easier to use than gfx. I prefer wgpu and I know clearly I only want to use vulkan. Despite what backend flags I passed to init the instance, gl backend is also compiled.

Describe the solution you'd like
Some features passed from wgpu-rs to wgpu, so that I can choose what I want to use.

Describe alternatives you've considered
None

Additional context
None

[kvark]

Are you concerned about the code size for the GL backend that becomes a part of the binary? It would be interesting to make a test, say with your application, by compile-time disabling GL and seeing how it affected the size. This would be done by checking out wgpu and adding a patch section to your Cargo toml.

[xhebox]

Yes, it is around 0.7MB using cargo-bloat. Another big library is spirv_cross. This is what I got under windows, after removing gl and dx11:

cargo bloat --release --crates

 File  .text     Size Crate
23.3%  34.3%   1.7MiB spirv_cross
22.2%  32.6%   1.6MiB std
11.8%  17.3% 877.4KiB [Unknown]
10.7%  15.7% 795.2KiB wgpu_core
 0.1%   0.1%   4.4KiB wepoll_sys
68.0% 100.0%   4.9MiB .text section size, the file size is 7.3MiB

I'll get the output under linux later.

[kvark]

SPIRV-Cross has just become an optional dependency in #1220, so maybe this is fine now?
Note that there is going to be a bit of a delay before wgpu-rs can consider it to be optional.

[xhebox]

OK, I remembered it wrong... Basically the largest one is spirv_cross. Of course, this result is with lto = true. This is the result under linux:

15.3%  21.2% 758.8KiB wgpu
13.7%  19.0% 678.7KiB spirv_cross
 9.0%  12.5% 446.7KiB std
 8.1%  11.2% 401.0KiB wgpu_core
 7.0%   9.7% 346.9KiB naga
 3.2%   4.4% 156.9KiB [Unknown]
 2.8%   3.9% 138.8KiB wgpu_lut
 2.5%   3.4% 122.4KiB gfx_backend_gl
 1.8%   2.6%  91.3KiB inplace_it
 1.7%   2.3%  83.4KiB hashbrown
 1.1%   1.5%  52.8KiB gfx_backend_vulkan
 0.8%   1.2%  41.7KiB gpu_descriptor
 0.7%   1.0%  35.2KiB ash
 0.5%   0.7%  24.7KiB spirv_headers
 0.4%   0.6%  21.1KiB async_io
 0.4%   0.6%  20.6KiB gfx_hal
 0.4%   0.5%  18.0KiB async_global_executor
 0.3%   0.4%  14.8KiB glow
 0.3%   0.4%  14.1KiB parking_lot
 0.2%   0.3%  11.0KiB miniz_oxide
 1.4%   1.9%  68.9KiB And 26 more crates. Use -n N to show more.

This what I got without lto:

14.7%  23.8% 972.8KiB wgpu
10.3%  16.7% 680.9KiB spirv_cross
 6.1%   9.9% 403.6KiB naga
 5.4%   8.7% 357.4KiB std
 5.4%   8.7% 355.3KiB wgpu_core
 4.2%   6.7% 275.7KiB inplace_it
 2.8%   4.6% 186.7KiB wgpu_lut
 2.4%   3.9% 157.5KiB gfx_backend_gl
 2.1%   3.5% 141.0KiB [Unknown]
 1.3%   2.1%  85.7KiB hashbrown
 1.0%   1.6%  66.3KiB gfx_backend_vulkan
 0.8%   1.3%  54.1KiB ash
 0.5%   0.8%  32.1KiB async_global_executor
 0.5%   0.8%  31.3KiB glow
 0.4%   0.7%  29.8KiB async_io
 0.3%   0.6%  23.2KiB gpu_descriptor
 0.3%   0.5%  20.9KiB gpu_alloc
 0.3%   0.5%  20.9KiB gfx_hal
 0.2%   0.3%  13.5KiB spirv_headers
 0.2%   0.3%  13.3KiB parking_lot
 1.5%   2.4%  96.6KiB And 36 more crates. Use -n N to show more.
61.5% 100.0%   4.0MiB .text section size, the file size is 6.5MiB

Well, I guess that I found that spirv_cross is used by other backends. So I want to disable other backends. I won't close the issue. It is indeed possible that other backends will involve some unused dependencies.

[kvark]

This is very informative, thank you!
Would you mind doing a local patch to wgpu-rs that doesn't enable "cross" feature in wpu-core? I'm curious to see the numbers when this feature isn't enabled.

[xhebox]

Here it is :)

[profile.release]
panic = "abort"
strip = "debuginfo"
lto = true

20.0%  26.7% 804.9KiB wgpu
12.1%  16.2% 487.0KiB std
10.3%  13.8% 416.0KiB naga
10.0%  13.4% 403.4KiB wgpu_core
 3.9%   5.3% 158.9KiB gfx_backend_gl
 3.4%   4.5% 136.5KiB wgpu_lut
 3.3%   4.4% 132.6KiB inplace_it
 2.4%   3.2%  97.4KiB hashbrown
 1.3%   1.8%  53.3KiB gfx_backend_vulkan
 1.0%   1.4%  41.3KiB gpu_descriptor
 0.9%   1.2%  35.2KiB ash
 0.7%   0.9%  28.0KiB spirv_headers
 0.5%   0.7%  21.1KiB async_io
 0.5%   0.7%  20.6KiB gfx_hal
 0.5%   0.6%  18.2KiB async_global_executor
 0.4%   0.6%  16.8KiB [Unknown]
 0.4%   0.5%  14.8KiB glow
 0.4%   0.5%  14.1KiB parking_lot
 0.3%   0.4%  11.0KiB miniz_oxide
 0.2%   0.3%   8.3KiB smallvec
 1.5%   2.0%  61.4KiB And 26 more crates. Use -n N to show more.
74.7% 100.0%   2.9MiB .text section size, the file size is 3.9MiB

I believe that wgpu can be made smaller somehow. You could also use cargo bloat to track the largest part in wgpu. link here.

[Shatur]

It would be great to control backends. In Bevy, for example, wgpu is a public API. And to be able to run the same game logic on the server, I need to build Bevy with wgpu, but without backends: bevyengine/bevy#3155 (comment)

[kvark]

If backends can be enabled individually with features, how can we make sure that people can just use "auto" mode - the logic that we have now? I.e. introducing features would immediately require the users to complicate their cargo manifests with something like this:

[target.'cfg(target_arch = "wasm32")'.dependencies]
wgpu = { version = "0.11", features = ["gles"] }

[target.'cfg(all(not(target_arch = "wasm32"), any(target_os = "ios", target_os = "macos")))'.dependencies]
wgpu = { version = "0.11", features = ["metal"] }

[target.'cfg(all(not(target_arch = "wasm32"), unix, not(target_os = "ios"), not(target_os = "macos")))'.dependencies]
wgpu = { version = "0.11", features = ["vulkan", "gles", "renderdoc"] }

[target.'cfg(all(not(target_arch = "wasm32"), windows))'.dependencies]
wgpu = { version = "0.11", features = ["vulkan", "dx12", "renderdoc"] }

I don't think our users are going to be excited for this...

@Shatur it's clear you don't want to run the same rendering logic on client and server. So wgpu use in the logic you do want to run is rather accidental, is it?

[Shatur]

I.e. introducing features would immediately require the users to complicate their cargo manifests with something like this:

Totally agree, I understand why we have prereconfigured backends.

it's clear you don't want to run the same rendering logic on client and server. So wgpu use in the logic you do want to run is rather accidental, is it?

It would be great to avoid having wgpu on server. But for relatively complex games, the server uses exactly the same logic as the client. So in Bevy we could do the following:

1. Guard all wgpu usage with compile-time checks. But this make code very ugly, see Add headless renderer bevyengine/bevy#3155 (comment)
2. Add additional API over wgpu that "fakes" wgpu if wgpu is disabled in features. But it is very difficult to maintain and it's basically mirroring of wgpu code.
3. Use wgpu as a public API by simply removing all rendering backends from the server. This is how it done in Godot.

@cart suggested to use the approach number 3, but it currently impossible due to preconfigured backends for specific platforms. So I decided to ask 😄 Is it possible to move this preconfigured features to default-features to let users opt-out them?

[kvark]

Main blocker is that default features can't be platform dependent. I think it's rust-lang/cargo#1197, although Rust issues are sometimes hard to navigate... If it was possible, we'd take it in a heartbeat.

There is another possible solution just for your case - via backends of wgpu-rs itself (as opposed to wgpu-core). It currently has the "web" backend and the wgpu-core backend. It needs also to have a "native header" backend, linking to an implementation to webgpu-headers. So we could add a "dummy" backend there.

Problem is - this would only help your case but not @xhebox or other peoples similar needs. So I can't recommend this path.

[Shatur]

So we could add a "dummy" backend there.

Hm... Yes, it would solve the problem.

Problem is - this would only help your case but not @xhebox or other peoples similar needs. So I can't recommend this path.

Agree, it would be better to solve the problem globally via backend configuration. But now I'm not sure if there is an elegant solution. We could move out automatic backend selection into a separate crate that depends on wgpu, but it looks dirty. The dummy backend seems like a more clean solution as to me.