18 ms·
WebGPU and WSL in Safari
- berdon 7y agoThe helmet gif is breathtaking. The eliding over abstractions as an API simplification is a bit disingenuous. gl.Foo(...) gl.Bar(...) gl.Baz(...) into encoder.setPipeline(pipeline) Unless they're intuiting what needs to be done, those Far, Boo, and Baz calls are still happening somewhere. 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.
- flohofwoe 7y ago...it's the exact same difference like GL to modern 3D-APIs (like Metal, Vulkan or D3D12, or even D3D11). The cost for those Foo, Bar and Baz calls is paid once during the creation of the pipeline object which usually happens at the start of the application. Making that pipeline object active during rendering is very cheap (about as cheap as one of those gl.Foo() calls).
- berdon 7y agoMy point was the post is misleadingly saying: "These 15 lines go away and are replaced by this 1 line". That's not what's happening (unless I'm mistaken) and the code examples are comparing apples to oranges.
- flohofwoe 7y agoWell, yeah ok, the lines move from the drawFrame() function into the init() function basically. It may not be less code to type, but it's much less code to run :)
- berdon 7y agoI re-read the article - and that's just not what the article implies. They make the implication that there's a reduction in "code to type". I suppose this is just an exercise in pedantry though. I'm excited, regardless, for any API simplification.
- jacobolus 7y agoThis seems pretty clear and unambiguous to me > 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.
- berdon 7y agoThat's neither clear nor unambiguous. The text I highlighted including their summary of it states there is a reduction of code. Not only that, the "both APIs" part you're mentioning isn't even pertaining to the code but rather the execution of the pipeline. 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.
- Rusky 7y agoMisleading if the point were that the API got smaller or easier, maybe. 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.
- kevingadd 7y agoFor years if not decades, imperative OpenGL calls like the ones above have been internally building state objects and command buffers. APIs like Vulkan and WebGPU just expose the state objects and command buffers directly. Part of the issue with OpenGL is that the state is hidden behind the driver (due to how much things have changed since the APIs were specified) and you build the state with a massive number of API calls that often need to get RPC'd into a sandbox or what have you. 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.
- saagarjha 7y agoUnrelated: the video doesn’t fit on the screen in Mobile Safari.
- saagarjha 7y agoUpdate: the demo site doesn't work for me either. There's a 404 in the console for https://webkit.org/demos/webgpu/babylon/babylon.max.js.map https://webkit.org/demos/webgpu/babylon/babylon.max.js.map.
- om2 7y agoI've reported the video issue to the author. The demo site requires STP 91 or newer with the WebGPU experimental feature enabled.
- saagarjha 7y agoI'm using Safari Technology Preview Release 91 (Safari 13.1, WebKit 15609.1.3) on a MacBook Pro (Retina, 13-inch, Early 2015) running macOS Catalina 10.15 Beta (19A558d) with the WebGPU experimental feature enabled and not seeing anything. I'd be happy to file a WebKit bug or Feedback Request if you'd like.
- om2 7y agoPlease do! It's working for me with STP 91 on a Catalina beta build. Could be a hardware-specific issue. A bug report would be useful. Please Cc mjs at apple dot com and I'll make sure the right people see it. For reference, do the other demos in the gallery work for you? https://webkit.org/demos/webgpu/ https://webkit.org/demos/webgpu/
- saagarjha 7y agoMight be, my computer has been having a number of OpenGL issues in Catalina. Anyways, I filed https://bugs.webkit.org/show_bug.cgi?id=201765 https://bugs.webkit.org/show_bug.cgi?id=201765 and CC'd you.
- iameli 7y agoThe Web Shading Language is going to have to pick a new acronym; I did a double take when I saw that Windows Subsystem for Linux was coming to Safari
- pavlov 7y agoIt really should be WebSL like everything else in its space (WebGL, WebAssembly, etc.)
- w_s_l 7y agoWeb Scraping Language here. It's just a nice sounding acronym.
- jraph 7y agoWhen two bad names collide in funny ways, creating a "No, this cannot possibly be true" moment.
- om2 7y agoThat’s reasonable feedback.
- SquareWheel 7y agoWebSL is definitely a lot more clear!
- zelly 7y agois tensorflow going to use this?
- enos_feedler 7y agoI would love to see a wasm API for Web GPU and then have a new tensorflow web runtime targeting that.
- zelly 7y agoit would really democratize machine learning so that developers don't have to rent GCP/AWS to serve apps that do inference
- modeless 7y agoTensorflow.js will probably add a WebGPU backend when WebGPU becomes widely available in browsers. But that won't by itself close the performance gap with native ML libraries. For that there is a new W3C community group specifically looking at ways of adding machine learning acceleration to the web: https://www.w3.org/community/webmachinelearning/ https://www.w3.org/community/webmachinelearning/
- nsthorat 7y agoThis backend work has already begun (and can run posenet, albeit still slower than WebGL): https://github.com/tensorflow/tfjs/tree/master/tfjs-backend-webgpu https://github.com/tensorflow/tfjs/tree/master/tfjs-backend-...
- devwastaken 7y agoI'm unsure how they're getting better performance. Webgl is using opengl in a sort of sandboxed manner, does this webgpu approach bypass some checks or find different performant ways to do them? Afaik the biggest problem with gpu access from browsers is that the you instructions are not at all hardware secure. So everything has to be managed.
- adossi 7y agoI just assumed that Apple exposed some API functionality in Webkit that allowed more efficient low-level usage of the GPU hardware. This leads me to believe that adoption of the WebGPU technology will probably fail to break out of the Apple ecosystem.
- kevingadd 7y agoOne big way to improve on performance over WebGL is that WebGL exposes a slow layer on top of an already slow imperative API (OpenGL), while new-style APIs (Vulkan, DX12, Metal) are built around command buffers and state objects that you can assemble and then dispatch to the GPU in big chunks. Think of it like the equivalent between calling memcpy(a++, b++, 1) in a loop and calling memcpy(a, b, n) instead.
- markdog12 7y agoIt's mentioned in the article, GPU calls (and validation) are done up front instead of in the draw loop. If the gallery is accurate though, looks like there isn't any validation right now.
- a13n 7y agoNot really interesting until Chrome adopts it
- Klathmon 7y agoChrome is adopting it! They've signaled "intent to implement", and have started work on it in chrome for mac. https://github.com/gpuweb/gpuweb/wiki/Implementation-Status https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
- Jasper_ 7y agoNote that Chrome has not signaled adoption for WSL (formerly WHLSL), instead preferring to use a profile of SPIR-V. They also put out a demo with the Babylon.js team for this as well. https://medium.com/@babylonjs/webgpu-is-coming-to-babylon-js-c44f8065ac05 https://medium.com/@babylonjs/webgpu-is-coming-to-babylon-js...
- Jasper_ 7y agoWeb Shading Language is a non-starter. I looked quite closely at the specification. Apple has argued in the WebGPU WG that SPIR-V is not defined enough, semantically, to be meaningful, but WSL is even worse. Sometimes, it's even explained in terms of SPIR-V, like in the case of discard, where it was hastily explained in terms of SPIR-V's OpKill after we identified it was completely missing. 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.
- magicalist 7y agoThe wire size comparison is also weird. Are they comparing serving WSL directly (depending on a WSL compiler they went ahead and built into the Safari preview) vs GLSL plus a compiler to convert to SPIR-V because that's not built into any browser (yet)? Why would that be an interesting comparison?
- Jasper_ 7y agoGLSL+glslang+SPIR-V was one of the suggested approaches for developers that want to compile GLSL at runtime on the web. 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.
- magicalist 7y agoBut presumably if that was the eventually standardized format the compiler could ship with browsers, though, right? It just seems weird to compare against another format that hasn't been agreed to either but they shipped the compiler with the browser preview so people can test it. It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.
- The_rationalist 7y agoSuch a shame that webGPU is not Vulkan based... Thanks Apple.
- aseipp 7y agoIt wasn't just Apple, even several Google engineers working on WebGPU agreed that simply mimicking Vulkan wasn't the right model. There are some notes here: https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGUWv_JrkpGizDN0bNq7wY/edit#heading=h.vty7esorrmjf https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGU... 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.
- billconan 7y agoby "network", what they really mean is interprocess communication, right?
- The_rationalist 7y agoThis is not about being a Vulkan fan. Not even about portability. 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.
- kvark 7y agoThe article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works. 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. [1] https://github.com/jrmuizel/glsl-to-spirv https://github.com/jrmuizel/glsl-to-spirv
- monkin 7y ago> The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works. 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."
- swypych 7y agoright?! short of listing all the browsers and renders out there I think they did ok.
- dekimir 7y ago> it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to hear back from Google. 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.
- mtgx 7y agoWhy would anyone adopt Apple's Metal-based WebGPU, when if anything, it's far more likely that all the other major players would adopt something like Mozilla's Vulkan-based Obsidian: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...
- banachtarski 7y agoI trust nothing from Apple when it comes to graphics. My years of pain as a graphics engineer trying to support their hardware and get good performance has created this deepseated mistrust, especially given their track record of abandoning open source standards, including the ones they started! (I'm looking at you, OpenCL).
- markdog12 7y agoAnyone from other browser vendors care to comment? Would love to know their progress and what they think of SPIR-V/WSL.
- pjmlp 7y agoHere are Google WebGPU efforts: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status 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.
- Tobu 7y agokvark is developping the wgpu implementation for Mozilla https://news.ycombinator.com/item?id=20954885 https://news.ycombinator.com/item?id=20954885 https://gfx-rs.github.io/2019/03/06/wgpu.html https://gfx-rs.github.io/2019/03/06/wgpu.html
- pcwalton 7y agoAs a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility. I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. 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.
- om2 7y agoThe only thing that already exists that is provably web-safe is the WebGL dialect of GLSL (which no one seems to like). WebSPIR-V would be based on SPIR-V but in many ways has to be a new thing as well. 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.
- pcwalton 7y agoI don't see any way in which it won't be way more work to migrate to this proposed WSL than to get my existing SPIR-V tooling working with Web SPIR-V.
- om2 7y agoThe actual functionality exposed is close enough that cross-compiling is a solvable problem. But fair point. (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.)
- kevingadd 7y agoYou can always just cross compile your SPIR-V to GLSL or something. People have been cross compiling between HLSL and GLSL for ages, it's a solved problem even if there are sharp edges.
- wffurr 7y agoIn the meantime, they never added support for WebGL2 and MSAA on Framebuffer Objects. Blargh.
- markdog12 7y agohttps://twitter.com/gfxprogrammer/status/1171553288681996288 https://twitter.com/gfxprogrammer/status/1171553288681996288 "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 https://bugs.webkit.org/show_bug.cgi?id=198948 for updates on the work."
- wffurr 7y agoThat's great news! Thank you!
- om2 7y agoWebGL 2 is still a work in progress in WebKit, not abandoned.
- wffurr 7y agoIt's been so long I assumed it was abandoned completely at this point.
- mehmetoguzderin 7y agoThe course of development with WebGPU initiative is breathtaking. The effort poured into the API is producing content that will be consumed by people that desire to study GPGPU applications. 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!
- TazeTSchnitzel 7y agoWe already have the ultimate shading language: SPIR-V.
- atq2119 7y agoThe claim that the developers shaping the WSL specification are experts is questionable given that the actual experts in shading languages -- i.e., the implementers building GPU hardware -- are looking at SPIR-V and seem to be pretty frustrated by the NIH syndrome of the web developer community here.
- xenadu02 7y agoDo you have some evidence for this assertion? Because Apple happens to make its own GPUs and shading language... a shading language that also runs on other people's GPUs. Seems like relevant expertise to me.
- atq2119 7y agoApple is huge. It's not clear to me whether the Apple GPU folks are involved, or whether it's just Apple's web people playing at graphics.
- greggman2 7y agoRandom comment. I've monitored the discussions of WHLSL/WSL vs SPIR-V and I can't decide which side I'm on. 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/ 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 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.
- _pmf_ 7y agoTotally not another side channel. Waiting for WebPCI and WebDMA.
- Tobu 7y agoPlease let Apple's shader language die an early death. 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.
- cromwellian 7y agoHaven’t we been down this text based vs Bytecode avenue before? The same arguments were made with asmjs against Bytecode wireformat, and ultimately we ended up with wasm. WSL seems to be making the same arguments.