WebGPU and WSL in Safari
webkit.org
webkit.org
Please, everyone, just use something that already exists. It is frustrating how the big players constantly use new and incompatible graphics APIs to try to obtain some sort of competitive advantage, adding to the workload we developers have to deal with. There is almost no cost to the platform developers to add new APIs; instead, the costs are borne by the application developers. It's a classic case of negative externalities.
Edit: I originally said "WebGPU dialect of GLSL" which is not a thing. I meant "WebGL dialect of GLSL", which is a thing and which works ok in practice.
(On the flip side, having two syntactically very similar but actually different things can be dangerous, as it may lead devs to think some tooling works when it actually doesn't.)
Also please stop trying to influence a technical debate in a standardization group by putting blog posts on top of Hacker News.
As far as posting blog posts, we think this is just as fair as the Chrome team's communication about their own WebGPU implementation, which included a public demo and sessions at Google I/O which were widely reported.
As for the post getting upvoted to the top of Hacker News, that's the community's choice, not ours. The initial poster wasn't even an Apple person (afaik). If you are insinuating some kind of vote manipulation then that is inaccurate.
The other benefit was that changes could be made to improve the usability of the shading language without having to wait on all vendors to update their compilers. If the change was just syntactic sugar, it could be made without changing the SPIR-V. It's kind of like how you don't need an operating system update to move from C++98 to C++11.
Apple isn’t alone this regard; as far as I can tell Windows does this too because they don’t commit to a stable syscall interface like Linux does. That being said, you may find Apple’s official stance on statically linking your binaries amusing: https://developer.apple.com/library/archive/qa/qa1118/_index...
In general, Apple links a lot of things to their OS releases: while their toolchains are distributed separately they’re practically tied to one or two major OSes unless you engage in hacks to make them continue working. And the languages which they exercise significant control over (namely Swift and Objective-C) are often tied to OS versions.
ANGLE is the base of the WebGL implementation in Chrome. For WebGPU, we (Google) are working on a new native library called Dawn[2] that will fill the same role that ANGLE does for WebGL. I'm personally hopeful that Dawn itself can eventually be useful as a cross platform graphics abstraction for native apps as well as web apps. There's also Mozilla's gfx-rs[3] in the same space.
[1] https://github.com/google/angle
Even on Mac OS it wasn't available, rather Quickdraw 3D was the API to go to.
Had Apple been successful with their in house OS, and surely they wouldn't have cared about OpenGL.
WWDC 1999: Mac OS 9 - A work in progress https://youtu.be/LkmSrCsKPLk?t=1360
Also note that Copland did not have any OpenGL support planned.
We still don't know when Apple will actually remove GL from their platforms, but since the backlash will be so huge, it might be a while. And even when they do, the first step of 95% of code-bases that rely on GL will be to link in some GL on Metal emulation library. The net effect will be a slight performance drop for Apple vs other platforms. Well done Apple.
At some point switching to Vulkan (and Vulkan on Metal for Apple, or the reverse if you're an Apple centric developer) may be worth it, but for the moment the amount of apps and games that will see close to identical performance in GL and Vulkan is still huge. If you are e.g. geometry/shader/memory bound, you'll see exactly 0% speedup from API changes. You really need to be pushing significant amount of draw calls to see a difference. If you're not doing this, its worth "hanging in there" with GL to see if the post-GL landscape de-clusterfucks itself in the meantime :)
Says one "who is currently knee-deep in papering over platform incompatibilities", instead of using one of the solutions that do it for you.
(I didn't downvote you.)
To anyone who has ever spent time working on a platform API this is deeply insulting.
> …the costs are borne by the application developers.
Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.
This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)NaCL.
I've worked on platform APIs too. Maybe "almost no cost" wasn't the right phrase, but there's certainly less cost for the platform vendor.
> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.
It's a tradeoff that has to be evaluated on a case-by-case basis. So far I haven't seen arguments for WSL that are compelling enough.
-- Path 1: We do need a leap here, and that leap should be essentially unleashing GPGPU primitives (memory barriers, etc.). The web is a ~decade behind, when we have a chance to 10X+ over what regular apps do.
-- Path 2: If not, then pure conservative standards work a la webgl2. Useful, and should take care for politicking to not prevent Path 1 from happening in parallel.
It's disconcerting for, ~7 years later, the same problems to keep happening.
On the other hand, we, the ordinary developer must pay the cost of supporting N APIs on M platforms. Every APIs carelessly invented by vendors just because almost no extra cost burden us all.
AMDN and Khronos are still fighting to get the love of CAD industry, adding back OpenGL features, because after having to create Iris Inventor like APIs in-house, they aren't keen in switching to yet another low level API.
Instead of a modern API, frameworks, 3D model format, IDE support for debugging shaders, we get plain old C, extensions creep, and go search yourself for basic feature like displaying text or loading textures.
Hardly an improvement on OpenGL status quo.
I did my graduation thesis in OpenGL, hunting for libraries that kind of work together, and doing from scratch what every other OpenGL beginner has to go through, is no fun.
Every Vulkan book does the same, first set of chapters are tips about which libraries to hunt for.
The dark side allows for a better gratification on time to pixel, instead of rites of passage.
Something that Khronos has failed to learn with OpenGL and their Vulkan SDK proves that they didn't actually learn their lesson.
If Vulkan SDK was actually at the same level as DirectXTK, Metal Kit, 3DS SDK, PhyreEngine,GX2... maybe it would get more love from those us that rather embrace the dark side.
It make an enormous amount of existing code available on the web.
It just wasn't agreed to by Firefox because it didn't have enough JS.
I’m one of the most vehement proponents for the use of platform-specific UI toolkits here, but even I disagree with that this statement without qualification. Standards, in general, are a useful thing to have. We’ve occasionally seen (for example, in the case of application frameworks) that each platform doing their own thing has now made it so that the better experience for the user is the non-general API. But standardized interfaces (POSIX, OpenGL, JavaScript) when done right have been a boon for developers and end-users alike.
Making the end result in industrial code bases hardly much different from implementing multiple times.
Apple has blocked any possibility of using a SPIR-V profile, sometimes with bad-faith arguments, despite it being the suggestion of all other vendors and the graphics community participating in the WG.
The team working on the WSL compiler had to have dominator analysis patiently explained to them, and then told us it was too complex of a concept, despite being something learned about in Compilers 101.
Google has been working on getting a minimal form of glslang out the door, but they're having trouble because glslang is a pretty big beast.
It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.
You cannot do that in .NET Native, for example.
But there's also a direct comparison of WSL vs SPIR-V wire size in he same graph, for cases where SPIR-V would be generated in advance.
Edit: Also seems like they are leaning pretty heavily into Babylon.js. I don't think a standard should be developed that closely with any one specific application or framework.
WebGPU itself is guided by input from many framework and engine developers.
Many developers already know that they will have to make significant overhauls to upgrade to WebGPU. "If WebGPU turns out to be as powerful as we all hope it to be libraries like Three.js will likely have to be rewritten from scratch in order to take full advantage of it." [0]
[0] https://github.com/mrdoob/three.js/issues/15936#issuecomment...
It’s really funny to say that we had to have dominator analysis patiently explained to them. I don’t have a clue what you are talking about there. In one meeting I remember having to explain dominator analysis to SPIR-V folks. (I am both a member of the WSL team and an expert on dominator analysis.)
Simple branching in shaders is notoriously under-defined as well because of complications related to divergence/convergence and the SIMT model.
re: dominator analysis, it was brought up by an Apple WebGPU developer (Myles C. Maxfield) as a complexity of parsing SPIR-V. David Neto had to explain it to Myles. https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTW...
Your claim that the WSL spec tells you very little seems off to me. The spec includes formal semantics for everything. If some things aren't in the spec yet they can be added. There is also a pretty extensive test suite. To me the level of specification rigor is considerably higher than SPIR-V, which has an informal spec with separate documents for adding web safety.
The spec has a semantics that describes that the language does when executed in great detail.
It seems that your complaint is that there is some thing that you think that SPIR-V describes better than WSL - waves and quads in this case.
I was there when we brought up dominators. You are right that we brought it up as a complexity of SPIR-V, but not because we didn't know what dominators are. We do know what they are, and because we do know, we know that it's complex. We're not saying "it's so complex that we don't understand it". We are saying "we understand it and we know it's complex". In particular, an early argument against text-based languages is that you have to specify and then validate variable scoping. Dominator analysis is a variable scoping rule, just a very complicated one for a wire format to have.
Here's what the WSL specification says about loading a texture, one of the simplest possible features of a shading language, but one that introduces a lot of complexity (again, to load a texture requires calculating an LOD, which requires talking about derivatives and scheduling pixels and shader execution in terms of quads):
> Todo: fill this section Sample, Load, Gather, etc..
That's it.
Now, your Babylon.JS demo clearly samples textures. So you have some semantics implemented, but what semantics are they? Note that these things are baked pretty heavily in hardware, so if you get the semantics wrong, you can't really fix the hardware. Your semantics have to model reality as it exists. Your automated tests can say that the spec is correct, but might break on a real GPU after translation to SPIR-V/Metal/HLSL.
The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.
Fun fact: The current modelling of "discard" of as OpKill instead of OpDemoteToHelperInvocation is incorrect for Metal's "discard", which I presume is one of your backends right now.
On the other hand, the SPIR-V working group has no participation from Apple or Microsoft (vendors of relevant platform APIs, relevant shading languages, and in Apple's case, of relevant GPUs).
You might argue that Apple should join the SPIR-V group but you could likewise argue that AMD and Nvidia should join the WebGPU group. After all, their voices would be valuable as to the API and not just the shader language. The barrier to entry to a W3C Community Group is also much lower.
Nobody inside the WG but Apple wants WSL.
(I personally don't think any option is a "nonstarter" but it's hard to even get agreement on the relevant evaluation criteria.)
This is arguably ahead of the proposed web dialect of SPIR-V (which needs to subset the language, add validation steps, and insert safety checks).
SPIR-V is also proven to compile to all the target APIs for WebGPU, while WSL only has a MSL transpiler right now.
[1] https://github.com/gpuweb/spirv-execution-env/blob/master/ex...
Although they created and gave OpenCL 1.0 to Khronos, they were not happy with the path that Khronos was taking it and their support basically stagnated on OpenCL 1.0.
As side note Google is yet to support OpenCL on Android, instead just like they did with their Android Java, they decided to create their own flavour, Renderscript, which isn't compatible with OpenCL.
As for OpenGL ES, I bet they only did it, as they were trying to "play pretend" being another kind of Apple as survival mechanism, nowadays they don't need it any longer.
Finally, Metal is one year older than Vulkan, offers a modern API instead of plain old C, and contrary to Khronos, just like other platform vendors, Apple understands the value of providing nice frameworks and debugging tools to go along an API.
Is it really though? Vulkan is based on AMD Mantle which AMD gave to Khronos. AMD Mantle (2013) predates Apple Metal (2014).
When Apple released Metal, Mandle was still an AMD API.
I'm not talking about pre-NeXT Apple, that's ancient history.
Many just don't realise how they were fooled to believe in the wolf in desguise.
Corporations do whatever to save themselves.
Do you think Microsoft will keep being FOSS champion, after they wipe out the board?
How naive are those that assign human behaviour to corporations.
You should have a look to pwcalton's Twitter feed if you want a quick overview of how nice the tools in questions are. Getting a kernel panic when running Xcode doesn't sound like “nice debugging tools” to me…
The only way I’m using any thing like this is through a tool or library or framework like Unreal Engine, where I just don’t have to care.
This is short term win long term loose, yes the platform specific programs look good now, but long run this stuff is going to be a negative as people look to avoid dealing with multiple platform specific frameworks.
I’m hoping the return of a proper Mac Pro is going to steer back against this trend. I’m reasonably confident that if third party gpu support is ok, then all of the work apple puts into optimisations on these Apple specific graphics languages is going to take a back seat, if NVidia are going to sell me a GPU for the Mac Pro, I’m confident that they care much more about CUDA than anything apple specific.
For shading languages, it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to hear back from Google. Side note: we are currently experimenting [1] with Rust-based SPIR-V generation, and the transformation is looking to be mostly trivial - there is no reason it should be slow.
A bigger question though that needs to be resolved is how to specialize SPIR-V shaders. Without this, there is no good alternative to text-based cut-and-paste that the blog argues to be the best approach.
The first thing you read is: "WebGPU is a new API being developed by Apple and others in the W3C which enables high-performance 3D graphics and data-parallel computation on the Web."
Off the top of my head:
- glslang supports all previous GLSL versions and profiles, which adds many checks and corner cases throughout the code
- it's tricky to generate correct SPIR-V; for instance, it took me a while to properly understand the constraints around basic-block ordering
Disclaimer: I left Google in 2016 and haven't looked at glslang/shaderc since. I am only offering personal opinions here.
Is the OpSpecConstant family not enough? Those exist specifically for specialisation.
Maybe they're on some ego trip to leave their mark in a more visible way than through shaping the shared effort in various places and want to have a big thing to call their own. Or maybe they just want to get some vendor lock-in.
But it's yet another slightly-incompatible, slightly-better slightly-worse alternative to the existing shader languages, and nobody wants to deal with that, just like nobody really wanted to care about Metal. Apple's tight control over their devices will probably force some people to build some kind of compatibility layer into their pipelines, but it won't have to be good, and it won't be the primary target.
"We're collaborating with Dean and the WebKit team to use ANGLE for WebGL's backend in WebKit, which will allow an easy upgrade to WebGL 2.0 on all platforms. Follow https://bugs.webkit.org/show_bug.cgi?id=198948 for updates on the work."
Think of it like the equivalent between calling memcpy(a++, b++, 1) in a loop and calling memcpy(a, b, n) instead.
Their performance chart only lists Mac computers, so I assume under the hood this specific implementation is either translating WebGPU calls to Metal calls or at least the implementation is more like Metal. I suppose on other platforms, replace Metal with Vulkan or DirectX 12.
I just like reading about this stuff, I am not a graphics programmer, so I may be wildly off base.
The potentially expensive stuff has basically been moved out of the render loop, and into the initialization phase. For instance, when you create a shader in WebGL, that shader may be patched and recompiled internally when it is used for different situations (for instance different render target pixel formats). And "last minute" changes like this happen all over the place in GL and WebGL, because the GL model has so many flexible "knobs" that can be pressed at any time.
In WebGPU everything is "baked" at creation time. You may need to create more "state objects" upfront for all possible state combinations you need, and this creation may be more expensive than in the GL model, but once those state objects are created they are very efficient to use, and more importantly, they wont be "recompiled" during use.
It's a similar effect like having an unpredictable GC which can kick in at any time and produce frame spikes (like Javascript), versus not having a garbage collector at all (like WASM).
WebGPU also needs a lot fewer calls in the "hot path" compared to WebGL. When in WebGL you may need dozens of calls to change state between draw calls, in WebGPU it's only a handful.
I built a WebGPU-like layer [0] for my 3D web application https://noclip.website , so I get some of the performance benefits today, under ANGLE, but WebGPU has these best-practices baked in, so everyone will see an increase.
[0] https://github.com/magcius/noclip.website/blob/master/src/gf...
I'm quite confident that WebGPU will still provide a nice performance boost compared to carefully written WebGL, because the API is a better match to the underlying native APIs (D3D12, Vulkan and Metal), while ANGLE is basically a GLES2/3 "emulator" on top of D3D, and D3D11 is quite different from the GL programming model.
Great job you did there..
https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
Which already mentioned on the standard meetings that although Chrome already ships a prototype implementation of Web Compute, they don't plan to fully productise it, rather take the learnings from the community into WebGPU shaders.
gl.Foo(...)
gl.Bar(...)
gl.Baz(...)
encoder.setPipeline(pipeline)
That's not to say abstraction isn't a useful way of separating out code. And OpenGL/WebGL's pipeline setup has always been a bit archaic. This is definitely progress - it's just not really being presented directly in the article.
Making that pipeline object active during rendering is very cheap (about as cheap as one of those gl.Foo() calls).
That's not what's happening (unless I'm mistaken) and the code examples are comparing apples to oranges.
It may not be less code to type, but it's much less code to run :)
I suppose this is just an exercise in pedantry though. I'm excited, regardless, for any API simplification.
> Most 3D applications render more than a single object. In WebGL, each of those objects requires a collection of state-changing calls before that object could be rendered. [...] All the pieces of state in the WebGL example are wrapped up into a single object in WebGPU, named a “pipeline state object.” Though validating state is expensive, with WebGPU it is done once when the pipeline is created, outside of the core rendering loop. As a result, we can avoid performing expensive state analysis inside the draw call. Also, setting an entire pipeline state is a single function call, reducing the amount of “chatting” between Javascript and WebKit’s C++ browser engine.
> Resources have a similar story. Most rendering algorithms require a set of resources in order to draw a particular material. In WebGL, each resource would be bound one-by-one. However, in WebGPU, resources are batched up into “bind groups”. [... In both APIs] multiple objects are gathered up together and baked into a hardware-dependent format, which is when the browser performs validation. Being able to separate object validation from object use means the application author has more control over when expensive operations occur in the lifecycle of their application.
The clear point in both of these comparisons is that the same operations must be done in both APIs, but the WebGPU version allows much of the work to be pre-computed, allowing the draw calls (where the performance bottleneck lies) to have as little overhead as possible.
My point is, and has been, that they should focus on the perf gains and reduce the misleading sentiment that it has simplified the API footprint.
gl.UseProgram(program1);
gl.frontFace(gl.CW);
gl.cullFace(gl.FRONT);
gl.blendEquationSeparate(gl.FUNC_ADD, gl.FUNC_MIN);
gl.blendFuncSeparate(gl.SRC_COLOR, gl.ZERO, gl.SRC_ALPHA, gl.ZERO);
gl.colorMask(true, false, true, true);
gl.depthMask(true);
gl.stencilMask(1);
gl.depthFunc(gl.GREATER);
gl.drawArrays(gl.TRIANGLES, 0, count);
encoder.setPipeline(renderPipeline);
encoder.draw(count, 1, 0, 0);But the point is instead that the amount of work done in the main render loop is smaller. Those 15 lines do go away in that sense- they only happen once on startup under the new API.
A carefully specified API like WebGPU that exposes state objects can allow those to be built outside the sandbox (in user content) and efficiently RPCd in a smaller set of calls.
It is realistic to say those calls go away, even if similar calls have to happen "once". In comparison, when I port native apps over to WebGL I'm invoking dozens of WebGL API calls every time I draw some tris and it's SUPER SLOW. Compared to that the cost of doing some basic setup is a rounding error.
Included in the final specification or not, a well-tailored shading language is only of benefit to the GPGPU community, similar to how simultaneous existence of DirectX, Metal, Vulkan has been to the robustness of the abstractions of the engines built upon them. No one should doubt the rigor of developers that are shaping the WSL specification; they are experts in their game. Moreover, the web mode of SPIR-V will also have considerable differences in its morph, and all parties are trying to find a good common denominator where none of the existing works is an exact solution; the work of Apple here will benefit everybody going forward.
Also, we are getting GPGPU computing abilities in the browser for a much broader market on many form factors! Let's prepare for it!
I started in the SPIR-V camp. I liked the idea that WebGPU would just get "shader assembly language" and that would let a 1000 other higher level languages blossom. I also liked the idea that injesting assembly seemed easier and less code than injesting a higher level language.
But, Apple had their original WHLSL post (https://webkit.org/blog/8482/web-high-level-shading-language...) and I liked some of their arguments for a text based language. I like the idea that I can just make snippet/jsfiddle/codepen and don't need a entire tool chain nor any 3rd party libraies just to get something working. I have 100s of standalone WebGL samples that have next to zero external code. I'd like to do the same with WebGPU but if it's SPIR-V based that will be impossible.
I also agreed that AFAICT SPIR-V being more assembly language like is not really a help. To validate it still requires a bunch of work, understanding it as a whole (building up an AST?) and checking everything so it's not clear to me there's a win there. The SPIR-V came does list some valid points here in relation to validation
https://github.com/gpuweb/gpuweb/issues/44
It's also been pointed out that SPIR-V is not a small format. Suggestions have been made that if you care about download size you'd send some other format that is smaller + a library to decompress/compile that format into SPIR-V. That sounded less interesting to me as again I need now both an offline toolset and a library to use its results.
I don't remember why but at some point I gravitated back toward the SPIR-V camp but when I went over the arguments it turned out to be mostly a tie.
I feel like if someone wrote a WSL or GLSL to SPIR-V compiler that was very small (50k to 100k compressed JS), ideally in JavaScript not WebAssembly, that might help decide the issue? Unfortunately AFAIK none of the devs involved with WebGPU are JS programmers so they do things like re-compile ANGLE's GLSL compiler via Emscripten as a solution which turns into a large bloated library with multiple parts.
I hate the idea that I won't be able to create small WebGPU demos without large external libraries or without finding places to host binary spirv files. A small library might push me in the SPIR-V camp. Without that I think I lean to the WSL camp.
I think the SPIR-V camp would argue that small samples don't matter. What matters is AAA games and AAA apps like Google Maps and those teams don't care if they have to use large offline toolsets. They'd also argue there's 2 or 3 orders of magnitude more devs using a large library like three.js than using low-level WebGL so the fact that without a large library the experience sucks is irrelevant. So again, I don't know which direction is better.
All in all there's waaaaay more reasons to use SPIR-V.
There’s also a good chance that in the end the shader processing will be in a common library like ANGLE.
With GLAL the issues were much more about the drivers consuming a textual language than about the browser consuming a textual language.
The bit about network transparency is the most interesting one IME (which, in this case, assumes the "network" is essentially a collection of intercommunicating system processes, not nodes), as well as the bits about how Vulkan exposes too much of the vendor model to the programmer, which also isn't their goal. But it's a very sensible goal for Vulkan itself on the desktop.
If anything, the work on the gfx-rs means that WebGPU might actually end up as a more low-ish-level "portable" graphics API than Vulkan itself if you want to target every major platform + the web. In particular, gfx-hal is a non-Vulkan abstraction layer on top of D3D12/Metal/Vulkan, and webgpu-native/wgpu-rs provide WebGPU APIs for desktop platforms (in C/Rust) based on gfx-hal. Eventually you should be able to target WebGPU+WebAssembly too. I just ran a wgpu-rs demo yesterday on my mac with Metal and on my Windows desktop with DX12 with no changes! Pretty good stuff so far. And if you're a die hard Vulkan fan and don't care about WebGPU, then gfx-portability will let you program against Vulkan while building on gfx-hal, all the same, so you can still target Windows/Mac. (It would be interesting to ask how gfx-rs overcomes the problems outlined in the above design doc.)
The shading language will probably end up being the most contentious point in the end, but ultimately I think the overall tool quality/available for desktop is impressive, and WebGPU will probably end up as a good offering in the design space.
The real issue is the one no one talk about. Webgpu is the intersection of features from Vulkan, directX 12 and metal. Which means that webGPU is a subset of Vulkan, metal and DX, by design it is less powerful than metal, less powerful than DX and less powerful than metal. By being an intersection, by design they've created a sub-par, non evolutive api. As a consequence, performance reachable on desktop, and expressivity of possible software and graphical features will be inferior on the web which is deeply sad
Nobody understanding and stating that is another sad thing.
Good luck making sense of Vulkan in 10 years time.
Metal, in my opinion, strikes the best balance between performance and low-level control.
With Vulkan the intention is that you have multiple codepaths for every vendor for good performance. This is way too much effort for an API that is already of little relevance.
I think that with AZDO-style extensions to OpenGL/WebGL you would've gotten 95% of the performance benefit without adapting a whole new rendering API (and shading language). Unfortunately, AMD could never get a proper OpenGL driver going so they pushed for Mantle which ultimately turned into Vulkan.
Where Metal is really different, in a good way, is that it has progressive complexity. You can use the basic commands and get pretty far, allowing the driver to manage lifetimes for you and not caring about multi-threading too hard. But then there are ways to get more control, gradually, which you can opt into later. This is very different from Vulkan's all-or-nothing approach.
For the Web, it seems to me that having the same property would work best.
They've signaled "intent to implement", and have started work on it in chrome for mac.
https://medium.com/@babylonjs/webgpu-is-coming-to-babylon-js...