
WebGPU demos - tilt
https://webkit.org/demos/webgpu/
======
blauditore
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...

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

~~~
flohofwoe
Vulkan is only available on Win32, Linux and Android though. The reality is
that there is no standard low-level 3D-API. I don't see this as a problem
though, the complexity of Vulkan shows that it is very hard to create a one-
size-fits-all 3D API, competition is good and Metal shows that it is possible
to create a balanced 3D-API which combines modern features with ease of use.

~~~
pjmlp
Regarding Windows, Vulkan is only available on the desktop.

UWP only allows for DirectX.

And it is an optional 3D API on Android, starting with version 7.0. Which
makes it pretty useless when targeting the majority of Android market, given
the whole upgrade story.

------
jsheard
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
Perhaps this is Mozilla's implementation?

[https://github.com/kvark/webgpu-servo](https://github.com/kvark/webgpu-servo)

~~~
GlitchEnzo
No, Mozilla's is Obsidian: [https://github.com/KhronosGroup/WebGLNext-
Proposals/tree/mas...](https://github.com/KhronosGroup/WebGLNext-
Proposals/tree/master/Obsidian-Mozilla)

~~~
haxiomic
Obsidian ultimately became WebGPU in servo (the op's link)
–[https://github.com/KhronosGroup/WebGLNext-
Proposals/pull/11#...](https://github.com/KhronosGroup/WebGLNext-
Proposals/pull/11#issuecomment-346517188)

------
mxfh
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
Apparently WebCL was blocked by Apple who refused to let their OpenCL patents
be used: [https://www.khronos.org/files/ip-disclosures/webcl/Apple-
Web...](https://www.khronos.org/files/ip-disclosures/webcl/Apple-WebCL-
Disclosure-Jan14_clean.pdf) ("Apple does not agree to make available .. for
any WebCL Specifications")

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

~~~
pjmlp
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
Previous discussion from 9 months ago:
[https://news.ycombinator.com/item?id=14100783](https://news.ycombinator.com/item?id=14100783)
(34 comments)

------
sgt
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
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
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
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
Hehe, didn't notice the username. :)

Might be, but what counts is the perception when someone goes to a given web
page.

EDIT: Just tried your shader toy example on an LG Power X, with a Mali T720,
it averages on 20FPS.

------
markdog12
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...](https://lists.w3.org/Archives/Public/public-
gpu/2017Sep/0015.html)

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

------
pier25
But why?

