Hacker News Reader

Comment by Ciantic | Hacker News Reader

> is so low level that differences between AMD and nVidia GPUs are exposed.

I interpreted it quite differently, the author writes:

> there's just less knobs in general. Almost all the magic you want to do is done with shaders. Since these GPU APIs have a little programming language of their own, the GPU API itself doesn't have to be super powerful. It can be small, designed to exactly how one would control the hardware efficiently, and the programmer has tons of freedom, because they can get buck-wild in a shader with almost no limits.

Which to me implies the Vulkan API is so simple, and close to metal, that it doesn't differ between implementations.

View on HN

> Which to me implies the Vulkan API is so simple, and close to metal, that it doesn't differ between implementations

As someone with 20 years 3D programming experience including paid work in DirectX and OpenGL ES 2.0, I attempted vulkantutorial.com but gave up because it is too hard. It really is 1000 lines of C/C++ to even get a flat shaded triangle on screen. Vulkan has validation layers to help with writing conformant portable code, but the validation layers are written by your GPU manufacturer and so you can get things that pass on an Intel GPU but fail on nVidia. If you've ever tried porting your "portable" ISO C++ code that works with GCC over to Visual C++ and dealt with 1000s of lines of compiler errors it's kinda the same thing. Vulkan has shaders that precompile to "portable" bytecode but I also noticed that the time delay of loading these "precompiled" bytecode shaders was instant on one Intel GPU but took about 5 seconds on an nVidia GPU. The nVidia driver then cached the results (I know not where) so that subsequent runs were faster, but the cache can be invalidated by either a driver update or a shader update, so your game level loader will need an "ifShaderLoadingSlowerThanMolasses() {...}" code path to deal with your users experiencing slow load times after a video card driver update, etc.

Summary: in ages past it was possible for mere mortals to write visualizations and simple games directly in OpenGL/DirectX, but with Vulkan most of us will need a middleware layer on top of it to get anything done within a deadline. If you want an open source portable solution I instead recommend Godot. If you want to make a 3D game that makes millions of dollars with less than 3 years of development and can deploy to Nintendos and Playstations with a button click I recommend Unreal Engine or Unity.

The funny thing is (mentioned briefly in the article) SDL just released a geometry API so pushing geometry to the renderer is easy now. Dear ImGui already updated their SDL renderer for it.

... apparently I was mistaken, this hasn't been released yet, it will be out with 2.0.18[0]

[0]https://github.com/libsdl-org/SDL/milestone/2

I'm not a 3D person or whatever, but is it possible to (asynchronously?) pre-compile shaders before you use them? Like, to run shader compilation behind the scenes while the user is playing the tutorial or whatever?

So there are two separate "pre-compile" steps with Vulkan: #1. Compiling shader source code to SPIR-V bytecode; #2. compiling SPIR-V bytecode to native GPU shader instructions. #2 is always done at runtime (though the vendor driver may silently use a cached previous run result), and yes, it is possible to do it async. But like you speculated, you have to figure out something for the user to do while this async compilation happens. In an open world 3D game this adds considerable complexity. If your hero is approaching the Ice Cave of Wonders you need to smoothly preload your fancy ice shaders before the cave mouth is in sight and this preload shouldn't make the current framerate drop. In simpler times past with simpler shaders (like OpenGL 2.1 / ES 2.0 GLSL) you could compile shaders from source in perhaps a single 1/60th second frame.

It's funny how 1980s Nintendo cartridges loaded instantly but now that we have hardware at least 10 million times faster we have long load times for games.

Couldn’t #2 shaders be compiled once and shared between users? A game could compile them on first run, submit them to a server with a unique hash of the OS, driver and shader version (and what else). Then other users could download the already compiled shaders if there’s a network connection. If not, you simply compile them anyway.

If security is an issue (can a shaders be dangerous?) you could wait until you have X copies of the same hash and verify that they all have compiled to the same code before adding it to the online cache.

Developers could even pre-compute such shaders for popular GPUs that they have access to.

Steam already does that automatically.

Exactly, in the age of middleware sticking with the broken designs of Khronos, is a waste of time except for the platforms where we cannot avoid it.

And WGSL seems to be going the way of Vulkan in what concerns shading languages, taking the fun out of playing around with WebGPU.

> the validation layers are written by your GPU manufacturer

What? I mean they could write extra ones, anyone could, but The Main Official Pack Of Validation Layers™ is maintained by Khronos:

https://github.com/KhronosGroup/Vulkan-ValidationLayers

The Vulkan API does not change between Intel, AMD, NVidia and MoltenVK (iOS/macos) GPUs.

What the grandparent is saying though is "that differences between AMD and nVidia GPUs are exposed." Vulkan is so low-level that your application needs to implement workarounds for each GPU's quirks.

OpenGL was high level enough that if you didn't care too much about raw speed, the only place you got into the weeds of GPU quirks was writing your shaders. With Vulkan, the weeds of GPU quirks pop up everywhere.

It surely does, because the Vulkan API is a bare bones loader for extension spaghetti, where the first thing an application is supposed to do is to load the extensions required for the application.

Reply on news.ycombinator.com