6 ms·

WebGPU Prototype and Demos

67 points by gok 10y ago

grenoire 10y ago
Seems quite Vulkan-y. I'm interested to see how far the support with this one gets. Also, I'm not really pleased with the Apple-platform and Metal choices.
- favorited 10y ago
  For the record, they said in their announcement[0] that they "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 this is a prototype, they're just going with the shader language they prefer for now. [0]https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/ https://webkit.org/blog/7380/next-generation-3d-graphics-on-...
  - nice_byte 10y ago
    I hope they won't do something daft like turning javascript into a shading language or something
    - om2 10y ago
      We'll probably look at existing cross-platform binary shader formats like SPIR-V, or alternately consider something based on Web Assembly.
      - nice_byte 10y ago
        The first option sounds great, it lets you potentially re-use the same shader binary. Out of curiosity, what benefit does the webassembly approach have? Wouldn't have to be translated by the runtime into something the driver supports (i.e. spir-v) anyway? I realize you probably want to abstract away the differences between Metal's shader IR and SPIR-V, but i think you could realistically translate from SPIR-V to metal IR, while letting other platforms use SPIR-V directly.
        om2 10y ago
        WebAssembly has solved the problem of validating for memory-safety and other requirements of web safety and security. SPIR-V has not. SPIR-V is known usable as a shader format and can be used directly with some APIs (which then translate into the native format for the GPU at some level), but WebAssembly has no such proof of concept. So on these two paths, the big challenges would be: - For WebAssembly: translate into an underlying format understood by the driver (could be SPIR-V or directly to something closer to the metal); and possibly add some primitives, e.g. for SIMD - For SPIR-V: invent a set of restrictions plus an efficient runtime validation mechanism to guarantee memory safety, plus translators on systems that don't natively support SPIR-V. (Even Web-safe SPIR-V to Vulkan-native SPIR-V might need translation, e.g. to remove bounds checks that have to be there to pass validation but that can be proven to be safely removable for efficiency.) Either way you need to produce a toolchain to produce the special format as well, a vanilla SPIR-V toolchain won't necessarily guarantee you can output web-safe SPIR-V. So in fact you won't be able to just use the same shader binary. An additional consideration: given the approach of modern GPU APIs, you're very likely to want to deal with the same data structures in the same memory layout from both your CPU code and your GPU code. It could be convenient to arrange this by targeting WebAssembly for both your CPU code and your GPU code. That said, we're very very early in exploring this question.
        nice_byte 10y ago
        Thanks for the explanation!
- Teknoman117 10y ago
  The API appears to be a near clone of the Metal API.
  - johncolanduoni 10y ago
    Metal on iOS is pretty Vulkan-y, somewhat less so on desktop. I don't love that Apple won't implement Vulkan on their platforms, but I think if you take the Vulkan API and make it object oriented (which is IMHO a good approach for JavaScript) you're going to get something that is reminiscent of Metal anyway.
    - kvark 10y ago
      Vulkan IS object-oriented, it's just specified as C API.
      - johncolanduoni 10y ago
        By "make object oriented" I mean converting functions that return VkResult to functions that throw exceptions, returning instead of using out pointers, converting vkCreate* to constructors, automating destruction, etc. You're absolutely right that there's no heavy lifting or abstraction involved, like there is when you want to make an object oriented OpenGL wrapper.
microcolonel 10y ago
A bit annoying that you can't look at the source of the demos without booting up OS X to get the page to display at all. Edit: Here are some of the source files, they call into `shared.js` https://webkit.org/demos/webgpu/hello.js https://webkit.org/demos/webgpu/hello.js https://webkit.org/demos/webgpu/2d.js https://webkit.org/demos/webgpu/2d.js https://webkit.org/demos/webgpu/simple.js https://webkit.org/demos/webgpu/simple.js https://webkit.org/demos/webgpu/cubes.js https://webkit.org/demos/webgpu/cubes.js
mtgx 10y ago
Other browser vendors should adopt WebGPU only when Apple adopts Vulkan. Apple's stubbornness is the only reason why Khronos is even considering this "portable" low-level API with fewer features in the first place (even though Vulkan was supposed to be that portable API - again, thanks Apple!): https://www.khronos.org/3dportability https://www.khronos.org/3dportability In the meantime, Mozilla has proposed its own low-level web graphics API that the other browser vendors can back: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...
- microcolonel 10y ago
  Yeah, Apple is trying to sidestep Khronos and go through W3C. I think the Khronos solution should succeed over the W3C one in this case. W3C doesn't seem to have a grasp of the power plays and politicking involved in the 3D graphics driver ecosystem.
  - digi_owl 10y ago
    W3C do not have a grasp on politicking, period. Just watch them rubberstamp a web spec for DRM...
  - om2 10y ago
    We have all major browser vendors on board with discussing these things in the W3C's GPU for the Web Community Group, and we expect to end up with a final result based on multiple prototypes as inputs. Submissions so far include: Apple's WebGPU proposal: https://github.com/gpuweb/proposals/tree/master/WebGPU-Apple https://github.com/gpuweb/proposals/tree/master/WebGPU-Apple Google's NXT proposal: https://github.com/gpuweb/nxt-chromium https://github.com/gpuweb/nxt-chromium We expect Mozilla to be submitting their proposal to gpuweb soon too. Khronos only has two of four browser vendors on board. It remains to be seen what will happen, but I doubt it will lead to a cross-browser standard. Browsers are more relevant for web standards than 3d graphics drivers.
- AlphaSite 10y ago
  Microsoft will never support Vulcan on the web either. For the same technical reason. Vulcan cannot be implemented on top of DirectX12 or Metal. So it's never going to happen.
bhouston 10y ago
This is a game changer if we can get this into the browser. Three.JS spends a lot of time in just housekeeping operations, and it is complex in part because of that.
_pdp_ 10y ago
All I want is better shaders so that I can implement hashcat in the browser.
binarymax 10y ago
I would have really liked to see a "Hello World" GPU compute command with this, as specified in the API https://webkit.org/wp-content/uploads/webgpu-api-proposal.html#api https://webkit.org/wp-content/uploads/webgpu-api-proposal.ht...
daenz 10y ago
Very cool stuff. I was going for some kind of javascript GPGPU utility with https://github.com/amoffat/gpgpu.js https://github.com/amoffat/gpgpu.js
- nraynaud 10y ago
  I did my computations by slicing the problem in little chunks so that the GPU has time to render the other tabs. https://github.com/nraynaud/webgcode/blob/gh-pages/webapp/cnc/cam/3D/3Dcomputer.js#L50 https://github.com/nraynaud/webgcode/blob/gh-pages/webapp/cn...
- om2 10y ago
  A WebKit contributor just added Compute support: https://trac.webkit.org/changeset/215131/webkit https://trac.webkit.org/changeset/215131/webkit We're planning to post new Compute demos as soon as this makes it into Safari Technology Preview.
Teknoman117 10y ago
You know, the worst part about this is the claim made on the WebGPU blog post - "Microsoft has Direct3D 12, Apple has Metal, and Khronos has Vulkan. None of these run across all platforms." The only holdout for Vulkan adoption is Apple and you know who controls WebKit for the most part? Apple. Well that and Windows Phone. Anyways, the API in the samples looks strikingly similar to Metal.
shurcooL 10y ago
> As of Safari Technology Preview Release 26, and WebKit Nightly Build, a WebGPU prototype is available for you to experiment with on macOS. Using latest WebKit Nightly, after enabling WebGPU in Experimental Features, I'm getting: TypeError: null is not an object (evaluating 'gpu.createCommandQueue') I'm guessing it's because I'm on a 2011 MBP that Metal doesn't support, so WebGPU won't work either. Or is it something else? In any case, the error handling should be improved to detect and handle the case when canvas.getContext("webgpu") returns null.
Seanny123 10y ago
What's the difference between WebGPU and WebCL?
- om2 10y ago
  WebGPU is designed to support use of the GPU for graphics as well as computation in a way that aligns with modern GPU APIs such as Metal, Vulkan and DirectX 12. It will provide more efficient graphics as well as GPU compute.
erikpukinskis 10y ago
Has anyone worked up a WebVulkan proposal or a Vulkan extension to WebGPU?
- azakai 10y ago
  Yes, Obsidian, Mozilla's proposal, is based on Vulkan, https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...

67 points by gok 10y ago

Seems quite Vulkan-y. I'm interested to see how far the support with this one gets. Also, I'm not really pleased with the Apple-platform and Metal choices.

favorited 10y ago
For the record, they said in their announcement[0] that they "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 this is a prototype, they're just going with the shader language they prefer for now. [0]https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/ https://webkit.org/blog/7380/next-generation-3d-graphics-on-...
- nice_byte 10y ago
  I hope they won't do something daft like turning javascript into a shading language or something
  - om2 10y ago
    We'll probably look at existing cross-platform binary shader formats like SPIR-V, or alternately consider something based on Web Assembly.
    - nice_byte 10y ago
      The first option sounds great, it lets you potentially re-use the same shader binary. Out of curiosity, what benefit does the webassembly approach have? Wouldn't have to be translated by the runtime into something the driver supports (i.e. spir-v) anyway? I realize you probably want to abstract away the differences between Metal's shader IR and SPIR-V, but i think you could realistically translate from SPIR-V to metal IR, while letting other platforms use SPIR-V directly.
      - om2 10y ago
        WebAssembly has solved the problem of validating for memory-safety and other requirements of web safety and security. SPIR-V has not. SPIR-V is known usable as a shader format and can be used directly with some APIs (which then translate into the native format for the GPU at some level), but WebAssembly has no such proof of concept. So on these two paths, the big challenges would be: - For WebAssembly: translate into an underlying format understood by the driver (could be SPIR-V or directly to something closer to the metal); and possibly add some primitives, e.g. for SIMD - For SPIR-V: invent a set of restrictions plus an efficient runtime validation mechanism to guarantee memory safety, plus translators on systems that don't natively support SPIR-V. (Even Web-safe SPIR-V to Vulkan-native SPIR-V might need translation, e.g. to remove bounds checks that have to be there to pass validation but that can be proven to be safely removable for efficiency.) Either way you need to produce a toolchain to produce the special format as well, a vanilla SPIR-V toolchain won't necessarily guarantee you can output web-safe SPIR-V. So in fact you won't be able to just use the same shader binary. An additional consideration: given the approach of modern GPU APIs, you're very likely to want to deal with the same data structures in the same memory layout from both your CPU code and your GPU code. It could be convenient to arrange this by targeting WebAssembly for both your CPU code and your GPU code. That said, we're very very early in exploring this question.
        nice_byte 10y ago
        Thanks for the explanation!
Teknoman117 10y ago
The API appears to be a near clone of the Metal API.
- johncolanduoni 10y ago
  Metal on iOS is pretty Vulkan-y, somewhat less so on desktop. I don't love that Apple won't implement Vulkan on their platforms, but I think if you take the Vulkan API and make it object oriented (which is IMHO a good approach for JavaScript) you're going to get something that is reminiscent of Metal anyway.
  - kvark 10y ago
    Vulkan IS object-oriented, it's just specified as C API.
    - johncolanduoni 10y ago
      By "make object oriented" I mean converting functions that return VkResult to functions that throw exceptions, returning instead of using out pointers, converting vkCreate* to constructors, automating destruction, etc. You're absolutely right that there's no heavy lifting or abstraction involved, like there is when you want to make an object oriented OpenGL wrapper.

microcolonel 10y ago

A bit annoying that you can't look at the source of the demos without booting up OS X to get the page to display at all. Edit: Here are some of the source files, they call into `shared.js` https://webkit.org/demos/webgpu/hello.js https://webkit.org/demos/webgpu/hello.js https://webkit.org/demos/webgpu/2d.js https://webkit.org/demos/webgpu/2d.js https://webkit.org/demos/webgpu/simple.js https://webkit.org/demos/webgpu/simple.js https://webkit.org/demos/webgpu/cubes.js https://webkit.org/demos/webgpu/cubes.js

mtgx 10y ago

Other browser vendors should adopt WebGPU only when Apple adopts Vulkan. Apple's stubbornness is the only reason why Khronos is even considering this "portable" low-level API with fewer features in the first place (even though Vulkan was supposed to be that portable API - again, thanks Apple!): https://www.khronos.org/3dportability https://www.khronos.org/3dportability In the meantime, Mozilla has proposed its own low-level web graphics API that the other browser vendors can back: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...

microcolonel 10y ago
Yeah, Apple is trying to sidestep Khronos and go through W3C. I think the Khronos solution should succeed over the W3C one in this case. W3C doesn't seem to have a grasp of the power plays and politicking involved in the 3D graphics driver ecosystem.
- digi_owl 10y ago
  W3C do not have a grasp on politicking, period. Just watch them rubberstamp a web spec for DRM...
- om2 10y ago
  We have all major browser vendors on board with discussing these things in the W3C's GPU for the Web Community Group, and we expect to end up with a final result based on multiple prototypes as inputs. Submissions so far include: Apple's WebGPU proposal: https://github.com/gpuweb/proposals/tree/master/WebGPU-Apple https://github.com/gpuweb/proposals/tree/master/WebGPU-Apple Google's NXT proposal: https://github.com/gpuweb/nxt-chromium https://github.com/gpuweb/nxt-chromium We expect Mozilla to be submitting their proposal to gpuweb soon too. Khronos only has two of four browser vendors on board. It remains to be seen what will happen, but I doubt it will lead to a cross-browser standard. Browsers are more relevant for web standards than 3d graphics drivers.
AlphaSite 10y ago
Microsoft will never support Vulcan on the web either. For the same technical reason. Vulcan cannot be implemented on top of DirectX12 or Metal. So it's never going to happen.

bhouston 10y ago

This is a game changer if we can get this into the browser. Three.JS spends a lot of time in just housekeeping operations, and it is complex in part because of that.

_pdp_ 10y ago

All I want is better shaders so that I can implement hashcat in the browser.

binarymax 10y ago

I would have really liked to see a "Hello World" GPU compute command with this, as specified in the API https://webkit.org/wp-content/uploads/webgpu-api-proposal.html#api https://webkit.org/wp-content/uploads/webgpu-api-proposal.ht...

daenz 10y ago

Very cool stuff. I was going for some kind of javascript GPGPU utility with https://github.com/amoffat/gpgpu.js https://github.com/amoffat/gpgpu.js

nraynaud 10y ago
I did my computations by slicing the problem in little chunks so that the GPU has time to render the other tabs. https://github.com/nraynaud/webgcode/blob/gh-pages/webapp/cnc/cam/3D/3Dcomputer.js#L50 https://github.com/nraynaud/webgcode/blob/gh-pages/webapp/cn...
om2 10y ago
A WebKit contributor just added Compute support: https://trac.webkit.org/changeset/215131/webkit https://trac.webkit.org/changeset/215131/webkit We're planning to post new Compute demos as soon as this makes it into Safari Technology Preview.

Teknoman117 10y ago

You know, the worst part about this is the claim made on the WebGPU blog post - "Microsoft has Direct3D 12, Apple has Metal, and Khronos has Vulkan. None of these run across all platforms." The only holdout for Vulkan adoption is Apple and you know who controls WebKit for the most part? Apple. Well that and Windows Phone. Anyways, the API in the samples looks strikingly similar to Metal.

shurcooL 10y ago

> As of Safari Technology Preview Release 26, and WebKit Nightly Build, a WebGPU prototype is available for you to experiment with on macOS. Using latest WebKit Nightly, after enabling WebGPU in Experimental Features, I'm getting: TypeError: null is not an object (evaluating 'gpu.createCommandQueue') I'm guessing it's because I'm on a 2011 MBP that Metal doesn't support, so WebGPU won't work either. Or is it something else? In any case, the error handling should be improved to detect and handle the case when canvas.getContext("webgpu") returns null.

Seanny123 10y ago

What's the difference between WebGPU and WebCL?

om2 10y ago
WebGPU is designed to support use of the GPU for graphics as well as computation in a way that aligns with modern GPU APIs such as Metal, Vulkan and DirectX 12. It will provide more efficient graphics as well as GPU compute.

erikpukinskis 10y ago

Has anyone worked up a WebVulkan proposal or a Vulkan extension to WebGPU?

azakai 10y ago
Yes, Obsidian, Mozilla's proposal, is based on Vulkan, https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...