There are already available bindings of WebGPU for Rust and C/C++ and of course JS/TS as it is designed for these languages. In case of C/C++ it is called Dawn. Are you going to implement WebGPU interface for C/C++ apps? If I understand correctly it would allow to write shaders using WebGPU Shading Language for all platforms (Linux, Windows, MacOS, Android, Web) and use SDL for other stuff apart from graphics and GPU computations.
1 Like
Thatās already possible using GLSL. My SDL2 app supports shader programming on all those platforms (plus iOS) using OpenGL/GLES/WebGL as the back end.
You can see my app running a common shader benchmark here (needs WebAssembly Threads, so not iOS browsers and some embedded browsers).
Yeah, you are right but according to the WebGL Compute specification WebGL is obsolete and the next framework more close to the metal is WebGPU. The quotation from WebGL specs below:
The WebGL 2.0 Compute specification was a tremendous effort spearheaded by Intel to bring compute shader support to the web via the WebGL rendering context. During the development of this specification, the decision was made to halt further expansion of the WebGL API, and instead focus the contributorsā efforts on the WebGPU specification.
For this reason, this specification should be considered obsolete. The WebGL working group thanks all of the contributors to this specification for their tremendous efforts in specifying and implementing this significant potential addition to the WebGL API. WebGPU will be the path forward for compute shaders on the web.
If I worried about things becoming āobsoleteā or ādeprecatedā my app would have been abandoned long ago! If and when it actually stops working, then Iāll worry. 
I am not going to convince you to rewrite your apps using WebGPU if you have them already working. I understand also that WebGL will be on the market for long time like OpenGL even if Vulkan is going to replace it finally. Simply WebGPU - if I understand it correctly - is going to relpace WebGL.
On the other hand, as I written before, there are already implementations of WebGPU in Rust and C/C++. So it is possible to write render / compute engine using WebGPU and Rust, C/C++, JS/TS and using WebGPU Shading Language instead of GLSL. Now, why reinvent the wheel again. Smart people invented WebGPU because is more close to the hardware in compare to WebGL. It uses as a back end OpenGL, Vulkan, D3D or Metal depending on the platform and availability. So as this is the possible future for Web and also supports all other platforms why not use it in future projects?
And the question is to the creators of SDL, or maybe it is already implemented but I donāt know it.
How similar is WebGPU Shader Language to GLSL? Iām in a particularly tricky situation with my app (itās a programming language) because I expose GLSL to my end users, so any change which means the shader source code has to be altered will be incompatible with their existing programs!
Wow this has to be the most frustrating type of non-answer ever.
WebGpu is solves a huge problem. OpenGL has has no future on Apple platforms and will soon be removed. Vulcan also doesnāt have support for Apple platforms. Where does that leave devs hoping to create a true cross platform 3d game?
Honestly Iām surprised at the crickets in this thread considering how much the goals of both SDL and WebGpu align.
Is there anything coming up? Any discussions? Is this already possible??
Will soon be removed? What evidence do you have of that? As Iāve noted here before, in my iOS build I receive no warnings at all about my use of OpenGL, not even that it is deprecated. Similarly when submitting my app to the iOS App Store, there are no warnings about OpenGL.
Currently, OpenGL is the only option I have in order to target Windows, MacOS, Linux, Android, iOS and in-browser (Wasm) in such a way that I can expose a common shader programming language to my end-users.
If and when WebGPU, or something else, offers that degree of cross-platform support I can consider migrating to it, although as Iāve said that will introduce incompatibilities if the shader programming language is significantly different from GLSL (i.e. canāt easily be āmachine translatedā).
If OpenGL is actually removed from any of the platforms I support before then, I will be screwed. But hopefully there is a recognition (even at Apple!) that having a common 3D/shader back-end across such a wide range of platforms is valuable.
Unfortunately it seems so.
ā¦Once itās removed, which could be two years from now, apps using OpenGL will stop working on devices running the latest operating systems, but will continue to work on devices with older OSes. Apple defends end of OpenGL as Mac game developers threaten to leave | VentureBeat
Itās been a while since that article, but it seems like the intention is to eventually remove OpenGL completely causing existing OpenGL games to stop working. Now you can see my interest in using a future proof cross-platform API 
On that front I found an interesting resource in the WebGPU Native demos repo that uses GLFW in a kind of hacky way for window creation. Could something like this be possible with SDL2? Iād much rather use SDL instead of GLFW.
webgpu-native-examples/src/core/window.c at master Ā· samdauwe/webgpu-native-examples Ā· GitHub
My understanding is that this applies only to MacOS rather than also to iOS. I know that OpenGL has been officially deprecated in MacOS for some time, but the absence of any build-time warnings makes me think the same is not true of iOS.
Why the two platforms would be treated differently I donāt know, unless itās simply the weight of so many more iOS apps using OpenGL than MacOS apps.
Itās just feels like a risky move to continue to develop for OpenGL. Apple has a track record of yanking support for things soon after deprecating (hello flash). Sure itās not a major concern for the short term, but it does feel somewhat like a waste to spend further time learning an API that has no future and whoās support can be cut at any time.
I donāt disagree, but I have no choice. Itās that or a non-working app.
It is rather far from GLSL. You can read about differneces from the professional point of view here (short)
https://dmnsgn.me/blog/from-glsl-to-wgsl-the-future-of-shaders-on-the-web/
and you can read the full specs (long)
https://www.w3.org/TR/WGSL/
From my point of view I regred that not all vendors support Vulkan and that company ārotted appleā even exist making always troubles. But live is like it is. The creators of Dawn
are making also Tint which is
Tint is a compiler for the WebGPU Shader Language (WGSL) that can be used in standalone to convert shaders from and to WGSL
I had no time to test it but maybe this is easy way to translate GLSL to WebGPU.
On the other hand I consider Vulkan as to much complicated. WebGPU looks like really nice compromise between OpenGL and Vulkan. Here I want to warn that WebGPU donāt allow for tesselation and geometric shaders but probably it will allow mesh shaders in the future.
Finally, can we have some response from SDL developers? Or maybe my question was, let to say, stupid and there is no question.
No. Tint is a SPIR-V ā WGSL translator. In case you want to code WebGPU with high level shader language, youāll need some compiler that compiles to SPIR-V such as glslang etc.
SDL3 will have their own (modern) GPU abstraction that will directly wraps DX12, Vulkan or Metal https://github.com/libsdl-org/SDL_shader_tools/blob/main/docs/README-SDL_gpu.md including shader language and bytecode. Itās still early stage of development but looks promisingā¦ Devs say it will wrap WebGPU as well Future 3D API... - #3 by icculus (but unfortunately WebGPU dropped multi worker support for v1 Create a proposal for multi-worker Ā· Issue #354 Ā· gpuweb/gpuweb Ā· GitHub .)
Re: using WebGPU as portability layer; note that their C binding GitHub - webgpu-native/webgpu-headers isnāt finished yet. Since Emscripten occasionally syncs their binding with Dawn, I guess using Dawn for non-web would be a good bet for now although future source compatibility is not guaranteed. SDL allows acquiring platform dependent Window or GPU context from initialized SDL window so integrating Dawn to existing SDL project shouldnāt be too hard. Thereās Dawn integration for GLFW already GitHub - eliemichel/glfw3webgpu: An extension for the GLFW library for using WebGPU native. and similar thing can be done on SDL.
That article seems to conflating deprecation with complete removal. OpenGL is already deprecated on all Apple platforms. On non-Intel platforms (iOS, M-series Macs), OpenGL is actually implemented on top of Metal. Itās unlikely that itāll be completely removed, but obviously isnāt a priority for Apple anymore.
Itās worth keeping in mind that Metal was designed, implemented, and shipped before Vulkan was even announced.
If thatās the case I find it surprising that I get no build-time warnings from Xcode about my use of OpenGLES on iOS. Nor do I get any warnings when submitting to the App Store.
Apple has publicly stated that OpenGL is deprecated. Iām not surprised you arenāt getting warnings when submitting to the App Store, since OpenGL/GLES are deprecated but not currently slated for future removal.
When building using Appleās OpenGL headers (as opposed to GLAD, GLEW, etc), you get a deprecation warning. Building a Mac app that uses OpenGL gives a long list of deprecation warnings like this:
pl_mpeg_player.c:62:3: warning: 'glGenTextures' is deprecated: first deprecated in macOS 10.14 - OpenGL API deprecated. (Define GL_SILENCE_DEPRECATION to silence these warnings) [-Wdeprecated-declarations]
glGenTextures(1, name);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl.h:2498:13: note: 'glGenTextures' has been explicitly marked deprecated here
extern void glGenTextures (GLsizei n, GLuint *textures) OPENGL_DEPRECATED(10.0, 10.14);
^
Mac apps, yes. Not only is OpenGL deprecated, its functionality was partly broken some while ago (if I remember rightly SDL_RENDERER_PRESENTVSYNC stopped working and SDL had to work around it). But I use the prebuilt SDL2 Framework so I donāt see any build errors related to that,
It was the absence of similar warnings when building for iOS from source that surprised me. Iām not explicitly including any Apple headers, my use of OpenGL stems solely from SDL2 (Iām using the standard 2.28.2 source package but with Metal disabled).
iOS apps as well. Appleās headers have all GLES 1, 2, and 3 functions marked as having been deprecated in iOS 12. You can see for yourself by finding OpenGLES.framework on your system and looking at the headers inside.
As to why you arenāt seeing the deprecation warnings even when building SDL, Iām assuming that SDL is using its own GLES definitions like in SDL_opengles2_gl2.h and friends.
Could be. Whatever the cause, I can build my iOS apps without any warnings, and since I have no choice but to use OpenGLES that suits me fine!