Vulkan Tutorial (Rust) | Hacker News Reader

Vulkan Tutorial (Rust)

kylemayes.github.io

180 pointsibobev33 comments

I'm glad that other people are still working on Vulkan documentation materials. Outside of just reading the specification, Overv's vulkan-tutorial.com is probably one of the most read Vulkan implementations in C++, but I have some minor complaints about it. And I hope this author considers making an improved tutorial, not just translating Overv's to Rust.

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.

Maybe I'm in the minority here, I'm sure I probably am, but I see no reason to declare particular structures in both the standard and in tutorial documentation like vulkan-tutorial.com when they widely aren't going to be of use to anyone until you reach broad adoption or advanced usage.

Most of these tutorials should be helping you get to a triangle as fast as possible, but none of them follow the order of what you're exposed to in the reference material, and they all go on tangents about needing to state application info (not required), creating your own validation layers (this is advanced material, why recreate VK_LAYER_KHRONOS_validation???) or declare what device you're going to use (it's almost always going to be the first exposed device--even systems with discrete GPUs will only declare that they have one GPU available and hide the fact that they have an integrated GPU on the CPU).

It leads to hundreds of lines of code that distract from the high-level goals: initialize the renderer, set your shaders, upload assets to the GPU, and draw them.

I think the industry is still lacking reference-quality documentation outside of the reference specification, which doesn't explicitly help you with implementation details for the most common use cases.

I wouldn't expect it to, but it would have been nice. A lot of modern reference specifications do actually do this now.

> 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.

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.

>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.

Slightly tangential, but for those who have gone through vulkan-tutorial.com and still felt lost even knowing a bit about basic graphics programming concepts, I highly recommend Brendan Galea's Youtube video series on Vulkan [1]. I'm about halfway through it and so far it has really tied together a lot of different concepts and cleared up a lot of my lingering confusion.

[1] https://www.youtube.com/@BrendanGalea/videos

For me, it was the "I Am Graphics And So Can You" [1] series, where author progresses from the similar concepts up to a working renderer for DOOM 3, linked in the intro of this article [2].

[1]: https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and...

[2]: https://github.com/DustinHLand/vkDOOM3

If you are just getting into graphics, also consider checking out wgpu https://github.com/gfx-rs/wgpu the Rust implementation of the WebGPU standard.

Conceptually it's the same as Vulkan it's just a lot less pain in the ass to work with.

Yes, that's one level up from Vulkan. You get abstraction over Vulkan, Apple's Metal (Apple just had to be different), and DX12, although Windows land supports Vulkan. Plus WebGL and Android support. Big win.

I believe the Metal project was underway for a couple years before the Vulkan project began.

> Apple's Metal (Apple just had to be different)

In their defense, Metal predates Vulkan by a couple of years and I would say that Metal jump started the new generation of GPU APIs.

I would say Mantle jump started the new generation of GPU APIs. Not sure if it predates Metal’s development.

That sounds like typical Apple fan rewriting of history to me. Metal was barely relevant to any 3D acceleration conversation at the time the Mandle/VK/DX12 conversations and planning was being had. Apple platforms just weren't all that important for this industry and console experience from Xbox 360/PS3/Nintendo shaped requirements much more.

Apple, Sony, Nintendo, Microsoft.

Metal also predates the nice present of AMD's Mantle to Khronos, which otherwise would still be arguing today what OpenGL vNext would look like.

I assumed that that abstraction meant that you lost some of Vulkan's flexibility/features. Is this not the case?

Yes, but wgpu is more than fine for 99% of use cases.

I have spent the last week working on an off screen rendering tool using Vulkan and Rust.

I’d highly recommend using vulkano

https://vulkano.rs/

It’s not stable but it’s useable. It’s actively developed. It’s quite a joy to use actually, feels like a rust library rather than a bunch of foreign function calls.

When it's Rust, I upvote.

But to the point, would this open OpenGL with Rust libs to be a new entry in the ML development space?

Reply on news.ycombinator.com