godot-proposals
godot-proposals copied to clipboard
godotengine
Add WebGPU support
Describe the project you are working on
Looks like this will ship with Chromium 113 and Firefox 113 (yes, both will have the same version). See https://developer.chrome.com/blog/webgpu-release/ and https://bugzilla.mozilla.org/show_bug.cgi?id=1746245
CanIUse has not been updated yet: https://caniuse.com/webgpu
Also, we have a nice site that makes surveys about device support: https://web3dsurvey.com/webgpu
Describe the problem or limitation you are having in your project
This is essentially Vulkan for web.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
- Improved performance: WebGPU is designed to utilize modern GPUs more efficiently, leading to better overall performance compared to WebGL 2.
- Lower overhead: WebGPU reduces CPU overhead, allowing for more efficient rendering and improved resource management.
- Unified shading language: WebGPU introduces a single, unified shading language (WGSL), simplifying development compared to WebGL 2's multiple shading languages (GLSL, ESSL).
- Better API design: WebGPU offers a more modern and user-friendly API, making it easier to develop and maintain applications.
- Broader hardware support: WebGPU supports more advanced features of modern GPUs, enabling developers to create more complex and visually impressive applications.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
See https://www.w3.org/TR/webgpu/
If this enhancement will not be used often, can it be worked around with a few lines of script?
No.
Is there a reason why this should be core and not an add-on in the asset library?
Yes.
Is this something a first-time contributor without prior knowledge about Godot internals but with WebGPU experience could reallistically implement? I have taken a glimpse at the D3D12 pull request and besides the huge amount of dependencies it adds I feel like it looks manageable.
Is this something a first-time contributor without prior knowledge about Godot internals but with WebGPU experience could reallistically implement? I have taken a glimpse at the D3D12 pull request and besides the huge amount of dependencies it adds I feel like it looks manageable.
@sakrel is already working on a WebGPU renderer for Godot. I suggest you get in touch with them on the Godot Contributors Chat's #rendering channel if you want to help :slightly_smiling_face:
WebGPU seems to be able to unify the graphics api like gles2.
If Godot's renderer is also implemented with WebGPU, it can reduce a lot of maintenance costs, and there is no need for a rendering backend like dx12.
WebGPU seems to be able to unify the graphics api like gles2.
If Godot's renderer is also implemented with WebGPU, it can reduce a lot of maintenance costs, and there is no need for a rendering backend like dx12.
There's likely significant overhead involved in this, on top of not being able to make use of advanced features (such as raytracing extensions). Not to mention build-time complexity would go way up, as WebGPU-related tools are usually written in Rust. I wouldn't go for that route for the same reasons we don't use something like bgfx.
@chrisgliddon Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.
WebGPU seems to be able to unify the graphics api like gles2. If Godot's renderer is also implemented with WebGPU, it can reduce a lot of maintenance costs, and there is no need for a rendering backend like dx12.
There's likely significant overhead involved in this, on top of not being able to make use of advanced features (such as raytracing extensions). Not to mention build-time complexity would go way up, as WebGPU-related tools are usually written in Rust. I wouldn't go for that route for the same reasons we don't use something like bgfx.
Don't we need it for webXR development though?
Don't we need it for webXR development though?
Yes, for the near future we need WebGL for WebXR. There is a proposal for supporting WebGPU in WebXR, but as far as I know, no browsers have implemented it yet. Once there's an implementation or two, it'll take a bit before it can be become a draft standard.
But even aside from that, I think we'll need to keep OpenGL/WebGL around for low-end devices for a while anyway.
Don't we need it for webXR development though?
Yes, for the near future we need WebGL for WebXR. There is a proposal for supporting WebGPU in WebXR, but as far as I know, no browsers have implemented it yet. Once there's an implementation or two, it'll take a bit before it can be become a draft standard.
But even aside from that, I think we'll need to keep OpenGL/WebGL around for low-end devices for a while anyway.
Chrome has. I know that playcanvas is supporting it already too. https://developer.chrome.com/blog/webgpu-release/
Chrome has. I know that playcanvas is supporting it already too. https://developer.chrome.com/blog/webgpu-release/
Are you saying Chrome supports WebXR on WebGPU? Do you have any references about that? The link above is just about WebGPU. Anyway, if true, I'd love to try demos of WebXR on WebGPU with Chrome. :-)
Chrome has. I know that playcanvas is supporting it already too. https://developer.chrome.com/blog/webgpu-release/
Are you saying Chrome supports WebXR on WebGPU? Do you have any references about that? The link above is just about WebGPU. Anyway, if true, I'd love to try demos of WebXR on WebGPU with Chrome. :-)
Maybe I'm wrong, but I don't see how it would be up to Google to do that implementation and not on the app dev.
Note that this doesnt concern only rendering on the web, WebGPU have implementations in C (so C++ too), Rust etc. Therefore this also concern Desktop scenario where one would want to use WebGPU for all devices and platforms. Apparently it's better supported (from day one???) than Vulkan because of no conflicts with Apple's decisions.
Note that this doesnt concern only rendering on the web, WebGPU have implementations in C (so C++ too), Rust etc. Therefore this also concern Desktop scenario where one would want to use WebGPU for all devices and platforms. Apparently it's better supported (from day one???) than Vulkan because of no conflicts with Apple's decisions.
Well well damn I was not aware of that. That's really cool and probably something we should focus on?
Therefore this also concern Desktop scenario where one would want to use WebGPU for all devices and platforms. Apparently it's better supported (from day one???) than Vulkan because of no conflicts with Apple's decisions.
Feature limitations and performance issues are something I'm concerned about with this approach. I think our WebGPU usage should be scoped to the web, avoiding extra abstraction layers where feasible.
Feature limitations and performance issues are something I'm concerned about with this approach. I think our WebGPU usage should be scoped to the web, avoiding extra abstraction layers where feasible.
Understandable. NOte that I'm not a specialist on the subject, but so far my (probalby partially wrong) understanding is that whatever the WebGPU implementation, it have the same feature-set and limitations as Vulkan?
Anyway I'm not a specialist in that domain and I'm still gathering information. I trust that yall will get it right and at worse in limited scope and growing as necessary👍🏽
The advantage of WebGPU is that it's fully crossplatform, and can even run natively using wgpu or Dawn and even support compute shader.
Therefore this also concern Desktop scenario where one would want to use WebGPU for all devices and platforms. Apparently it's better supported (from day one???) than Vulkan because of no conflicts with Apple's decisions.
Feature limitations and performance issues are something I'm concerned about with this approach. I think our WebGPU usage should be scoped to the web, avoiding extra abstraction layers where feasible.
Would using webgpu even prevent diving into lower level graphics apis when you need to? If at the moment all of godot can be run on webgpu on all platforms, and raytracing that requires non-webgpu is a far off thing, why wouldn't webgpu just be the gpu interface for now and then "oh to support ultra graphics you need vulkan or xyz thing" and it calls vulkan despite being majority webgpu, not the other way around?
If the above is true and you can "fall back" to a native gfx api, using webgpu doesn't prevent you from adding any features/performance when you need to and doesn't have any drawbacks at all in current godot.
FWIW: there have been interest in the WebGPU working group to handle Ray Tracing, there are even some draft specs. Realistically it will be awhile though before it is released, however see: https://github.com/codedhead/webrtx
@creikey My understanding is that webgpu provides more advanced functionality and hides underlying details. If you want to call the underlying interface, perhaps angle is a better idea, as it not only supports multiple backends but also provides access to the underlying interface
What are the presently active threads concerning WebGPU? To my knowledge, there hasn't been any public progress.
If there's anyone actively working on WebGPU, kindly make your efforts known.
A master thesis was written on the subject of getting WebGPU in Godot with interesting performance gains: https://www.diva-portal.org/smash/get/diva2:1762429/FULLTEXT01.pdf
Will we want a "forward+" renderer, a "mobile" renderer, or both?
Unfortunately, I think the answer is "both". This will put Godot in the very uncomfortable position of having to maintain 4-5 separate renderers (Vulkan/D3D12 mobile/forward+, WebGPU mobile/forward+, GLES3?).
If it were up to me, I would lean toward totally replacing Vulkan/D3D12 with WebGPU for Godot 5. The performance loss should be minimal, since the existing renderers are far from hyper-optimized anyway.
Any missing features such as raytracing could be worked around with custom "extensions" (see dawn-ray-tracing) for native platforms, or polyfills for the web (see WebRTX).
Using WebGPU as the main rendering API would probably also help attract contributors, since it is much easier to understand.
I am aware that a ton of effort has gone into the Vulkan renderers, and now Google is helping improve the mobile one, so I do understand that this decision would be quite painful.
It seems like the latest technical preview for Safari has added WebGPU support.
https://webkit.org/blog/14879/webgpu-now-available-for-testing-in-safari-technology-preview/
This would allow for a theoretical WebGPU enabled version of the editor to run on iPads/iPhones right?
Will we want a "forward+" renderer, a "mobile" renderer, or both?
Unfortunately, I think the answer is "both". This will put Godot in the very uncomfortable position of having to maintain 4-5 separate renderers (Vulkan/D3D12 mobile/forward+, WebGPU mobile/forward+, GLES3?).
If it were up to me, I would lean toward totally replacing Vulkan/D3D12 with WebGPU for Godot 5. The performance loss should be minimal, since the existing renderers are far from hyper-optimized anyway.
Any missing features such as raytracing could be worked around with custom "extensions" (see dawn-ray-tracing) for native platforms, or polyfills for the web (see WebRTX).
Using WebGPU as the main rendering API would probably also help attract contributors, since it is much easier to understand.
I am aware that a ton of effort has gone into the Vulkan renderers, and now Google is helping improve the mobile one, so I do understand that this decision would be quite painful.
i dont think we should get rid of vulkan or d3d12 as each have there own pros and cons , personally i dont have an issue with a long drop list if we can have more futures.
i dont think we should get rid of vulkan or d3d12 as each have there own pros and cons , personally i dont have an issue with a long drop list if we can have more futures.
vulkan can be supported indirectly through angle, and d3d12 can wait a while for angle to be supported :rofl: (bushi
i dont think we should get rid of vulkan or d3d12 as each have there own pros and cons , personally i dont have an issue with a long drop list if we can have more futures.
vulkan can be supported indirectly through angle, and d3d12 can wait a while for angle to be supported 🤣 (bushi
Angle is only realy for OpenGL ES 2 and 3 (and by extension WebGL 1 & 2)
Angle is only realy for OpenGL ES 2 and 3 (and by extension WebGL 1 & 2)
I'm sorry, I should have made it clearer that it was a joke. I'm not opposed to adding more backends to suit the needs of more scenarios
ps. In our area, (bushi means joke