> 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.
Vulkan was not well supported in android until around android 9. In android 10 I believe it can run skia using vulkan (somehow). And broadly vulkan is still in the adoption curve — so seems too early to say vulkan is failing —it’s still quite new.
Vulkan started as optional API on Android and its support is so bad outside Google and Samsung flagship devices, that with Android 10 Google made it a required API with respective OEM acceptance tests.
Yet, the numbers are so tiny that Google has yet to bother to list them on Android Dashboard,
TBH (and IMHO of course) both OpenGL and Vulkan aren't all that great APIs to work with.
OpenGL was a nice API up until early 2.x versions, after that the move away from the fixed-function-pipeline would have needed a clear cut instead of the gradual stacking of new features, and since then two or three other of such "clear cuts" would also have helped, similar to how each new D3D version was incompatible with the previous version (but still supported for a long time).
Vulkan had a problem right from the start that it had to wrap an explicit low-level API over very different GPU architectures. And without the "wiggle room" of more abstract APIs this ended up in a complex API and high number of vendor-specific extensions in a very short time. As a result Vulkan was already bigger and more complex right from the start than OpenGL was after two decades.
I'm personally pretty comfortable with OpenCL and "old" OpenGL (i.e. using immediate point API which is deprecated now, I didn't do any graphics coding for ~a decade). But I found Vulkan impenetrable. The boilerplate code was absolute insanity. I tried to find some libraries that'll implement the boilerplate for me, but couldn't find anything good enough. Maybe I didn't look hard enough, idk, but Vulkan didn't seem like something an OpenGL engineer could pick up in one afternoon.
To understand Vulkan, Metal or Direct3D 12, you first need to understand modern high-level APIs like OpenGL 4 or Direct3D 11. The fixed-function pipeline is nothing like the new way of doing things.
Then you can move to low-level ones, if you really want to spend a few weeks on it! But if it is a hobby, I suggest you stay with a high-level one.
That is the exact thing that is "all warts". It is bending the OpenGL API far beyond its breaking point to desperately try to get it to match what the GPU actually wants.
The medium term future will certainly be competing abstraction layers over varying subsets of D3D, Metal, Vulkan, OpenGL and OpenGL ES. Libraries like bgfx and game engines lead the way. Direct programming against low level APIs is too complex for mere mortals who want to create an actual application without an army of devs just for porting their graphics rendering to different devices (e.g. Vulkan allows for tons of subtle and hard to handle variations in device behaviour and these happen in practice).
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.
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.
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."
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.
Apple created Metal waaay before Vulkan existed and moved their whole ecosystem to it before Vulkan was production ready.
While moving from OpenGL to Metal was a significant technical upgrade for them, moving all their ecosystem from Metal to Vulkan is just a lot of work for very little benefit.
But yeah, sure, maybe they are just sticking with Metal to mess around with people.
MoltenVK is the most prominent Vulkan to Metal translation library. Technically, it's a 1st party library, since it's the core of the Khronos Group's Vulkan SDK on mac/iOS.
It's not 1st party. Up to the very recent, the whole SDK was a "LunarG SDK" for a reason - it wasn't 1st party either. It's basically just somebody packing up a bunch of useful libraries together.
This is my main pain point on how Khronos deals with their APIs.
Naturally for those of us around since the ARB days it hardly matters, but for teaching beginners into 3D world, or nowadays 2D was well, those bunch of useful libraries still lack the tooling experience of proprietary APIs.
And the OEM SDKs are hardly better, because they also provide better tooling for the proprietary APIs.
So in the end it all turns out into a rite of passage for everyone, getting to know which set of useful libraries, useful GPU debugging tools are to be used.
Hence why I just advise most beginners to start with middleware and only afterwards dive into the low level details.
Game consoles also don't support Khronos standards.
Switch has Vulkan, but it has its own NVN, which is what middleware engines and most Switch titles actually take advantage of.
Given that Unity has shared numbers that they are responsible for 50% of the Switch titles, and there is also other middleware, there aren't many titles left.
Vulkan is fine and major games are shipping with it, but you should never expect any 3D API to become standard. Hardware and software vendors will never agree on one, at least for 10 years.
Vulkan is supported on macOS through MoltenVK, provided by Khronos.
MoltenVK is not a Khronos product. It's a product of Brenwill Workshop that is one of the many member companies under Khronos. It moved the code under Khronos github. There is quite a few community / other companies contributions. But it's still just a library out there.
It is provided by Khronos in the sense that they control the repository and they provide it as a permissive, open, free license, which is the important bit for end users of Vulkan.
Whoever develops it is not really important for managers deciding on technologies to use.
> 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.
Other than MacOS/iOS Vulkan's future looks just fine.
Windows UWP has failed so incredibly hard that the Windows Store has begun allowing win32 app distribution, so what UWP supports is irrelevant. And Microsoft's game division has even given up on the Windows Store and releases their games on Steam now as well. So UWP is doubly irrelevant currently.
Intel's Skylake & newer support Vulkan 1.1 (which are 4 years old now). Not supporting Haswell/Broadwell is annoying as those do support D3D12, but that's the only API gap in Intel's lineup, and that's obviously something that's on a clock to stop mattering at some point. After all, Intel's iGPU primarily matters on laptops, and laptops tend to have a shorter lifespan than desktops as things other than the CPU show their age a lot more quickly.
The 50% on Android is also a thing that'll be solved with time. If Khronos doesn't do a new OpenGL ES, then eventually the driver priority on mobile will shift over to Vulkan as that's what benchmarks will begin prioritizing, and that's what sells hardware. Android's latency to supporting something new is incredibly long, but it does also keep moving forwards fairly reliably.
So MacOS/iOS is currently the only real question mark on Vulkan's future. But then again, Apple seems to only want Metal on their platform, which doesn't work anywhere else, so no "standard" will matter. You'll be forced onto a compatibility layer of some kind to work on Apple - be it MoltenVK, bgfx/sokol-gfx, or WebGPU. The article dresses up WebGPU as being superior because it's backed by a standard, but that's nonsense. The quality of the implementation is the only thing that matters, and bgfx/sokol-gfx already have quite the head-start there. There's no particular reason to think a couple of people on Firefox are going to be "strictly superior" to the couple of people on bgfx/sokol-gfx. Maybe WebGPU will end up better, in which case great! But it's the same basic thing as what already exists today. It's very firmly in the "compatibility layer" camp here, despite the article trying desperately to dress it up as something else. There's no driver support for it, there's no influence on hardware road-maps, etc...
So right now if you could only target a single driver API then Vulkan would cover more platforms than any other driver-native standard. Which is no small feat.
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”.
This is somewhat disingenuous. The big advantage to breaking with standards to do your own thing is that you don't have to deal with committee politics or delays. You can iterate quickly on ideas you think are good and test them in the market right now.
> 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).
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.
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).
> 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).
I'm feeling the same way, I'm interested in getting into doing a little graphics programming as a beginner, but the whole thing does feel impenetrable.
I don't think getting into OpenGL is actually that hard. There are wrapper libraries, e.g. for Java, and tons of tutorials.
The hardest part for beginners is probably wrapping their head around the concept of the rendering pipeline, with it's various stages. Once this is settled, it becomes much clearer what the various shaders do and how they interact with each other. So I'd higly recommend spending some time to understand rendering pipelines first.
Absolutely this. I wish I had spent more time learning about the rendering pipeline before jumping into trying out so much as a "Hello Triangle" tutorial.
It's also worth getting familiar with terminology early on, because common terms in the context of graphics programming have different meanings to their common usage. e.g. I've found it helpful to think of a "vertex" first and foremost as an element of an array, which is processed SIMD-style by the "vertex shader". In most cases it is the co-ordinates of a polygon vertex, but usually with other data bundled in the element as well such as texture co-ordinates. The term "shader" seems to be used for any program that runs on the GPU, regardless of whether it does shading of any kind.
I agree. I recently started exploring OpenGL and found it pretty approachable. If someone is looking for a resource to help learn OpenGL, I found https://learnopengl.com/ extremely helpful.
OpenGL isn't hard, but it's API is outdated and full of surprises. Error reporting is bad (glGetError), debug context works somewhat better (error callbacks), but I had errors that reproduce on debug context only. C API is very weakly typed, so it's easy to pass GL_RGBA to a function which expects GL_RGBA8. But the worst part of OpenGL is the state machine. OpenGL is the only graphical API still remaining that has the concept of state machine, and it causes a lot of trouble when rendering. You basically have to abstract the entire state machine on your side of code, or defensively back out all state changes that you do. Modern APIs are more stateless, and state object is passed along with the drawcall, more or less, without affecting any other drawcalls in the commandbuffer.
Legacy OpenGL is a pain not because of the state machine, but the many ways of doing things, some of which are slow. The weird function names don't help either.
WebGL is better than that because it is only the useful, fast subset, and provides some objects too. Plus JavaScript is easier to work with than C, too.
Anyway modern APIs are not stateless, having an object that contains the state is the same. In the end, it is still all about bind this, bind that, do this, do that.
Might I shamelessly plug my sokol_gfx.h library (assuming your language of choice is C or C++). These are WASM samples written in C or C++, a link to the source code is in each sample:
A complete Hello Triangle fits in a single source file of about 80 lines, and the API structure of sokol-gfx is close enough to modern 3D-APIs that it also serves as a useful starting point if you want to move on to Metal, D3D12 or Vulkan (or even WebGPU) later.
I edited it, but let me say I don't agree with your policy, because downvoting is reserved for high-score accounts. If it would be open to (almost) everyone, then it would be fine.
In fact, if you think about it, what is "petty" isn't talking about downvoting, but the ability to downvote itself. Flagging is fine, because trolls will always be around.
> Except going forward, those are going to be the only APIs available
That is false. There are already library implementations of legacy OpenGL, modern OpenGL, OpenGL ES, WebGL, legacy Direct3D, Direct3D 10/11, Direct3D 12, Vulkan and others.
Major players like Microsoft, AMD, Khronos, Valve and others already depend and employ people on providing those APIs and libraries long-term.
Those APIs are not going anywhere, even if a hardware vendor decides to only provide a low-level one (which is understandable, by the way...).
> They are still there, but not longer map to existing graphics hardware.
They have never mapped to hardware, so there is no real difference between now and then.
WebGL follows the OpenGL programming model, which isn't "simple" either, we just got used to it over time.
Also, there's a lot of room for sane APIs between GLES2 and Vulkan, so much room that a single "standard" 3D-API doesn't make much sense TBH since there are many different opinions on where the "sweet spot" for a 3D-API lies between ease-of-use, feature coverage and acceptable layering overhead.
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.
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)
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.
I'd like to chime in by pointing you fine folks to http://regl.party — a functional, partial-application, "stateless WebGL" library that lets you model rendering commands as nested little scopes. It offers "the rest of us" a graphics programming foundation that's lower level than three.js, and I can't recommend it enough.
IMO, WebGL's implementation has some glaring wrinkles that REGL-like libraries can't smooth away, but at least REGL does a decent job of tackling the state problems you're discussing, while offering a more flexible approach (I think?) than the out-of-the-box WebGPU API's render pass command encoder.
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.
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.
Shipping compiled shaders is a feature request that pops up from time to time in gfx-rs land [1]. So far, we have been skeptical about this. Something like a serializable pipeline cache would help, but not entirely solve the shipping binary size. Although, is it really important? "Hello Triangle" may be a few megs, but the code for shader translation is a constant addition to it, so extrapolating this 5.2Mb value is not useful.
Currently, both Dawn and wgpu-native use SPIRV-Cross for translation of shaders. The plan is for both is to migrate to in-house translation. In case of wgpu, that would be Naga [2]. Sometime in the future, you could be able to include it with only WGSL -> AIR (Apple's shader IR) code path compiled in, without anything else. Could be good enough for the code size? :)
Yeah it will be interesting to see whether a different set of libraries for the shader translation will cut down the size a bit.
Of course in a "big" application like a 3D modeller or many games, 4..5 MB added to the exe size isn't critical, but for smaller applications it seems a bit excessive TBH.
And if there's already an offline shader compilation step in a game-engine's asset pipeline anyway, why not do the whole backend-specific shader preprocessing there as well.
AIR is not a documented or supported endpoint. MSL is the supported endpoint. You will hear from Apple's lawyers if toy reverse engineer AIR, as one of my colleagues knows from experience.
Lawyers know how to fight corporate entities. This tech doesn't have to be a corporate product. It could be a separate community repository somewhere, used only by those native gfx/wgpu users who opt into it.
It might be really difficult to avoid runtime shader translation without some other solution (e.g. populating pipeline caches ahead of time).
For example, to provide MSL, there needs to be assumptions about exactly which MSL version is supported, all possible values of specialization constants if the MSL version is less than 1.2, all the details of which pipeline layouts will be used at runtime, etc. and all of these also have to match the internal logic used in Dawn or wgpu.
Given that any most implementations of WebGPU will be open source it should be trivial for you to add a way to use pre-compiled native shaders to whatever implementation you choose to use.
s/trivial/possible/. But yes, this is a wishlist item for me (in piet-gpu) as well, partly because of the bloat issues and partly because I want to be able to use the most advanced features (subgroup operations) that the shader languages provide, and there's currently a pretty big gap there.
I've been playing Dreams on PS4 a lot recently, and it's kind of like "game development for the rest of us". I'd love to see a Dreams-like web application that allows anyone to create and share small-scale interactive experiences. Seems like WebGPU is a step in that direction.
Another great usage option would be for GTK Broadway. Right now Broadway does not support any form of OpenGL so pretty much any CAD or design tool written in GTK would not work with Broadway. It is quite a disadvantage if you are running heavy workloads on a compute cluster and have to resort to VNC/Xpra which is much, much more slower than Broadway. This is especially if you are doing instrumentation or ML work and your charting tool uses OpenGL for performance.
Fun challenge for HN: rewrite Xpra in Rust, it is currently implemented in AOT-compiled Python (Cython)
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.
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?
Browsers are Javascript bindings to WebGPU :) But more seriously, there is a 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.
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.
Watching Unity progress is amazing how it is spanning out from being a game engine into a whole technology and art canvas. Pretty confident we'll be seeing Unity rendering effects in at least one Hollywood movie in the next 5 years.
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
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.
That is a common Khronos approach to learning, one should learn everything from ground up, including hunting for libraries that handle math, images, fonts, shader loading,...
I agree with you, this is not the way to bring people up to speed with graphics programming.
"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.
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?
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.
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.
"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.
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.
97 comments
[ 3.0 ms ] story [ 154 ms ] threadWow. 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.
Yet, the numbers are so tiny that Google has yet to bother to list them on Android Dashboard,
https://developer.android.com/about/dashboards
Last update was on May 1, 2020.
OpenGL was a nice API up until early 2.x versions, after that the move away from the fixed-function-pipeline would have needed a clear cut instead of the gradual stacking of new features, and since then two or three other of such "clear cuts" would also have helped, similar to how each new D3D version was incompatible with the previous version (but still supported for a long time).
Vulkan had a problem right from the start that it had to wrap an explicit low-level API over very different GPU architectures. And without the "wiggle room" of more abstract APIs this ended up in a complex API and high number of vendor-specific extensions in a very short time. As a result Vulkan was already bigger and more complex right from the start than OpenGL was after two decades.
Then you can move to low-level ones, if you really want to spend a few weeks on it! But if it is a hobby, I suggest you stay with a high-level one.
The medium term future will certainly be competing abstraction layers over varying subsets of D3D, Metal, Vulkan, OpenGL and OpenGL ES. Libraries like bgfx and game engines lead the way. Direct programming against low level APIs is too complex for mere mortals who want to create an actual application without an army of devs just for porting their graphics rendering to different devices (e.g. Vulkan allows for tons of subtle and hard to handle variations in device behaviour and these happen in practice).
"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...
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.
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
While moving from OpenGL to Metal was a significant technical upgrade for them, moving all their ecosystem from Metal to Vulkan is just a lot of work for very little benefit.
But yeah, sure, maybe they are just sticking with Metal to mess around with people.
https://github.com/KhronosGroup/MoltenVK
Naturally for those of us around since the ARB days it hardly matters, but for teaching beginners into 3D world, or nowadays 2D was well, those bunch of useful libraries still lack the tooling experience of proprietary APIs.
And the OEM SDKs are hardly better, because they also provide better tooling for the proprietary APIs.
So in the end it all turns out into a rite of passage for everyone, getting to know which set of useful libraries, useful GPU debugging tools are to be used.
Hence why I just advise most beginners to start with middleware and only afterwards dive into the low level details.
Hopefully WebGPU can also help there.
Switch has Vulkan, but it has its own NVN, which is what middleware engines and most Switch titles actually take advantage of.
Given that Unity has shared numbers that they are responsible for 50% of the Switch titles, and there is also other middleware, there aren't many titles left.
Vulkan is supported on macOS through MoltenVK, provided by Khronos.
Whoever develops it is not really important for managers deciding on technologies to use.
But from the early days it was clear that MS and Apple will bet on their own proprietary APIs so the current situation is not news.
Other than MacOS/iOS Vulkan's future looks just fine.
Windows UWP has failed so incredibly hard that the Windows Store has begun allowing win32 app distribution, so what UWP supports is irrelevant. And Microsoft's game division has even given up on the Windows Store and releases their games on Steam now as well. So UWP is doubly irrelevant currently.
Intel's Skylake & newer support Vulkan 1.1 (which are 4 years old now). Not supporting Haswell/Broadwell is annoying as those do support D3D12, but that's the only API gap in Intel's lineup, and that's obviously something that's on a clock to stop mattering at some point. After all, Intel's iGPU primarily matters on laptops, and laptops tend to have a shorter lifespan than desktops as things other than the CPU show their age a lot more quickly.
The 50% on Android is also a thing that'll be solved with time. If Khronos doesn't do a new OpenGL ES, then eventually the driver priority on mobile will shift over to Vulkan as that's what benchmarks will begin prioritizing, and that's what sells hardware. Android's latency to supporting something new is incredibly long, but it does also keep moving forwards fairly reliably.
So MacOS/iOS is currently the only real question mark on Vulkan's future. But then again, Apple seems to only want Metal on their platform, which doesn't work anywhere else, so no "standard" will matter. You'll be forced onto a compatibility layer of some kind to work on Apple - be it MoltenVK, bgfx/sokol-gfx, or WebGPU. The article dresses up WebGPU as being superior because it's backed by a standard, but that's nonsense. The quality of the implementation is the only thing that matters, and bgfx/sokol-gfx already have quite the head-start there. There's no particular reason to think a couple of people on Firefox are going to be "strictly superior" to the couple of people on bgfx/sokol-gfx. Maybe WebGPU will end up better, in which case great! But it's the same basic thing as what already exists today. It's very firmly in the "compatibility layer" camp here, despite the article trying desperately to dress it up as something else. There's no driver support for it, there's no influence on hardware road-maps, etc...
So right now if you could only target a single driver API then Vulkan would cover more platforms than any other driver-native standard. Which is no small feat.
Also as information the WIn32 sandbox model also only allows DirectX, and Microsoft way forward is to support OpenGL on top of DirectX.
https://devblogs.microsoft.com/directx/in-the-works-opencl-a...
Expect Vulkan to get a similar treatment, the OpenGL 1.1 ICD driver model won't exist forever.
Vulkan on Android is still so meaningless that the dashboard, updated this month, still doesn't show Vulkan support.
https://developer.android.com/about/dashboards
And then there are the game consoles.
That is why Microsoft, Sony, NVIDIA, Apple, Xilinx, etc. create their own platforms and APIs.
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).
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.
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).
I'm feeling the same way, I'm interested in getting into doing a little graphics programming as a beginner, but the whole thing does feel impenetrable.
The hardest part for beginners is probably wrapping their head around the concept of the rendering pipeline, with it's various stages. Once this is settled, it becomes much clearer what the various shaders do and how they interact with each other. So I'd higly recommend spending some time to understand rendering pipelines first.
It's also worth getting familiar with terminology early on, because common terms in the context of graphics programming have different meanings to their common usage. e.g. I've found it helpful to think of a "vertex" first and foremost as an element of an array, which is processed SIMD-style by the "vertex shader". In most cases it is the co-ordinates of a polygon vertex, but usually with other data bundled in the element as well such as texture co-ordinates. The term "shader" seems to be used for any program that runs on the GPU, regardless of whether it does shading of any kind.
Oy vey
WebGL is better than that because it is only the useful, fast subset, and provides some objects too. Plus JavaScript is easier to work with than C, too.
Anyway modern APIs are not stateless, having an object that contains the state is the same. In the end, it is still all about bind this, bind that, do this, do that.
I wanted to play with Nvidia's real-time raytracing. They have a nice tutorial to show a triangle.
https://developer.nvidia.com/rtx/raytracing/dxr/DX12-Raytrac...
https://developer.nvidia.com/rtx/raytracing/dxr/DX12-Raytrac...
https://floooh.github.io/sokol-html5/
A complete Hello Triangle fits in a single source file of about 80 lines, and the API structure of sokol-gfx is close enough to modern 3D-APIs that it also serves as a useful starting point if you want to move on to Metal, D3D12 or Vulkan (or even WebGPU) later.
Then you should be looking at WebGL, not WebGPU!
https://news.ycombinator.com/newsguidelines.html
In this case specifically I'd just use the second half of your comment, the first half just detracts from the message and sounds petty.
In fact, if you think about it, what is "petty" isn't talking about downvoting, but the ability to downvote itself. Flagging is fine, because trolls will always be around.
It would be the same as using SVAlib or Allegro nowadays.
They are still there, but not longer map to existing graphics hardware.
That is false. There are already library implementations of legacy OpenGL, modern OpenGL, OpenGL ES, WebGL, legacy Direct3D, Direct3D 10/11, Direct3D 12, Vulkan and others.
Major players like Microsoft, AMD, Khronos, Valve and others already depend and employ people on providing those APIs and libraries long-term.
Those APIs are not going anywhere, even if a hardware vendor decides to only provide a low-level one (which is understandable, by the way...).
> They are still there, but not longer map to existing graphics hardware.
They have never mapped to hardware, so there is no real difference between now and then.
That is like telling someone that coding against POSIX.1 is all they will ever need for their applications.
https://fosdem.org/2020/schedule/event/rust_webgpu/
Also, there's a lot of room for sane APIs between GLES2 and Vulkan, so much room that a single "standard" 3D-API doesn't make much sense TBH since there are many different opinions on where the "sweet spot" for a 3D-API lies between ease-of-use, feature coverage and acceptable layering overhead.
WebGPU is a low-level API is more flexible than WebGL, which means more complexity. That is why it is being introduced, after all!
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)
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.
IMO, WebGL's implementation has some glaring wrinkles that REGL-like libraries can't smooth away, but at least REGL does a decent job of tackling the state problems you're discussing, while offering a more flexible approach (I think?) than the out-of-the-box WebGPU API's render pass command encoder.
Currently, both Dawn and wgpu-native use SPIRV-Cross for translation of shaders. The plan is for both is to migrate to in-house translation. In case of wgpu, that would be Naga [2]. Sometime in the future, you could be able to include it with only WGSL -> AIR (Apple's shader IR) code path compiled in, without anything else. Could be good enough for the code size? :)
Of course in a "big" application like a 3D modeller or many games, 4..5 MB added to the exe size isn't critical, but for smaller applications it seems a bit excessive TBH.
And if there's already an offline shader compilation step in a game-engine's asset pipeline anyway, why not do the whole backend-specific shader preprocessing there as well.
Not a show-stopper of any kind of course ;)
For example, to provide MSL, there needs to be assumptions about exactly which MSL version is supported, all possible values of specialization constants if the MSL version is less than 1.2, all the details of which pipeline layouts will be used at runtime, etc. and all of these also have to match the internal logic used in Dawn or wgpu.
There's some more discussion about this in gfx and wgpu, e.g. https://github.com/gfx-rs/gfx/issues/3117#issuecomment-57045...
Fun challenge for HN: rewrite Xpra in Rust, it is currently implemented in AOT-compiled Python (Cython)
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.
What I am missing is not a Web replacing operating systems, but better operating systems!
> What I am missing is not a Web replacing operating systems, but better operating systems!
But, that I cannot argue.
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.
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
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.
I agree with you, this is not the way to bring people up to speed with graphics programming.
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.
Unity, Unreal, Xenko/Stride, CryEngine, Unigine
It definitely got me excited for this new piece of technology.
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.
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
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.