
Raw WebGPU - ingve
https://alain.xyz/blog/raw-webgpu
======
mschuetz
I'm extremely excited for WebGPU. Support for Compute Shaders and efficient
batching of various tasks such as setting shader uniforms are going to be game
changers with respect to power and performance of 3D graphics and GPGPU in web
browsers. Right now, Chrome Canary on windows crashes for me when I try
WebGPU, unfortunately.

~~~
kvark
Without push constants or persistently mapped uniform buffers, it's a long
stretch to call our way of setting uniforms "efficient"...

~~~
Jasper_
I've lost track of the many buffer management proposals up in the air. What's
the current motion? Would love to see devh's range tracking proposal brought
back from the dead, but that's probably unlikely for MVP at this stage.

~~~
kvark
Current motion is maybe we'll get a Queue::setBufferSubData and
setTextureSubData, or not. And even if we get them, it's problematic to allow
the copy to be direct if this part of the buffer isn't used (while some other
part is used) by the GPU.

------
macawfish
I'm excited about having the option to generate portable SPIR-V shaders from a
wide range of languages (GLSL, HLSL, Julia, Rust, OCaml and others).

I understand that SPIR-V is an excellent, flexible intermediate
representation... I really hope it ends up as the shader language of WebGPU.

(Apple is trying to sabotage SPIR-V and it'll be really disappointing if they
succeed.)

~~~
CharlesW
If by "Apple is trying to sabotoge" you mean "Apple has no plans to support",
[https://webkit.org/blog/8482/web-high-level-shading-
language...](https://webkit.org/blog/8482/web-high-level-shading-language/)
goes into some detail about why SPIR-V bytecode isn't a good fit for them
specifically, and reasonable (IMHO) arguments for why SPIR-V isn't a good fit
for the web in general.

As SPIR-V is an intermediate language, I am curious how you imagine this would
affect you. Mind elaborating?

~~~
Jasper_
Let me offer a rebuttal to that page.

> First, SPIR-V was not written with security as a first principle, and it’s
> unclear whether it can be modified to satisfy the security requirements of
> the web.

At the time of this post's authoring, Google already had a set of SPIR-V
restrictions to make it suitable for the web [0]. The only response from Apple
I heard was "it doesn't have tests", but, again, it had more than WSL at the
time [1].

[0] [https://github.com/gpuweb/spirv-execution-
env/blob/master/ex...](https://github.com/gpuweb/spirv-execution-
env/blob/master/execution-env.md) [1] [https://github.com/KhronosGroup/SPIRV-
Tools/blob/master/test...](https://github.com/KhronosGroup/SPIRV-
Tools/blob/master/test/val/val_webgpu_test.cpp)

> Forking the SPIR-V language means developers would have to recompile their
> shaders, possibly being forced to rewrite their source code anyway.

They might have to rewrite some small portions of their shader code to target
WebGPU, or run some preprocessing tools to validate it. I don't think this was
ever a problem. This is basically saying "if they have to change it anyway,
why not rewrite it in an entirely new language", but most realistic shader
code would be unaffected.

> Additionally, browsers would still be unable to trust incoming bytecode, and
> would be required to validate programs to make sure they are not doing
> anything insecure.

Browsers need to validate WSL/WHLSL too for things like out-of-bounds array
accesses.

> And since Windows and macOS/iOS don’t support Vulkan, the incoming SPIR-V
> would still need to be translated/compiled into another language.

This is also true for WSL/WHLSL. But SPIR-V has a leg up here, as existing
community cross-compile tools like SPIRV-Cross exist [2].

[2] [https://github.com/KhronosGroup/SPIRV-
Cross/](https://github.com/KhronosGroup/SPIRV-Cross/)

The argument that we have against WSL/WHLSL is that we do not trust the
developers of these specifications to correctly understand the GPU programming
environment, and involving IHVs in WSL/WHLSL's design is a waste of time, when
they have already produced SPIR-V over many years.

~~~
throwaway34241
Regardless of the advantages of SPIR-V as an intermediate format, it's kind of
unfortunate for step one of using WebGPU to be "choose a shader compiler and
integrate it into your build system" (or alternately delivering a shader
compiler on every page load).

That seems like a big usability regression over WebGL. It would sure be nice
if there was some human readable format that was guaranteed to be available,
even if all it did was compile to SPIR-V and submit it to a lower level API.
Maybe that's too hard to specify adequately.

~~~
macawfish
I'd personally be completely satisfied if they decided to compromise on
letting you use either WSL/whatever-shader-language _and_ SPIR-V. I just want
to be able to use SPIR-V because I'm tired of high level shader language lock-
in preventing me from:

1\. using existing libraries written in other languages

2\. using features that the graphics hardware has supported for years simply
because the language/API has been abandoned

I agree that it could be convenient to have a readily available human writable
shader language, but don't think it should replace SPIR-V. WSL could be that
language for all I care. It already compiles to SPIR-V.

~~~
throwaway34241
Yeah that seems like it would be ideal since it would satisfy both use cases.

I’m just using OpenGL right now and hoping to port to WebGPU (and the
corresponding native libraries) when it comes out. If the performance is
adequate maybe I’ll skip porting to Vulkan altogether.

So to dynamically load shaders I’d prefer not to have to ship a separate
shader compiler on every platform. I also worry that a separate shader
compiler implementation (used mostly offline) might not have as good
portability/security/performance as something that’s part of a web standard
and implemented directly by browser vendors, although that’s not guaranteed I
guess.

Of course this doesn’t matter to game engines that always compile shaders up
front and already support SPIR-V. But a lot of existing WebGL code isn’t like
that. The rest of the API doesn’t look too complex, so if there was an easy
way to input shaders (of course _in addition_ to SPIR-V) I think it would go a
long way to making it a total replacement for existing WebGL code.

------
abvdasker
Forgive my ignorance of GPU programming. I'm genuinely curious -- how does
this differ from WebGL?

------
imjasonmiller
This is great and I would love to try this out. Unfortunately, support for
Linux seems to be lacking? It’s definitely one of the web technologies I’m
very excited about.

~~~
kvark
You can play with the native implementations on Linux for now, such as wgpu
and Dawn, with an ability to build for the web in the future.

------
alaingalvan
Hey everyone, I'm the original author here, thanks for reading! WebGPU's
pretty exciting stuff, a modern graphics API for the Web.

Feel free to let me know if you have any suggestions/improvements! I'll keep
an eye on the thread though.

------
moondev
Are there any examples of using webgpu for remote desktop applications?

------
sesuximo
this sounds cool, but why do we need it? why can't the web directly expose
opengl?

~~~
mschuetz
OpenGL kind of sucks, tbh. I know because I work full time with it. There are
so many things in OpenGL that are either inneficient, outdated, or plain
stupid. You also can't directly expose it anyway because of poor support on
Windows and MacOS. The former requires you to install proper drivers that
users may not have, the latter deprecated it and to my knowledge already
didn't properly support the latest versions.

So whatever you do in the browser, it would need some kind of translation
layer to another API anyway. On windows that's usually DirectX via ANGLE. Even
today, whatever you do with WebGL will actually be translated to DirectX
calls. On MacOS, WebGL is probably be translated to Metal, right now. Same
with Vulkan.

~~~
jdashg
On macOS WebGL in all browsers goes through OpenGL, same as on Linux and
Android. On Windows, WebGL generally calls into ANGLE-on-D3D, though both
Firefox and Chrome support using "native GL" experimentally as well.

------
domenicd
> Raw

> TypeScript

What?

~~~
TomMarius
Is "raw" reserved only for chemical elements now? Or maybe atomic nuclei only?

