Hacker News Reader

> Vulkan is so painfully verbose in unnecessary ways, forcing you to be explicit about everything

It's my understanding that Vulkan (like Metal) has fundamentally different goals than OpenGL

OpenGL is like if the lowest-level programming language available on your OS was Java. Low-enough level to be fast-enough most of the time, and high-enough level to write application code with. When OpenGL was designed, it was common for eg. game developers to directly write OpenGL code as a part of their game

In today's world- we not only have higher-level libraries and APIs, but many eg. game developers use a game engine like Unity or Unreal and never touch the raw API. In this world, it makes sense to have that raw API be lower-level, so that the people maintaining the libraries and game engines can have more control and optimize those more deeply. Vulkan is the C to OpenGL's Java

(that's my understanding anyway; I've never been paid to do graphics programming)

I do graphics programming for Planimeter (https://github.com/Planimeter). Even when you use game engines, you still actually have to understand some OpenGL/Vulkan/DirectX/Metal level details.

If you understand one of the standards, the knowledge carries over to others.

Most game engines will abstract away shader attributes, but if you're not aware of how to define them, you're probably not writing them, either. So even if you're not touching glGetAttribLocation/vertex attribute APIs, you still actually have to know how to use them. Otherwise, the assumption is that you're only ever going to be able to use basic predefined rendering information exposed from the host game engine.

There's a bunch of other information like that which you have to be somewhat aware of once you step outside the bounds of "just draw this for me" with the host's default shaders.

OpenGL was an api cleanup of SGI IrisGL, a library wrapping configuration of their custom high performance graphics hardware. When the hardware techniques subsequently became more sophisticated and in particular programmable, so called shaders were a driving force in these more abstracted apis.

Shaders as concept are older than IrisGL actually, one of the first famous examples.

https://en.m.wikipedia.org/wiki/TMS34010

cool example!

The yardstick Vulkan is measured against shouldn't be OpenGL but D3D11 and Metal (even though Metal and Vulkan share a lot of common ideas which have their roots in modern GPU architectures, Metal is a lot more convenient to work with than Vulkan), and D3D10/11 introduced many of those ideas to graphics programmers already (like grouping related render states into immutable state objects).

> but many eg. game developers use a game engine like Unity or Unreal and never touch the raw API

3D APIs have a lot more uses than game development. Even though I'm also coming out of the game dev world and can understand the reasons, it is a real shame that game engine rendering engineers had so much influence in the design of modern 3D APIs, because it's hard to find a community that's more imprisoned in ivory towers of their own design ;)

Sane defaults tend to evolve over time with the hardware architectures so it's probably not a very good idea to encode these into the API.

A lot of what you request can be achieved by using Vulkan wrappers that simplifies these things without making the driver API more magic/implicit and regress back to the dx9/openGL style API's that mantle/vulkan/dx12 was made in opposition of.

I don't think Vulkan needs to specify hardware level defaults, but for instance, something all of the tutorials does is irrelevant: no one cares what your game engine information is. There's going to be a handful of major studios whose Vulkan metrics are going to be collected and vendors can study that data.

99% of tutorial readers are going to grab the first device exposed to them. On a system with a discrete GPU, which is what most people will want to use, they'll pick that. When it's not available, an integrated device will be exposed.

You will almost never need to actually query for more device information.

If you're working through a tutorial, you will almost never need to actually write your own validation layers.

etc.

Edit: A lot of these tutorials do things that you don't need to do simply because they read it from another tutorial! I seriously doubt everyone is actually reading the reference specification.

Yeah, this is easy to confirm. I've had a desktop with multiple GPUs in it for close to 10 years, and outside of Final Cut Pro and Motion, I haven't found a single app (definitely not any games) that would use both GPUs, even though they were there and waiting for data! I write my own code to use both of them and it screams. It's unfortunate that more developers don't use it. But it's certainly overkill for an intro tutorial to discuss it.

All of this to say: I fully agree. The Vulkan tutorials I've found have put me off ever trying to use it again. I'm sticking to Metal which is much easier to understand and a delight to use.

Developers have different use cases. I have a laptop with both an integrated and discrete GPU, and the primary app uses the discrete device, however the aux tools (scene editors) use the integrated device, best of both worlds and I’m grateful I have the option to choose the output device. Even legacy OpenGL allows this.

That's a fair statement but realize most graphics programmers don't do this. Many will attempt to minimize redraw to reduce power consumption, but most are not going to profile power consumption and consider integrated usage to further reduce power draw.

>Vulkan is so painfully verbose in unnecessary ways, forcing you to be explicit about everything, when in many cases, whole swaths of lines of code are unnecessary or the standard could have established sane defaults that match what actually happens in practice in the industry.

Seems like it’ll be a perfect match for rust then

In my experience, the patterns Rust makes explicit are usually worth reconsidering and replacing. Further, it makes other common patterns more compact than in other languages: e.g. `std::fs::read()` vs the abomination with ByteInputStream and IOReader or whatever from Java, and I believe C++ makes it non-trivial either

I mean I’d rather use default parameters and named arguments then make a dozen enums or macros and structs to pass into a function. Look at polars and bevy, rust makes things hideous. It’s a great language for writing rust and not actually making something.

I recently started that tutorial and this describes how I feel—thought it was just me being unready. The setup is very long and the explanation seems uneven oftentimes, such that getting an idea of what is going on and why has been challenging, to say the least. It is as though all of the setup and configuration is the point of the tutorial and Vulkan itself.

I decided to contend myself with Web 3D APIs, even if I find them quite behind native ones, or stuff like Unreal/Unity when playing with native code.

Without middleware I would rather stick to a proprietary API than deal with Vulkan.

Vulkan is pretty close to proprietary too, after all it only really matters on Linux and Android ;)

Yeah, seen that way.

Pity that it misses out on the tooling from the other SDKs.