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!
We won’t be building an implementation of WebGPU from scratch (such as Dawn or wgpu did), if that was the question.
But you can definitely use WebGPU with SDL. One can use SDL for all the window management, input, audio, etc and use WebGPU with the SDL-created window, the same way that one can with Direct3D, etc now. I haven’t tried it, but I assume one could use Dawn for this purpose.
In addition to that, we are building a 3D API of our own for SDL3. Its goals are similar to what WebGPU is planning, but is focusing on simplicity and portability as primary features.
The FAQ for that is here. One of the things SDL will be able to use behind the scenes, eventually, is WebGPU. This will be a requirement for Emscripten builds that want to run C/C++ on the web using this new API if nothing else.
1 Like
This is great, if only I could use it! But as you know I can’t migrate to SDL3 because it doesn’t support OpenGLES 1.1, which I need for glLogicOp(). You did once hint that you might reconsider that decision, but I presume nothing has come of it.
Thanks for the answer. I see that my question was a little bit silly. I always used OpenGL or Vulkan backend and proper option in SDL_CreateWindow. That is why I thought that there should be an option for WebGPU as well. Now I see that Dawn is taking care of proper initialization of any backend and SDL will just create window (creation of the context is on Dawn). I will try to run SDL+Dawn+WebGPU.
I regret that you are not trying to use WebGPU Shading Language as it is almost finalized (or maybe I am wrong). As you said they and you have the same goals. Both WebGPU Shading Language and yours SDL Shading Language looks very similar to me. Both are inspired by Rust. The compiler of WebGPU Shading Language will be probably good optimized over time and for free to use. No need to work hard to make your own.
The imposter syndrome is strong with this one 
The point of SDLSL is a language whose compiler can easily be integrated into SDL, have a relatively small footprint, and not need extra work to get it to build. Adding external dependencies can be a real hassle.
3 Likes