
WebGPU Prototype and Demos - gok
https://webkit.org/blog/7504/webgpu-prototype-and-demos/
======
mtgx
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/mas...](https://github.com/KhronosGroup/WebGLNext-
Proposals/tree/master/Obsidian-Mozilla)

~~~
AlphaSite
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.

~~~
awalton
> Vulcan cannot be implemented on top of DirectX12 or Metal.

Ehh I don't believe this for a second; somewhat more correctly, "Vulcan may
not be able to be efficiently implemented on top of other APIs."

I also believe that Apple has a vested interest in keeping Metal around, so of
course they're going to push hard and fast for their standard...

~~~
AlphaSite
Well yes, anything can be done, but doing it in a way that doesn't throw away
all the potential gains of a low level api is hard.

------
daenz
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)

~~~
om2
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.

------
bhouston
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.

------
shurcooL
> 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.

------
binarymax
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.ht...](https://webkit.org/wp-content/uploads/webgpu-api-
proposal.html#api)

------
microcolonel
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)

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

------
grenoire
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
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-...](https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/)

~~~
nice_byte
I hope they won't do something daft like turning javascript into a shading
language or something

~~~
om2
We'll probably look at existing cross-platform binary shader formats like
SPIR-V, or alternately consider something based on Web Assembly.

~~~
nice_byte
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
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
Thanks for the explanation!

------
Seanny123
What's the difference between WebGPU and WebCL?

~~~
om2
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
Has anyone worked up a WebVulkan proposal or a Vulkan extension to WebGPU?

~~~
azakai
Yes, Obsidian, Mozilla's proposal, is based on Vulkan,

[https://github.com/KhronosGroup/WebGLNext-
Proposals/tree/mas...](https://github.com/KhronosGroup/WebGLNext-
Proposals/tree/master/Obsidian-Mozilla)

------
Teknoman117
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.

