Wgpu-rs: Some questions about OpenGL support and overhead by native C-layer

[bvssvni]

I am currently not able to run examples on OSX 10.11.6 because:

• Metal is not installed
• In order to install Metal I need to upgrade Xcode
• In order to upgrade Xcode is need to update the OSX
• The OSX update is broken

I have a Windows computer too (workstation), but I prefer to write code using MacBook Air.

That's why I prefer to use OpenGL when developing new stuff, because even if the API is phased out by new APIs, it works on many platforms, and it works on my preferred device for writing code.

While I'm not concerned about my own private use (I can just buy a new computer at some point in the future) it puts me in a somewhat difficult spot regarding deciding whether to port existing code to WebGPU or write backend specific code.

Currently, OpenGL does not work with WebGPU, but it looks like it might be supported in the future, since Gfx-HAL has a backend for it.

If OpenGL is supported, the software stack will look like this:

WebGPU (Rust wrapper around C layer)
WebGPU-native (C layer)
Gfx-HAL
OpenGL

My questions are:

• Will OpenGL support be added?
• Will the overhead be noticeable for common use cases? (e.g. less than 2%)

I do not require an exact estimate, just asking about what's your thoughts about this.

[zesterer]

I too am quite eager to hear about OpenGL backend support for Veloren.

[kvark]

Hi @bvssvni ! Sorry for getting late on this (had my notifications disabled by mistake).

GL support is certainly planned. In fact, it's already coming in #10
The group has been discussing the limitations of GL, see #2784 for the main one.
It's hard to say what the overhead would be:

• gfx-hal to GL may need more state checking during command recording, and the whole command stream has to be "soft" recorded (stored as a vector of commands) before reaching the GL context. There is unlikely a good way to solve this.
• wgpu-native to gfx-hal does resource tracking that is pretty much useless for GL. This may be partially improved by exposing more info about what backend needs from gfx-hal, but the validation rules still have to be enforced regardless.

At the end of the day, the overhead on GL will be quite real. The only reasonable use to it is to be a fallback, both for native (GL/GLES) and the web (WebGL).

@zesterer I wonder if Veloren team is using or planing to explore wgpu?

[zesterer]

@kvark We are indeed very interested in wgpu, and there's been a lot of talk about switching. However, we're very keen to have OpenGL as a fallback platform (support for low-end devices is quite important to us). If wgpu can provide this, then we'll likely end up looking into switching to wgpu for the 0.4 release.

[bvssvni]

@kvark Thanks for the response! I did not expect support for OpenGL being in the progress already. The use of OpenGL as fallback is interesting.

[kvark]

PR got just merged btw, so I'm closing this issue. Please feel free to continue discussion on the topic!