4 ms·

This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. It's

by tormeh 4y ago

This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. It's already the best way to code cross-platform graphics outside the browser. This release in Chrome ought to bring lots more developer mindshare to it, which is an awesome thing.

gostsamo 4y ago
or it will be yet another standard
- pl90087 4y ago
  [flagged]
- tormeh 4y ago
  Not really. I don't see how any of the vendors could break it without being extremely overt about it. And it has no direct competition. Nothing else runs on any OS and any GPU, except WebGL, which is abandoned.
  - illiarian 4y ago
    > I don't see how any of the vendors could break it without being extremely overt about it. > except WebGL, which is abandoned. So it can be abandoned
    - tormeh 4y ago
      It becoming a stale standard is maybe the biggest threat, yes. It has the issue all standards have since several actors have to play along, except this time it isn't Nvidia, Apple, and AMD, but Wgpu/Mozilla and Google. Their incentives are hopefully better aligned with users than those of the hardware vendors. I suspect WebGL was different, since it was based on the old OpenGL/DX9 way of doing things, so a clean break was desireable. But I honestly am not that knowledgeable in neither graphics programming nor WebGL history, so take that with several grains of salt.
      - pjmlp 4y ago
        WebGL was based on OpenGL ES 2.0 and a subset of OpenGL ES 3.0. Google refused to support WebGL compute based on OpenGL ES 3.0 compute shaders, citing WebGPU alternative, and there are still quite a few capabilites from OpenGL ES 3.2 missing from WebGL. Some of which still not available in WebGPU 1.0.
    - whitehexagon 4y ago
      Pretty impressed with WebGL2, and it is already on most platforms, so I hope it wont be pushed aside by this. I assumed WebGPU was going to be more about a Web based OpenCL implementation, is OpenCL also being pushed aside by this then? and wasnt there a plan to do some compute with WebGL? I cant keep up! I hope this myriad of new Chrome APIs being pushed slows down enough for some new browser vendors to enter the market. Or is this just a push for a new 'native' browser experience single horse race...
  - kllrnohj 4y ago
    Vulkan & GLES are both the obvious competition here, I don't know why you seem to be ignoring them?
    - tormeh 4y ago
      Vulkan doesn't run on Apple platforms. And Apple refuses to upgrade their OpenGL drivers. So no, they don't count. Then there are the consoles, which also have their own APIs. Expecting all vendors to implement a common API is a fool's errand, and we should stop trying. The vendors don't want this, and we can't force them. Any common GPU API must be an abstraction over vendor-specific ones.
      - kllrnohj 4y ago
        MoltenVK exists and runs Vulkan on Apple devices perfectly fine. Almost certainly better than WebGPU does even. Vulkan is already a common API both in theory and in practice. It's not a nice API, but it is common and vendor neutral all the same. A lot moreso than WebGPU is, even, since Khronos has a much more diverse set of inputs than the web does. See eg all the complaints about Chrome dominating the web discussion, and even beyond that you only really need 3 companies on board. Khronos has significantly more at the table than that.
illiarian 4y ago
> This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. Instead we have a third graphics standard (after canvas and WebGL) fully incompatible with the previous two that does exactly that: abstracts the OS graphics stack in a new layer
- adrian17 4y ago
  Further, in some ways it's the "lowest common denominator" (so that it can be easily implemented on top of each "underlying" graphics API), with union of all their downsides and only intersection of upsides.
- flohofwoe 4y ago
  WebGPU brings some important improvements that are simply impossible to implement with the WebGL programming model (such as moving all the expensive dynamic state validation from the draw loop into the initialization phase). It's not perfect mind you (e.g. baked BindGroups may be a bit too 'rigid'), but it's still a massive improvement over WebGL in terms of reduced CPU overhead.
- dilawar 4y ago
  obligatory xkcd: https://xkcd.com/927/ https://xkcd.com/927/
pjmlp 4y ago
There are lots of ways to write code cross-platform graphics outside the browser, it has been available for decades, it is called middleware. WebGPU outside of the browser not only suffers the pain of being yet another incompatible shading language, it is also offers the additional possibility of having code incompatible with browsers WebGPU support, due to the use of extensions not available on the browsers.
- flohofwoe 4y ago
  AFAIK the WebGPU implementations outside the browser can all load SPIRV directly, no need to translate to WGSL first.
  - pjmlp 4y ago
    Yes, and that is one of the reasons why I wrote it is also offers the additional possibility of having code incompatible with browsers WebGPU support.
    - flohofwoe 4y ago
      These differences are smaller than the differences between desktop GL and WebGL though. It's just another option in the low-level vs high-level 3D API zoo. As far as wrapper APIs go, the native WebGPU implementation libraries are a pretty good option, because being also used in browsers there's a ton of testing and driver bug workarounds going into them which other 3D API wrapper projects simply can't afford to do.
      - pjmlp 4y ago
        Not at all. First of all, if one depends on SPIR being present, then a SPIR to WGSL compiler needs to be present when deploying to the Web part of WebGPU. Secondly, it will be yet another extension spaghetti that plagues any API that Khronos has some relation to.
        flohofwoe 4y ago
mike_hearn 4y ago
"Webgpu solves the incentives problem where all actors tries to lock you in" Or flipped around, it creates an incentive problem where none of the vendors see much benefit in doing R&D anymore, because browsers aren't content to merely abstract irrelevant differences, they also refuse to support vendor extensions except for their own. No point in adding a cool new feature to the GPU if Chrome/Safari insists on blocking it until your competitors all have it too. Luckily the GPU industry is driven by video games and nowadays AI, industries that don't write code using the web stack. So they'll be alright. Still, that same incentives problem exists in other areas of computing that sit underneath the browser (CPUs, hardware extensions, operating systems, filesystems, etc). Abstractions don't have to erase all the differences in what they abstract, but people who create them often do so anyway.
- tormeh 4y ago
  Good and valid point. Effort will naturally focus on the lowest common denominator. Any new features would have to be implemented in software in the WebGPU layer for targets without API support. That's probably going to slow development of new extensions. However, I think what GPU programming needs at the moment is better ergonomics, and code portability is a step in the right direction, at least. Currently it's quite a bit more annoying than CPU programming.
  - mike_hearn 4y ago
    Yeah, but that's because performance always takes priority. The Vulkan/DX12/Metal APIs are lower level and much more tedious than OpenGL and shader based OpenGL was itself a step backwards in usability from the fixed function pipeline (when doing equivalent tasks). So the trend has been towards more generality and performance at the cost of usability for a long time in graphics APIs. Prefixing it with "Web" won't change that. I'm not saying that's a bad trend - the vendors take the perspective that people who need usability are using game engines anyway so "easy but low level" like classic GL is a need whose time has passed. There's probably a lot of truth to that view.
    - tormeh 4y ago
singularity2001 4y ago
the best way to code cross-platform graphics outside the browser. so WebGPU is a bit like WebAssembly which might really shine outside the Web (on the Edge, as universal bytecode format, for plugins …)
- kllrnohj 4y ago
  Except unlike WebAssembly this one is actually useful. WASM enters a domain full of existing universal bytecodes that all failed to become truly universal because the actual assembly is never the hard part to get portable, it's the API surface. Which WASM doesn't even pretend to attempt to handle, unlike a Java or C# which ship pretty fat bundled libraries to abstract most OS differences. Meanwhile on the GPU front you don't have much in the way of large, good middlewares to abstract away the underlying API. OpenGL used to be OK at this, but now neither platforms nor Khronos wants to touch it. Vulkan is "portable" but it's like writing assembly by hand, it's ludicrously complicated. WebGPU fills the role of essentially just being GLES 4.0. It won't be fast, it won't be powerful, but it doesn't actually need to for the long tail of things that just want to leverage a GPU for some small workloads.
mschuetz 4y ago
Unfortunately WebGPU is also an essentially a 5 year old mobile phone graphics API, which means for most desktop features younger than 10 years, you'll still need DirectX, Vulkan, or Metal.
hinell 4y ago
Still, this comes at cost of new complexity. They just createa and abstraction over different operating system APIs. This isn't something cool really. Now they trying to obsolete Webgl. What a joke..

by tormeh 4y ago

gostsamo 4y ago

or it will be yet another standard

pl90087 4y ago
[flagged]
tormeh 4y ago
Not really. I don't see how any of the vendors could break it without being extremely overt about it. And it has no direct competition. Nothing else runs on any OS and any GPU, except WebGL, which is abandoned.
- illiarian 4y ago
  > I don't see how any of the vendors could break it without being extremely overt about it. > except WebGL, which is abandoned. So it can be abandoned
  - tormeh 4y ago
    It becoming a stale standard is maybe the biggest threat, yes. It has the issue all standards have since several actors have to play along, except this time it isn't Nvidia, Apple, and AMD, but Wgpu/Mozilla and Google. Their incentives are hopefully better aligned with users than those of the hardware vendors. I suspect WebGL was different, since it was based on the old OpenGL/DX9 way of doing things, so a clean break was desireable. But I honestly am not that knowledgeable in neither graphics programming nor WebGL history, so take that with several grains of salt.
    - pjmlp 4y ago
      WebGL was based on OpenGL ES 2.0 and a subset of OpenGL ES 3.0. Google refused to support WebGL compute based on OpenGL ES 3.0 compute shaders, citing WebGPU alternative, and there are still quite a few capabilites from OpenGL ES 3.2 missing from WebGL. Some of which still not available in WebGPU 1.0.
  - whitehexagon 4y ago
    Pretty impressed with WebGL2, and it is already on most platforms, so I hope it wont be pushed aside by this. I assumed WebGPU was going to be more about a Web based OpenCL implementation, is OpenCL also being pushed aside by this then? and wasnt there a plan to do some compute with WebGL? I cant keep up! I hope this myriad of new Chrome APIs being pushed slows down enough for some new browser vendors to enter the market. Or is this just a push for a new 'native' browser experience single horse race...
- kllrnohj 4y ago
  Vulkan & GLES are both the obvious competition here, I don't know why you seem to be ignoring them?
  - tormeh 4y ago
    Vulkan doesn't run on Apple platforms. And Apple refuses to upgrade their OpenGL drivers. So no, they don't count. Then there are the consoles, which also have their own APIs. Expecting all vendors to implement a common API is a fool's errand, and we should stop trying. The vendors don't want this, and we can't force them. Any common GPU API must be an abstraction over vendor-specific ones.
    - kllrnohj 4y ago
      MoltenVK exists and runs Vulkan on Apple devices perfectly fine. Almost certainly better than WebGPU does even. Vulkan is already a common API both in theory and in practice. It's not a nice API, but it is common and vendor neutral all the same. A lot moreso than WebGPU is, even, since Khronos has a much more diverse set of inputs than the web does. See eg all the complaints about Chrome dominating the web discussion, and even beyond that you only really need 3 companies on board. Khronos has significantly more at the table than that.

illiarian 4y ago

> This is HUGE news. Webgpu solves the incentives problem where all actors tries to lock you in to their graphics/compute ecosystem by abstracting over them. Instead we have a third graphics standard (after canvas and WebGL) fully incompatible with the previous two that does exactly that: abstracts the OS graphics stack in a new layer

adrian17 4y ago
Further, in some ways it's the "lowest common denominator" (so that it can be easily implemented on top of each "underlying" graphics API), with union of all their downsides and only intersection of upsides.
flohofwoe 4y ago
WebGPU brings some important improvements that are simply impossible to implement with the WebGL programming model (such as moving all the expensive dynamic state validation from the draw loop into the initialization phase). It's not perfect mind you (e.g. baked BindGroups may be a bit too 'rigid'), but it's still a massive improvement over WebGL in terms of reduced CPU overhead.
dilawar 4y ago
obligatory xkcd: https://xkcd.com/927/ https://xkcd.com/927/

pjmlp 4y ago

There are lots of ways to write code cross-platform graphics outside the browser, it has been available for decades, it is called middleware. WebGPU outside of the browser not only suffers the pain of being yet another incompatible shading language, it is also offers the additional possibility of having code incompatible with browsers WebGPU support, due to the use of extensions not available on the browsers.

flohofwoe 4y ago
AFAIK the WebGPU implementations outside the browser can all load SPIRV directly, no need to translate to WGSL first.
- pjmlp 4y ago
  Yes, and that is one of the reasons why I wrote it is also offers the additional possibility of having code incompatible with browsers WebGPU support.
  - flohofwoe 4y ago
    These differences are smaller than the differences between desktop GL and WebGL though. It's just another option in the low-level vs high-level 3D API zoo. As far as wrapper APIs go, the native WebGPU implementation libraries are a pretty good option, because being also used in browsers there's a ton of testing and driver bug workarounds going into them which other 3D API wrapper projects simply can't afford to do.
    - pjmlp 4y ago
      Not at all. First of all, if one depends on SPIR being present, then a SPIR to WGSL compiler needs to be present when deploying to the Web part of WebGPU. Secondly, it will be yet another extension spaghetti that plagues any API that Khronos has some relation to.
      - flohofwoe 4y ago

mike_hearn 4y ago

"Webgpu solves the incentives problem where all actors tries to lock you in" Or flipped around, it creates an incentive problem where none of the vendors see much benefit in doing R&D anymore, because browsers aren't content to merely abstract irrelevant differences, they also refuse to support vendor extensions except for their own. No point in adding a cool new feature to the GPU if Chrome/Safari insists on blocking it until your competitors all have it too. Luckily the GPU industry is driven by video games and nowadays AI, industries that don't write code using the web stack. So they'll be alright. Still, that same incentives problem exists in other areas of computing that sit underneath the browser (CPUs, hardware extensions, operating systems, filesystems, etc). Abstractions don't have to erase all the differences in what they abstract, but people who create them often do so anyway.

tormeh 4y ago
Good and valid point. Effort will naturally focus on the lowest common denominator. Any new features would have to be implemented in software in the WebGPU layer for targets without API support. That's probably going to slow development of new extensions. However, I think what GPU programming needs at the moment is better ergonomics, and code portability is a step in the right direction, at least. Currently it's quite a bit more annoying than CPU programming.
- mike_hearn 4y ago
  Yeah, but that's because performance always takes priority. The Vulkan/DX12/Metal APIs are lower level and much more tedious than OpenGL and shader based OpenGL was itself a step backwards in usability from the fixed function pipeline (when doing equivalent tasks). So the trend has been towards more generality and performance at the cost of usability for a long time in graphics APIs. Prefixing it with "Web" won't change that. I'm not saying that's a bad trend - the vendors take the perspective that people who need usability are using game engines anyway so "easy but low level" like classic GL is a need whose time has passed. There's probably a lot of truth to that view.
  - tormeh 4y ago

singularity2001 4y ago

the best way to code cross-platform graphics outside the browser. so WebGPU is a bit like WebAssembly which might really shine outside the Web (on the Edge, as universal bytecode format, for plugins …)

kllrnohj 4y ago
Except unlike WebAssembly this one is actually useful. WASM enters a domain full of existing universal bytecodes that all failed to become truly universal because the actual assembly is never the hard part to get portable, it's the API surface. Which WASM doesn't even pretend to attempt to handle, unlike a Java or C# which ship pretty fat bundled libraries to abstract most OS differences. Meanwhile on the GPU front you don't have much in the way of large, good middlewares to abstract away the underlying API. OpenGL used to be OK at this, but now neither platforms nor Khronos wants to touch it. Vulkan is "portable" but it's like writing assembly by hand, it's ludicrously complicated. WebGPU fills the role of essentially just being GLES 4.0. It won't be fast, it won't be powerful, but it doesn't actually need to for the long tail of things that just want to leverage a GPU for some small workloads.

mschuetz 4y ago

Unfortunately WebGPU is also an essentially a 5 year old mobile phone graphics API, which means for most desktop features younger than 10 years, you'll still need DirectX, Vulkan, or Metal.

hinell 4y ago

Still, this comes at cost of new complexity. They just createa and abstraction over different operating system APIs. This isn't something cool really. Now they trying to obsolete Webgl. What a joke..