WebGPU Prototype and Demos | Hacker News Reader

WebGPU Prototype and Demos

webkit.org

67 pointsgok34 comments

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

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

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.

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

Google's NXT proposal: 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.

W3C do not have a grasp on politicking, period.

Just watch them rubberstamp a web spec for DRM...

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.

> Microsoft will never support Vulcan

People said the same about WebGL. Today Microsoft is a member of Khronos.

Vulkan can be implemented on anything. It's just a matter of performance. And since Microsoft defines DirectX, they can add any features they need to improve the performance of a Vulkan implementation if they so choose.

In a way, Vulkan is already implemented on top of Metal (https://moltengl.com/moltenvk/). Porting it to DirectX12 should be a little easier.

What are the issues with Vulkan-on-DX12? Metal is missing geometry shaders and the tesselation shaders are kind of weird, plus GPU heap allocation is iOS only so I understand the difficulties there (although as kvark mentioned there is a decent Vulkan-on-Metal implementation for the rest of the API in the works). AFAIK DX12 has all of that.

Also Windows GPU drivers already support Vulkan (all the way back to the 600 series in Nvidia's case IIRC), so I don't see why that would be a technical deal breaker. And it definitely won't be a "political" deal breaker for Firefox or Chromium on Windows.

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

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.

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

A WebKit contributor just added Compute support: 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.

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/cn...

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.

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

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

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/2d.js

https://webkit.org/demos/webgpu/simple.js

https://webkit.org/demos/webgpu/cubes.js

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

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.

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

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

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

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.

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.

Thanks for the explanation!

The API appears to be a near clone of the Metal API.

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.

Vulkan IS object-oriented, it's just specified as C API.

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.

What's the difference between WebGPU and WebCL?

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.

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

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

https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...

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.

Reply on news.ycombinator.com