I have been playing around with slang, which is supposed to be more cross platform. They have a neural rendering slant, and I have yet to fully test on all platforms, but I think it's a welcome move to consolidate all these apis. https://shader-slang.org/

Vulkan is by far the worst API of all the modern graphics API. It's crap. It's also not even trying to be portable, expecting you to query a million things and then adapt to the platform.

I for one am glad Vulkan is not "it"

Also, it's not even portable on Windows. Sure, if you're making a game, you can expect your gamer audiences have it installed. If you're making an app and you expect businesses to use you it you'll find neither OpenGL nor Vulkan work on most business class machines view Remote Desktop. The point being, it's not portable by design nor in actuality

I would agree if Vulkan would be a good 3D API, but it turned out to be the worst of the modern 3D APIs because it repeats the same main mistake as GL:

There is no design vision, instead it's a cobbled together mess of adhoc vendor extensions that are eventually promoted to 'core'.

As expected, they don't touch the issue of how shaders work in PlayStation (LibGNM, LibGNMX) and Switch (NVN).

I’d very much like to read about Blade, but seems like they have literally no documentation in text format, not even a basic introduction. Every link on the GitHub page goes to YouTube.

Project authors, please don’t do this. It’s impossible to get a two-minute overview from a video. Browsing through tutorials and documentation is much more efficient.

If you really have never written anything about the project except conference slides, then at least put up that deck in addition to the YouTube link. Clicking through slides is not great, but it’s still a better browsing experience than seeking at random in a video.

Imagine the outcry if every game came with a background process that just sits there in the background.

Also - and this may sound a little bonkers - some renderers are so complex and flexible that the actual set of required shaders is only discovered when it tries to render a frame and the full set of possible shader configuration permutations is so large that compiling them all in advance is pointless or borderline infeasible.

Steam actually shares compiled shaders between users with the same hardware / driver version, but only for Vulkan I believe.

A better approach is to drastically reduce the number of individual shaders. Having tens of thousands of shader variants is an unfortunate side effect of treating shaders as asset data, and building them with visual noodle-graph tools by artists. No game actually needs tens of thousands of shaders.

One alternative that many games choose is to do it on-demand which is felt as micro-stutters while you play but this is a poor choice for a competitive game like CoD.

We take a slightly different approach: we don't do any up-front in the launcher but do as much as possible on the level loading screen; it's not perfect though: due to the way some legacy code works we can't always anticipate all permutations ahead of time so you get the occasional micro-stutter as missing shaders are sent to the driver.

You can get away with being lazier with modern drivers because they will cache the compiled result for you (if you don't cache the pipeline state object yourself in DirectX 12) but on older DirectX drivers for Intel IGPs there wasn't a cache at all so the first 30 seconds after loading into a level would be very busy.

Because the input bytecode blobs that are passed into 3d APIs are only a gpu-vendor- and render-pipeline-agnostic bytecode format (eg SPIRV or DXBC) - this is not what's actually running on the GPU. There's a second compile step happening inside the driver which compiles into a proprietary "machine code" format, and specialized for a specific pipeline object. Normally that driver internal compile step is quite fast, but that doesn't matter if there's tens of thousands of shader variants.

The only reason I like WebGL and WebGPU is that they are the only 3D APIs where major players take managed language runtimes into consideration, because they can't do otherwise.

Had WebAssembly already been there without being forced to go through JavaScript for Web APIs, and most likely they would be C APIs where everyone and their dog are writing bindings insteads.

Now, it is pretty much a ChromeOS only API still, and only available across macOS, Android and Windows.

Safari and Firefox have it as preview, and who knows when it will ever it stable at a scale that doesn't require "Works best on Chrome" banners.

Support on GNU/Linux, even from Chrome, is pretty much not there, at least for something to use in production.

And then we have the whole drama that after 15 years, there are still no usable developer tools on browsers for 3D debugging, one is forced to either guess what rendering calls are from the browser or which are from the application, GPU printf debugging, or having a native version that can be plugged into Renderdoc or similar.

> Microsoft

With the switch to Chromium as browser engine, I don't think that Microsoft has any people working on WebGPU.