The Linux graphics stack in a nutshell, part 1

Posted Dec 19, 2023 20:06 UTC (Tue) by randomguy3 (subscriber, #71063)
In reply to: The Linux graphics stack in a nutshell, part 1 by adobriyan
Parent article: The Linux graphics stack in a nutshell, part 1

the impression i've always had is that direct application use isn't what vulkan was designed for - and as such, how complex it is to use in that way isn't really an interesting statement on whether it is a "good" api or not

the way i understand it, it would be a bit like complaining that it's hard to program in LLVM's intermediate representation - sure, but what did you expect?

The Linux graphics stack in a nutshell, part 1

Posted Dec 19, 2023 20:17 UTC (Tue) by adobriyan (subscriber, #30858) [Link] (6 responses)

Yeah, I've heard that everyone should be using some kind of 3d engine.

But who is going to write 3d engine if everyone should be using one?

My comment is a warning for the uninitiated.

The Linux graphics stack in a nutshell, part 1

Posted Dec 19, 2023 22:27 UTC (Tue) by excors (subscriber, #95769) [Link] (5 responses)

The engines would be written by the same kind of people who write OpenGL engines. Those people would likely also take a large fraction of 1000 LOC to draw a single triangle in OpenGL, because they'd draw it with VBOs and VAOs and UBOs and MultiDrawIndirect and whatever, since that's the modern high-performance dialect of OpenGL.

I think most of the verbosity of Vulkan is because it exposes the complex architecture of modern GPUs; but if you're trying to write a decent engine in OpenGL then you'll have to use various OpenGL features and extensions that similarly expose the architecture of modern GPUs, so there's not so much difference. There is a big difference in learning curves though: you need to learn quite a lot about how GPUs work before drawing that first triangle in Vulkan (but then you can steadily progress to rendering many more triangles), whereas OpenGL provides many shortcuts so you can get something onto the screen quickly (and then rewrite your code several times as you learn new concepts and realise those shortcuts were actually traps).

The Linux graphics stack in a nutshell, part 1

Posted Dec 20, 2023 12:55 UTC (Wed) by Sesse (subscriber, #53779) [Link] (1 responses)

Creating a VAO, a VBO, some shaders and generally what you need to draw a triangle in modern OpenGL (4.6, core profile) is more like 100 lines. Not 1000.

AFAIU, Khronos intended for there to be some sort of middle layer for those who didn't want to use a full engine, but it never really materialized. The situation is pretty atrocious, and it means we can basically never kill OpenGL even though it doesn't get any new features.

The Linux graphics stack in a nutshell, part 1

Posted Dec 20, 2023 14:26 UTC (Wed) by pta2002 (guest, #168664) [Link]

I would say it has actually materialized now though, in the form of WebGPU! It's a much nicer abstraction over Vulkan (or DX12, or Metal, depending on the OS, which are basically the same as Vulkan capability-wise), and despite the name doesn't really have to be used from the web. Namely, you can use it from most programming languages and bind to the WebGPU engines from either Chromium (dawn, written in C++) or Firefox (wgpu, written in Rust), and it'll just... work, mostly everywhere.

WebGPU's API, from what people seem to say, is basically identical to Apple's Metal, which most people also seem to agree is the nicest of the three, and massively reduces the boilerplate.

Took a bit, but I think we finally do have the graphics API to rule them all now :)

The Linux graphics stack in a nutshell, part 1

Posted Dec 20, 2023 16:32 UTC (Wed) by kolAflash (subscriber, #168136) [Link] (2 responses)

Regarding:
> I think most of the verbosity of Vulkan is because it exposes the complex architecture of modern GPUs;

Hmm. Sounds like there's a higher risk, that outdated Vulkan applications might not run on newer GPUs. At least higher than it is with OpenGL or WebGL.
Is that correct?

The Linux graphics stack in a nutshell, part 1

Posted Dec 21, 2023 5:50 UTC (Thu) by joib (subscriber, #8541) [Link]

Well, if future GPU architecture turns out to be drastically different from contemporary GPU, sure, there might be a lot of impedance mismatch between Vulkan and the HW.

Then again, it's hard to imagine OpenGL with all its implicit state and fundamentally single threaded architecture, being a particularly good match to any conceivable future GPU architecture either, despite being a somewhat higher level interface than Vulkan.

The Linux graphics stack in a nutshell, part 1

Posted Dec 21, 2023 11:16 UTC (Thu) by farnz (subscriber, #17727) [Link]

Not really. OpenGL comes from an era where the GPU was expected to have a lot of stateful, fixed-function hardware, and thus the only way to program it was to set the state in registers and trigger the hardware to do its thing. That's not the current direction of travel for any form of compute, and hasn't been for a long time, and we have emulated this model by having all the state live in software that sends GPU programs over to the GPU to execute.

Vulkan's underlying model is of multiple execution engines processing queues of commands, where the state for each engine is stored in a block of memory, and the execution engine is responsible for managing state changes when the state pointer is changed. This is a common model for compute acceleration hardware like GPUs, because it's trivial to context-switch; change the state pointer associated with the engine, and you've changed contexts. And in practice, this also works well if your hardware is designed to be stateless; when you submit a block of work to the hardware, you include the necessary state from a software copy.

Further, Vulkan's model works well if the GPU is a shared resource; you submit work in batches, and can wait for a batch to complete; the underlying drivers and hardware can choose which batches to execute when. The OpenGL model doesn't work in this case; you are expected to claim the hardware, do your graphics stuff, release the hardware.

The Linux graphics stack in a nutshell, part 1

Posted Dec 19, 2023 20:18 UTC (Tue) by randomguy3 (subscriber, #71063) [Link]

to clarify my previous comment, i have have always understood vulkan to be basically designed as the lowest level cross-hardware interface (hence the comparison to LLVM's intermediate representation), with the assumption that you build frameworks on top of it (whether that's opengl as zink does, or a game engine, or a gui toolkit), and you do all the interesting stuff using those frameworks

The Linux graphics stack in a nutshell, part 1

Posted Dec 19, 2023 22:14 UTC (Tue) by atnot (subscriber, #124910) [Link] (1 responses)

> the way i understand it, it would be a bit like complaining that it's hard to program in LLVM's intermediate representation - sure, but what did you expect?

I don't think this is a perfect analogy. Vulkan is actually pretty fine to program it once you've got it set up. There is just a lot to configure, because it turns out that displaying a triangle on a screen is actually an incredibly complex task. The beauty of GPUs and the Vulkan API compared to it's predecessors is that once you've done all of that work to set things up, displaying a single triangle is about as hard as displaying a billion triangles. Once you've got a triangle, it's up to you what you want to fill your buffers with.

It kind of actually is like LLVM IR in that respect actually. Making a code generator that outputs the basic arithmetic instructions and control flow is a lot of work. But once you've got that, it's 90% of what you'll ever need.

The Linux graphics stack in a nutshell, part 1

Posted Dec 20, 2023 9:41 UTC (Wed) by WolfWings (subscriber, #56790) [Link]

Yeah I've written some code directly in WASM bytecode before because what I needed was so small it was faster to just... bang out the three dozen instructions directly into a file somewhere than setup a whole whatever-to-WASM compiler for the web project.

Vulkan is nothing like that or LLVM intermediate, it's just... not hiding ANY complexity. It's like writing code for a PSX era hardware where you literally have to track EVERYTHING.

Useful levels above Vulkan

Posted Dec 20, 2023 1:11 UTC (Wed) by animats (guest, #168630) [Link] (1 responses)

Few code directly to Vulkan.

I use Rend3/WGPU. WGPU is an abstraction layer which supports Vulkan, Direct-X 11 and 12, and Apple's Metal. This is a standard 3D graphics library for Rust.

Above that, you have a choice of game engines and libraries. Godot is widely used for C++ game dev. There's Bevy, for Rust game dev, and the somewhat bleeding edge Rend3, which offers a clean, safe interface for Rust 3D graphics but is not a full game engine. All open source, of course.

Here's some video generated with Rend3, running on Ubuntu Linux 22.04.3 LTS with an NVidia 3070 GPU.

https://video.hardlimit.com/w/tp9mLAQoHaFR32YAVKVDrz

Useful levels above Vulkan

Posted Dec 20, 2023 16:29 UTC (Wed) by kolAflash (subscriber, #168136) [Link]

The Antarctica engine from SuperTuxKart-1.4 also has initial Vulkan support. So I guess it can also be used for building arbitrary Vulkan applications.
https://www.phoronix.com/news/SuperTuxKart-1.4
And there are a lot of commercial engines with Vulkan support like Unity3D or the Unreal Engine.