
Point of WebGPU on Native - olalonde
http://kvark.github.io/web/gpu/native/2020/05/03/point-of-webgpu-native.html
======
flohofwoe
I'm really rooting for WebGPU as the "cross-platform 3D-API for the rest of
us" (where "rest of us" is everybody who isn't a highly specialized rendering
engineer in an AAA-game engine team).

There's "one small thing" I'd like to see in WebGPU for the native use case:
an optional compile-time configuration feature which allows to pass in
"backend-native" shaders so that all the runtime-shader-translation code isn't
necessary.

Example size for compiling "Hello Triangle" on macOS before and after
stripping, both using the Metal backend:

\- with sokol-gfx: 95 KB, 91 KB

\- with Google Dawn: 5.2 MB, 4.0 MB

I bet that most of that 4 MB overhead is coming from the integrated shader
validation and translation code. I haven't tested with wgpu-native, but I
guess the size overhead will be similar.

Since native applications don't need the strict shader validation of the web
platform, this probably would also speed up pipeline creation a bit :)

PS: clarification, the executable size for Dawn is _also_ using sokol-gfx but
using its new WebGPU backend and statically linked against Dawn (which in turn
is using its own Metal backend), so not a 'Hello Triangle' built directly on
top of the webgpu.h API. The size difference should be negligible though (at
most a few Kbytes more).

~~~
jfkebwjsbx
> where "rest of us" is everybody who isn't a highly specialized rendering
> engineer in an AAA-game engine team

Then you should be looking at WebGL, not WebGPU!

~~~
skocznymroczny
No, WebGPU will be easier to use than WebGL, because it doesn't have the
global state. Global state is the worst thing about OpenGL and requires a lot
of code to get it under control.

~~~
jfkebwjsbx
WebGL is different than legacy OpenGL from 20 years ago. WebGL is pretty easy
to work with.

WebGPU is a low-level API is more flexible than WebGL, which means more
complexity. That is why it is being introduced, after all!

~~~
mmis1000
However It still use global state, you need to flush state everywhere when
switch scenes.

Run another filter? good, switch everything on global state. Render another
scene with different texture? Set everything again.

Moreover... if you forgot to reset something after change it. You got weird
bug that only happen under some specific order of operation. Because
everything share a global state.

And it is full sync. A shader takes long time for render also makes your whole
page non responsive, which is a pain. (open the list page of shadertoy, you
will know what am I saying)

~~~
jfkebwjsbx
You don't need to reset everything, only whatever you change. Yeah, other APIs
allow you to keep the state pre-packaged and switch from what appears a single
command, but the state is still there nevertheless.

The full sync is a problem of how WebGL is provided. They could easily change
it to allow parallel rendering as long it is to independent contexts.

~~~
mmis1000
I am not sure it is easy to change opengl to run parallelly given it all
shares a global state. How do you not mess up anything when render two scene
at same time if two pipeline shares the same variable but you want to fill it
with different value? And if you really want to change it so hard to give
pipelines standalone context. Why not use the webgpu? It seems just designed
in a stateless way that I just described.

~~~
skocznymroczny
OpenGL wasn't designed with multithreading/parallel execution in mind. Before
running any OpenGL call, you have to bind the application-wide context to a
specific thread. Vulkan, DX12 work differently - they allow you to create
command lists from separate threads, but in exchange you have to work on the
synchronization yourself via semaphores and fences.

------
valand
Web and client-side WebAPI has security first in mind. The conception of WASM
and WebGPU is pushing Web into wider audiences and influence, taking up what
used to be OS' market.

On the OS side, Google the capability-based OS Fuchsia. Someone in Google
understands that user's consent over their computation resource
(file/directory, network) is more important than ever.

And then there's WASI where it will enable OS to directly host WASM while
allowing controllable gates over computation resources. WASI might be an
important endeavor in the future and I think WebGPU design should have WASI in
mind.

Those may have conflicts of space and market in the future, but all are moving
into the same interest, the balance of user's consent over resources,
security, and performance. It seems these standards are in good hands.

~~~
jfkebwjsbx
Capability-based systems have been a thing for decades but never took off for
lack of interest and complexity.

What I am missing is not a Web replacing operating systems, but better
operating systems!

~~~
valand
Non-technical users are driven to rely more and more on the web app than
direct-to-OS-apps due to how easy to build they are.

> What I am missing is not a Web replacing operating systems, but better
> operating systems!

But, that I cannot argue.

------
davedx
> Besides, real Vulkan isn’t everywhere. More specifically, there are no
> drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on
> Windows UWP (including ARM), it’s below 50% on Android, and totally absent
> on macOS and iOS. Vulkan Portability aims to solve it, but it’s another
> fairly complex layer for your application, especially considering the shader
> translation logic of SPIRV-Cross, and it’s still a WIP.

Wow. Has Vulkan failed as a standard then? I'm interested in this area but
came away from the article feeling extremely confused about what the future of
portable graphics programming looks like.

I know despite the hopes for WebGPU there's NWIH I will invest time learning
it while everything is so up in the air.

OpenGL is great despite its warts, I've had a lot of fun programming with it
over all the years.

~~~
greggman3
There's no Vulkan on MacOS/iOS (though there may be some 3rd party library
that will translate to Metal).

~~~
kevingadd
While true this boils down to "Apple won't support anything it doesn't have
control over", as demonstrated by them using veto power to pick WebGPU's
shader language (a custom one) instead of using the shader IR literally
everyone else wanted. It doesn't make a ton of sense to evaluate the success
of APIs and standards this way because Apple has a long track record of
refusing to implement stuff or deprecating it once they had an interest in
promoting a proprietary alternative.

~~~
kvark
That paints Apple in a wrong light. They agreed on the WebGPU Shading Language
proposed by Google (!) (previously called "Tint"). This is something Google is
interested in, as well.

~~~
kevingadd
It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to
disputes with Khronos. Tint is a compromise, it doesn't matter who proposed
it.

"MS: Apple is not comfortable working under Khronos IP framework, because of
dispute between Apple Legal & Khronos which is private. Can’t talk about the
substance of this dispute. Can’t make any statement for Apple to agree to
Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say
whether we’re (Apple) happy with that. NT: nobody is forced to come into
Khronos’ IP framework."

[https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...](https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_253vEtKxuUkTGvxpuv8Ac/edit)

~~~
kvark
I know, I was there. I also think that objection to SPIR-V wasn't completely
unfounded. SPIR-V is a nice binary representation of shaders, but it has
problems in the context of WebGPU adoption:

1\. It's so low level that generating HLSL and MSL from it is more painful
than it could be. For example, it represents branching in the form of a
Control Flow Graph (which is typical for an IR). This is lower level than
either a source language people would use (e.g. GLSL), or the destination
backend language we need to produce (e.g. HLSL or MSL). This is unnecessary
complexity for translation.

2\. It has a lot of instructions, covering wide range of hardware (somewhat
similar to Vulkan). In contrast, for WebGPU it would make sense to have fewer
instructions for the ease of securing it and translating to other
representations.

3\. Friction in the features we need, vs features Khronos needs.

There is also a situation where there is no single well specified and tested
textual shading language. HLSL doesn't have a spec. MSL has documentation, but
not enough for a spec, and it's not portable. GLSL kinda has a few specs, but
realistically it's just specified by the implementation of glslValidator.

~~~
dagmx
I think this is actually something that might be deserving of a blog post
itself, if you had the time.

There’s a lot of opinions from people outside the working group for WGSL as to
why it exists.

I think most of the PR damage right now comes from those people not having
enough context and thus framing it in a negative light.

A blog post with more context and information would probably help imho

------
peteforde
Most of this is "head-adjacent" for me, but there's one point where I'm
confident the author is not seeing the whole forest, and that is the
comparison to Unity. I'm sympathetic that someone working so hard to make
WebGPU amazing would perceive the value of Unity through the lens of not
having to worry about arcane device compatibility concerns.

However, that's just a tiny slice of the reasons driving Unity's runaway
success train. After all, if this were true, everyone would just be using
ThreeJS. And don't get me wrong - ThreeJS has a massive and well-deserved user
base, but few see it as a serious platform.

Unity is crushing it because they provide an almost VB6-like canvas to paint
on; because they have the most outrageously comprehensive asset-store
ecosystem I've seen for any platform period; and because they frequently
support the cool new toys like ARKit the day that they are announced.

Unity is hands-down my favourite way to introduce day-one noobs to
programming. I can take someone who has never programmed before and lead them
through creating a VR experience where they can fight a giant spider with a
burning sword in about an hour.

The idea to payoff pathway Unity offers someone who is deciding whether to
pursue programming in real time is _crazy_.

~~~
flohofwoe
That is definitely (mostly) true, but integrated engines like Unity or UE4
also heavily nudge you in doing things their way and come with a non-trivial
size overhead (e.g. it is complete overkill to use Unity for your next Tetris
clone).

And let's be honest, if you sit beginners in front of Unity they don't learn
programming, instead they learn "Unity problem solving", e.g. "Unity trivia"
which is hardly applicable to other contexts.

In my opinion, Unity is the Photoshop for game creation, you work on a very
high level, but it's also very convenient (if you actually follow the rules
and workflows).

But there are quite a few commercial games which use Unity only as a 'cross-
platform wrapper', because their game client is more or less just a dumb
input+rendering client, and the actual gameplay stuff all happens server-side.

It would be awfully nice if Unity could be split into a couple of standalone
products (however that probably won't happen because it doesn't make much
commercial sense):

\- a low-level platform-abstraction library which contains all the driver-bug
workarounds and behind-the-scene-fixes that have been accumulated over the
years

\- a 'bring-your-own-engine' asset pipeline and editor

\- and finally, the actual Unity runtime engine, split into modules

~~~
peteforde
I dunno. This is all so subjective. I don't think Day 1 of programming is
about picking up programming. It's about seeing if there's going to be a Day
2-4.

And if Unity isn't in the picture, they sure as fuck aren't going to be
hearing about WebGPU for the first 3-5 years of their journey.

Photoshop for game creation is a little bit loaded. I'll take it in good faith
but point aggressively to how wrong you are because it's possible you just
don't realize how much cutting edge engineering is being deployed.

For example, there's currently a major push towards moving everyone over to a
job scheduled, burst-compiled data-driven architecture so that you can have
tens of thousands of actors on screen at once. I stand by what I said about a
VB6-like UI experience, but nobody is building anything real without learning
a ton of C#, Quaternion math and shader language.

~~~
flohofwoe
"Photoshop for game creation" in the sense of: Unity has become the standard
tool for creating games, and definitely has "democratized" and standardized
creating games. But with this standardization also came a loss of diversity.
Just as all drawing programs more or less became Photoshop clones, all
integrated game development solutions eventually became Unity clones because
that's exactly what users expect nowadays.

The under-the-hood technology in Unity is definitely bleeding edge, but the
user-facing workflows aren't anymore, they simply cannot "revolutionize" their
workflows again as they did a decade ago, because that would alienate their
own user base. Being the "industry standard" also has its downsides.

------
1_player
Fantastic blog, I've devoured its few articles describing the whole history of
WebGPU from the WebMetal prototype in 2016 until where we are today.

It definitely got me excited for this new piece of technology.

------
FpUser
The author states something like:

Use XXX API and deal with bugs, incompatibilities, etc. etc.

What makes him think that this new API will be free of any of things he
mentions above? As far as I can see this whole high performance graphics area
has always been a wasps nest of various vendors each trying to pull the
blanket to their side. I doubt adding "Web" to it will make life any easier.

~~~
kvark
At some point, it comes down to the amount of momentum behind the API. In case
of WebGPU, we have strong support from Intel and Apple, which are hardware
vendors, as well as Google, who can influence mobile hardware vendors. We are
making the specification and have resources to appropriately test it and
develop the necessary workarounds. It's the quantity to quality transition
that sometimes just needs to cross a certain threshold in order to succeed.

~~~
FpUser
_" It's the quantity to quality transition that sometimes just needs to cross
a certain threshold in order to succeed."_

So until that happens it is still: Use XXX API and deal with bugs,
incompatibilities, etc. etc. We are back to square one.

I would really love it if we have some decent multiplatform high performance
graphics API (with single shader language). I would also love said API to not
require one possess PhD. However looking back the last 20 years does not
inspire much optimism.

Wish you luck anyways

------
thinkloop
This touches on apps vs. web a little. Fundamentally what's the difference
between mobile apps and the web? Is one naturally faster? Smoother? More
cross-platform? Better at sensors? Offline mode? Not at all, not fundamentally
at least. They are both just code on a machine. Either of them can make their
runtimes do whatever they like whenever they like. If the web dedicated all
it's resources to performance they would be smooth as native - there is no
physical law prohibiting that. And vice versa for cross-platform
compatibility. The fundamental difference is philosophical. The web consortium
starts with consensus and cross-platform compatibility as a core tenant, while
native pumps out proprietary features. They both strive for the same point but
approach from opposite ends of the spectrum. As time goes on they might
converge on the same point - which philosophy will win?

------
tengbretson
I wonder if we'll see any 2d UI frameworks built on this in an effort to get
around the DOM entirely? Similar to what famo.us tried to do with 3D
accelerated CSS.

------
saurik
Is there an easy way to get Dawn or wgpu attached to v8 or SpiderMonkey
without having to involve the entire rest of a web browser? I see there are a
number of language bindings for wgpu in the wgpu-native repository, but
surprisingly not JavaScript. I found commits placing it in servo, but I don't
see why the vast majority of the API surface should be reliant on a browser
:(. As an analogy, I can use OpenGL without a GUI toolkit, and the only parts
that are really connected to the GUI toolkit are a handful of presentation
functions at the very top: the headers and libraries for OpenGL are
abstract/common no matter what toolkit you are using. I want to use WebGPU in
all the same contexts I use OpenGL: to do accelerated rendering operations,
not merely to display graphics. I would thereby expect that I would have
bindings for WebGL/WebGPU (with all of its safety/security transformations) at
a lower level that can target a JavaScript engine API and then I can build
whatever GUI I wanted at a higher layer. Where is the impedance mismatch in
what I am thinking vs. how this always seems to be implemented?

~~~
kangz
Browsers are Javascript bindings to WebGPU :) But more seriously, there is a
[https://github.com/maierfelix/webgpu](https://github.com/maierfelix/webgpu)
that implements node bindings for Felix's Dawn fork. The fork is close to
upstream and Dawn is close to "webgpu.h" so it should be easy to repurpose.

------
xt00
Sounds promising — would be great to know the history on why the other people
who tried to make the one graphics api to rule them all failed? Seems like
that could be helpful in the whole “learning from the past thing”.

~~~
jfkebwjsbx
Because hardware vendors don't want one. Lock-in when you are leading your
particular niche gives big profits, so companies go for it.

That is why Microsoft, Sony, NVIDIA, Apple, Xilinx, etc. create their own
platforms and APIs.

~~~
kllrnohj
> Because hardware vendors don't want one. Lock-in when you are leading your
> particular niche gives big profits, so companies go for it.

Complete nonsense. All the hardware vendors except Apple support Vulkan and
contributed towards it.

NVIDIA hasn't created their own graphics API since... ever, actually. They
_have_ their own APIs, of course (cuda being an obvious one, but there's also
NVAPI), but they don't do graphics. Because hardware vendors have no interest
or motivation in making more drivers than they need to, because drivers are
hard & expensive. So much so that driver _quality_ is a better lock-in for
them.

Consoles use exclusives to drive lock-in, not APIs. Consoles have their own
APIs, but historically that's always been a performance thing. They want to
give game devs the rawest access they can, to make the best looking games they
can. Maybe low-level APIs like Vulkan will end up changing that, maybe it
won't, but it's not a "lock-in" thing. OS's use APIs to do lock-in, but they
don't make hardware (Apple being the exception here, of course).

~~~
pjmlp
Sony and Nintendo definitely make hardware.

Microsoft not only does not support Vulkan, ICD drivers aren't allowed in
Win32 and UWP sandbox models.

NVidia designs their hardware in collaboration with Microsoft, giving first
class support to DirectX, and only afterwards they port the features as
extensions to Vulkan/OpenGL.

Latest two examples, Ray Tracing and MeshShaders.

------
eschaton
A web page is for presenting structured text with embedded media, and
optionally associated—and user-replaceable—style information.

A web page does not need direct or even indirect access to your GPU, and it
does not need to run a Turing-complete language.

