8 ms·

WebGPU demos

62 points by tilt 9y ago

blauditore 9y ago
Note this is not about WebGL, but about WebGPU by Apple, claiming it "generally offers better performance" than OpenGL/WebGL. I'm not an expert in this area, but isn't it a bad idea to introduce another standard if there's already WebGL with great cross-browser and -platform support? It reminds me of what people have been raging about towards Microsoft for years...
- deleted 9y ago
  [deleted]
- m_eiman 9y ago
  This is like the web variant of Vulcan/Metal/etc, isn't it? Lower level API than GL.
- markdog12 9y ago
  It's being introduced for the same reason it was on desktop, increased performance, more GPU features, avoidance of poor driver implementation, and more optimal usage of the underlying hardware. See https://gpuweb.github.io/admin/cg-charter.html https://gpuweb.github.io/admin/cg-charter.html
- flohofwoe 9y ago
  Apple's WebGPU is just one of 3 proposals (from Mozilla, Google and Apple) of what the WebGL successor will look like. WebGPU is (more or less) a mapping of the Metal 3D API to the web, but the final standard API will have to be a common subset of Vulkan, D3D12 and Metal with a common shading language. The WebGL programming model has a lot of shortcoming from a modern point of view, see here: http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html (you can mostly ignore my criticism of adopting Vulkan for the web, the Mozilla proposal (called Obsidian) is pretty close to Vulkan, and doesn't look as bad as I feared when I wrote that blog post).
  - kuschku 9y ago
    > a common subset of Vulkan, D3D12 and Metal with a common shading language. So, Vulkan? This is literally what Vulkan exists for, and does – a shading language and API implemented by all vendors.
    - jsheard 9y ago
      In a perfect world yes, but Apple doesn't support Vulkan and probably never will. Microsoft doesn't support Vulkan in UWP apps either. Vulkan being a universal 3D API is a myth - it only exists on Windows (as a second class citizen), Linux, Android, and the Nintendo Switch.
      - kuschku 9y ago
        Well, then Apple users will just see what a Firefox user sees today when they visit Google Earth: Your Browser is not supported. This isn’t an issue – there’s more people using Firefox, or even more unusual browsers, which can’t use half the web, than there are people using Apple devices.
        tpush 9y ago
        > [...] there’s more people using Firefox, or even more unusual browsers, which can’t use half the web, than there are people using Apple devices. Highly unlikely.
        kuschku 9y ago
        In Germany, Apple has a sub-16% mobile marketshare, and even less on desktop. Firefox has 43% marketshare. Google frequently releases major products without Firefox support, with this only being added months or years later. This is reality today.
        tpush 9y ago
        Germany != the World. Besides, market share of iOS in Germany is ~32% [1], and Firefox ~17% [2], according to stat counter. And even those numbers are lower/higher(respectively) than those of countries like USA, UK, Australia, Japan etc... [1] http://gs.statcounter.com/os-market-share/mobile/germany http://gs.statcounter.com/os-market-share/mobile/germany [2] http://gs.statcounter.com/browser-market-share/all/germany http://gs.statcounter.com/browser-market-share/all/germany
- deleted 9y ago
  [deleted]
- DiThi 9y ago
  If it maps closely enough to Vulkan, it's good (and it seems it will be the case according to the other comment). It's not the only competing successor of WebGL.
  - kvark 9y ago
    Apple's prototype is basically WebMetal, and the question about how well it maps to Vulkan is still open. Like, surely, there are hoops you've got to solve (w.r.t memory types, pipeline barriers, etc), but it's not clear how much actual real-world performance is going to be lost on this emulation. Same goes to the other direction (mapping from Obsidian/WebVulkan to Metal), with a caveat that Vulkan requires more state to be communicated, so it's easier to ignore some of the user input (if it doesn't make sense on Metal) than to figure out the missing bits.
jsheard 9y ago
Is Apples WebGPU proposal still being actively developed? I haven't seen any signs of life since the initial reveal nearly a year ago, or from Mozilla's Obsidian proposal for that matter. At least from an outsider's perspective, the only active proposal for a WebGL successor seems to be Googles NXT: https://github.com/google/nxt-standalone https://github.com/google/nxt-standalone
- markdog12 9y ago
  Perhaps this is Mozilla's implementation? https://github.com/kvark/webgpu-servo https://github.com/kvark/webgpu-servo
  - GlitchEnzo 9y ago
    No, Mozilla's is Obsidian: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...
    - deleted 9y ago
      [deleted]
    - haxiomic 9y ago
      Obsidian ultimately became WebGPU in servo (the op's link) –https://github.com/KhronosGroup/WebGLNext-Proposals/pull/11#issuecomment-346517188 https://github.com/KhronosGroup/WebGLNext-Proposals/pull/11#...
  - kvark 9y ago
    At this point, since there is no consensus on the shape of the API or even the concrete feature set/programming model, we decided to focus on the low-level graphics abstraction layer ([1]) instead of pushing the WebGPU-Servo prototype further. This can change once things clear up a bit. [1] http://github.com/gfx-rs/gfx http://github.com/gfx-rs/gfx
acoye 9y ago
I peeked at the source code of the shaders, it looks like it is metal for the web. I don't get how a closed API like metal could be the future of an open internet. Yet it can start a discussion.
- Jare 9y ago
  It's meant to be a starting point: "We expect the discussions around the shading language to be one of the most fun parts of the standardization process, and look forward to hearing community opinions. For our WebGPU prototype, we decided to defer the issue and just accept an existing language for now. Since we were building on Apple platforms we picked the Metal Shading Language."
  - striking 9y ago
    As someone who likes developing OpenGL apps in his spare time, that handwaving actually bothered me. Of course Apple's going to pick Metal's shader language, they don't fully support anything else! They're still on OpenGL 4.1 in their drivers, even though those GPUs support GL 4.5, in what seems to be an effort to move graphics devs to supporting Metal. I have no idea why anyone would let them near an open graphics spec discussion after such a stunt.
    - fiala__ 9y ago
      well that's precisely why the discussion is open – Apple can come in with their (arguably selfish) ideas, but they can't impose them on other big players such as MS, Google and Mozilla. In an ideal world this prevents the final common API from only working for one of them.
    - pjmlp 9y ago
      Just like Sony, Nintendo and Microsoft. Apple had their own 3D API in the old days, Quickdraw 3D. They only played nice with OpenGL, because of NeXT acquisition, NeXTSTEP had Renderman and OpenGL, and they needed to bring developers into their eco-system to avoid closing doors. Now the bank is full and with graphics middleware, a 3D API is just another interface implementation for the scene graph rendering calls, that are actually used. Metal is already supported by the majority of engines that matter in the industry, with Qt in the process of adopting configurable backends as well.
okket 9y ago
Previous discussion from 9 months ago: https://news.ycombinator.com/item?id=14100783 https://news.ycombinator.com/item?id=14100783 (34 comments)
markdog12 9y ago
Would love to see some kind of status update on WebGPU from any of the participants. Is this the latest? https://lists.w3.org/Archives/Public/public-gpu/2017Sep/0015.html https://lists.w3.org/Archives/Public/public-gpu/2017Sep/0015...
- deleted 9y ago
  [deleted]
- kvark 9y ago
  I wouldn't say that we've crossed any significant milestone since Chicago F2F. There's been progress on the implementations, but conceptually the main questions about the API are still open.
sgt 9y ago
This is amazing - I've never run any kind of demos like this before in a browser (i.e. WebGL) that didn't immediately spin up all fans with 100%+ CPU usage for the browser. I ran the Shadertoy on a 4k monitor in full screen mode and CPU (as well as energy usage) was minimal, if noticable at all on my MacBook Pro. (Edited: Which means it's using the GPU only... that's the whole point here.)
- jsheard 9y ago
  There shouldn't really be any performance difference between WebGL and WebGPU in a ShaderToy-like example, given that only requires a single draw-call per frame. The API overhead should be utterly negligible in that case. If WebGPU really does perform better in an apples-to-apples comparison (i.e. running the same shader) then there's something seriously wrong with Apples WebGL implementation. edit: here's that example translated verbatim to WebGL if you want to compare: https://www.shadertoy.com/view/Mt2fRy https://www.shadertoy.com/view/Mt2fRy
  - pjmlp 9y ago
    While you are right, for me WebGL is nothing more than just for prototyping purposes, in what concerns mobile devices. Most of the WebGL demos that get posted around here, always have issues running on my mid-range devices, that don't have any issues playing my collection of 3D games. So I still look forward to a 3D Web API that can actually compete with native 3D across all mobile devices, not only on flagship ones. Or proper implementations of WebGL, if that is actually the issue.
    - jsheard 9y ago
      I'll just refer back to the last time you replied to me with that exact comment :P https://news.ycombinator.com/item?id=16086537 https://news.ycombinator.com/item?id=16086537 I suspect that Three.js is the main reason why so many WebGL demos are slow, rather than WebGL itself.
      - pjmlp 9y ago
pier25 9y ago
But why?
mxfh 9y ago
Would rather see something like WebCL back in development for general purpose GPU computation, most importantly deep learning, on the web, then the Xth attempt on superseeding WebGL. Funneling things through WebGL just doesn't feel right, where proper OES_texture_float support is also not guaranteed. https://www.khronos.org/webcl/ https://www.khronos.org/webcl/
- fulafel 9y ago
  Apparently WebCL was blocked by Apple who refused to let their OpenCL patents be used: https://www.khronos.org/files/ip-disclosures/webcl/Apple-WebCL-Disclosure-Jan14_clean.pdf https://www.khronos.org/files/ip-disclosures/webcl/Apple-Web... ("Apple does not agree to make available .. for any WebCL Specifications")
- jsheard 9y ago
  WebGPU will almost certainly include support for general purpose compute shaders, which pretty much removes the need for a dedicated compute API: https://docs.google.com/presentation/d/1l1rTCtKHowIEhwzA4l1uEq2_JtiKolApTOgA0ebRJIM/edit?usp=sharing https://docs.google.com/presentation/d/1l1rTCtKHowIEhwzA4l1u... (besides, building a new API on top of OpenCL would be questionable given that OpenCL is all but dead at this point)
- fulafel 9y ago
  Float textures were just optional back in WebGL 1[1]. Any new spec is going to lose in support coverage to WebGL 2 which has been shipping for a year now! [1] Look for RGBA32F in the WebGL 2 and corresponding OpenGL ES 3.0 specs. Also documented on MDN's coverage of OES_texture_float.
- pcwalton 9y ago
  OpenCL is irritating for graphics development, because it doesn't integrate as seamlessly with the rest of the graphics pipeline as GL compute shader does. Unified approaches such as GL compute shader or Vulkan are much more convenient.

62 points by tilt 9y ago

Note this is not about WebGL, but about WebGPU by Apple, claiming it "generally offers better performance" than OpenGL/WebGL. I'm not an expert in this area, but isn't it a bad idea to introduce another standard if there's already WebGL with great cross-browser and -platform support? It reminds me of what people have been raging about towards Microsoft for years...

deleted 9y ago
[deleted]
m_eiman 9y ago
This is like the web variant of Vulcan/Metal/etc, isn't it? Lower level API than GL.
markdog12 9y ago
It's being introduced for the same reason it was on desktop, increased performance, more GPU features, avoidance of poor driver implementation, and more optimal usage of the underlying hardware. See https://gpuweb.github.io/admin/cg-charter.html https://gpuweb.github.io/admin/cg-charter.html
flohofwoe 9y ago
Apple's WebGPU is just one of 3 proposals (from Mozilla, Google and Apple) of what the WebGL successor will look like. WebGPU is (more or less) a mapping of the Metal 3D API to the web, but the final standard API will have to be a common subset of Vulkan, D3D12 and Metal with a common shading language. The WebGL programming model has a lot of shortcoming from a modern point of view, see here: http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html (you can mostly ignore my criticism of adopting Vulkan for the web, the Mozilla proposal (called Obsidian) is pretty close to Vulkan, and doesn't look as bad as I feared when I wrote that blog post).
- kuschku 9y ago
  > a common subset of Vulkan, D3D12 and Metal with a common shading language. So, Vulkan? This is literally what Vulkan exists for, and does – a shading language and API implemented by all vendors.
  - jsheard 9y ago
    In a perfect world yes, but Apple doesn't support Vulkan and probably never will. Microsoft doesn't support Vulkan in UWP apps either. Vulkan being a universal 3D API is a myth - it only exists on Windows (as a second class citizen), Linux, Android, and the Nintendo Switch.
    - kuschku 9y ago
      Well, then Apple users will just see what a Firefox user sees today when they visit Google Earth: Your Browser is not supported. This isn’t an issue – there’s more people using Firefox, or even more unusual browsers, which can’t use half the web, than there are people using Apple devices.
      - tpush 9y ago
        > [...] there’s more people using Firefox, or even more unusual browsers, which can’t use half the web, than there are people using Apple devices. Highly unlikely.
        kuschku 9y ago
        In Germany, Apple has a sub-16% mobile marketshare, and even less on desktop. Firefox has 43% marketshare. Google frequently releases major products without Firefox support, with this only being added months or years later. This is reality today.
        tpush 9y ago
        Germany != the World. Besides, market share of iOS in Germany is ~32% [1], and Firefox ~17% [2], according to stat counter. And even those numbers are lower/higher(respectively) than those of countries like USA, UK, Australia, Japan etc... [1] http://gs.statcounter.com/os-market-share/mobile/germany http://gs.statcounter.com/os-market-share/mobile/germany [2] http://gs.statcounter.com/browser-market-share/all/germany http://gs.statcounter.com/browser-market-share/all/germany
deleted 9y ago
[deleted]
DiThi 9y ago
If it maps closely enough to Vulkan, it's good (and it seems it will be the case according to the other comment). It's not the only competing successor of WebGL.
- kvark 9y ago
  Apple's prototype is basically WebMetal, and the question about how well it maps to Vulkan is still open. Like, surely, there are hoops you've got to solve (w.r.t memory types, pipeline barriers, etc), but it's not clear how much actual real-world performance is going to be lost on this emulation. Same goes to the other direction (mapping from Obsidian/WebVulkan to Metal), with a caveat that Vulkan requires more state to be communicated, so it's easier to ignore some of the user input (if it doesn't make sense on Metal) than to figure out the missing bits.

jsheard 9y ago

Is Apples WebGPU proposal still being actively developed? I haven't seen any signs of life since the initial reveal nearly a year ago, or from Mozilla's Obsidian proposal for that matter. At least from an outsider's perspective, the only active proposal for a WebGL successor seems to be Googles NXT: https://github.com/google/nxt-standalone https://github.com/google/nxt-standalone

markdog12 9y ago
Perhaps this is Mozilla's implementation? https://github.com/kvark/webgpu-servo https://github.com/kvark/webgpu-servo
- GlitchEnzo 9y ago
  No, Mozilla's is Obsidian: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...
  - deleted 9y ago
    [deleted]
  - haxiomic 9y ago
    Obsidian ultimately became WebGPU in servo (the op's link) –https://github.com/KhronosGroup/WebGLNext-Proposals/pull/11#issuecomment-346517188 https://github.com/KhronosGroup/WebGLNext-Proposals/pull/11#...
- kvark 9y ago
  At this point, since there is no consensus on the shape of the API or even the concrete feature set/programming model, we decided to focus on the low-level graphics abstraction layer ([1]) instead of pushing the WebGPU-Servo prototype further. This can change once things clear up a bit. [1] http://github.com/gfx-rs/gfx http://github.com/gfx-rs/gfx

acoye 9y ago

I peeked at the source code of the shaders, it looks like it is metal for the web. I don't get how a closed API like metal could be the future of an open internet. Yet it can start a discussion.

Jare 9y ago
It's meant to be a starting point: "We expect the discussions around the shading language to be one of the most fun parts of the standardization process, and look forward to hearing community opinions. For our WebGPU prototype, we decided to defer the issue and just accept an existing language for now. Since we were building on Apple platforms we picked the Metal Shading Language."
- striking 9y ago
  As someone who likes developing OpenGL apps in his spare time, that handwaving actually bothered me. Of course Apple's going to pick Metal's shader language, they don't fully support anything else! They're still on OpenGL 4.1 in their drivers, even though those GPUs support GL 4.5, in what seems to be an effort to move graphics devs to supporting Metal. I have no idea why anyone would let them near an open graphics spec discussion after such a stunt.
  - fiala__ 9y ago
    well that's precisely why the discussion is open – Apple can come in with their (arguably selfish) ideas, but they can't impose them on other big players such as MS, Google and Mozilla. In an ideal world this prevents the final common API from only working for one of them.
  - pjmlp 9y ago
    Just like Sony, Nintendo and Microsoft. Apple had their own 3D API in the old days, Quickdraw 3D. They only played nice with OpenGL, because of NeXT acquisition, NeXTSTEP had Renderman and OpenGL, and they needed to bring developers into their eco-system to avoid closing doors. Now the bank is full and with graphics middleware, a 3D API is just another interface implementation for the scene graph rendering calls, that are actually used. Metal is already supported by the majority of engines that matter in the industry, with Qt in the process of adopting configurable backends as well.

okket 9y ago

Previous discussion from 9 months ago: https://news.ycombinator.com/item?id=14100783 https://news.ycombinator.com/item?id=14100783 (34 comments)

markdog12 9y ago

Would love to see some kind of status update on WebGPU from any of the participants. Is this the latest? https://lists.w3.org/Archives/Public/public-gpu/2017Sep/0015.html https://lists.w3.org/Archives/Public/public-gpu/2017Sep/0015...

deleted 9y ago
[deleted]
kvark 9y ago
I wouldn't say that we've crossed any significant milestone since Chicago F2F. There's been progress on the implementations, but conceptually the main questions about the API are still open.

sgt 9y ago

This is amazing - I've never run any kind of demos like this before in a browser (i.e. WebGL) that didn't immediately spin up all fans with 100%+ CPU usage for the browser. I ran the Shadertoy on a 4k monitor in full screen mode and CPU (as well as energy usage) was minimal, if noticable at all on my MacBook Pro. (Edited: Which means it's using the GPU only... that's the whole point here.)

jsheard 9y ago
There shouldn't really be any performance difference between WebGL and WebGPU in a ShaderToy-like example, given that only requires a single draw-call per frame. The API overhead should be utterly negligible in that case. If WebGPU really does perform better in an apples-to-apples comparison (i.e. running the same shader) then there's something seriously wrong with Apples WebGL implementation. edit: here's that example translated verbatim to WebGL if you want to compare: https://www.shadertoy.com/view/Mt2fRy https://www.shadertoy.com/view/Mt2fRy
- pjmlp 9y ago
  While you are right, for me WebGL is nothing more than just for prototyping purposes, in what concerns mobile devices. Most of the WebGL demos that get posted around here, always have issues running on my mid-range devices, that don't have any issues playing my collection of 3D games. So I still look forward to a 3D Web API that can actually compete with native 3D across all mobile devices, not only on flagship ones. Or proper implementations of WebGL, if that is actually the issue.
  - jsheard 9y ago
    I'll just refer back to the last time you replied to me with that exact comment :P https://news.ycombinator.com/item?id=16086537 https://news.ycombinator.com/item?id=16086537 I suspect that Three.js is the main reason why so many WebGL demos are slow, rather than WebGL itself.
    - pjmlp 9y ago

pier25 9y ago

But why?

mxfh 9y ago

Would rather see something like WebCL back in development for general purpose GPU computation, most importantly deep learning, on the web, then the Xth attempt on superseeding WebGL. Funneling things through WebGL just doesn't feel right, where proper OES_texture_float support is also not guaranteed. https://www.khronos.org/webcl/ https://www.khronos.org/webcl/

fulafel 9y ago
Apparently WebCL was blocked by Apple who refused to let their OpenCL patents be used: https://www.khronos.org/files/ip-disclosures/webcl/Apple-WebCL-Disclosure-Jan14_clean.pdf https://www.khronos.org/files/ip-disclosures/webcl/Apple-Web... ("Apple does not agree to make available .. for any WebCL Specifications")
jsheard 9y ago
WebGPU will almost certainly include support for general purpose compute shaders, which pretty much removes the need for a dedicated compute API: https://docs.google.com/presentation/d/1l1rTCtKHowIEhwzA4l1uEq2_JtiKolApTOgA0ebRJIM/edit?usp=sharing https://docs.google.com/presentation/d/1l1rTCtKHowIEhwzA4l1u... (besides, building a new API on top of OpenCL would be questionable given that OpenCL is all but dead at this point)
fulafel 9y ago
Float textures were just optional back in WebGL 1[1]. Any new spec is going to lose in support coverage to WebGL 2 which has been shipping for a year now! [1] Look for RGBA32F in the WebGL 2 and corresponding OpenGL ES 3.0 specs. Also documented on MDN's coverage of OES_texture_float.
pcwalton 9y ago
OpenCL is irritating for graphics development, because it doesn't integrate as seamlessly with the rest of the graphics pipeline as GL compute shader does. Unified approaches such as GL compute shader or Vulkan are much more convenient.