The Linux graphics stack in a nutshell, part 1

Posted Dec 19, 2023 22:27 UTC (Tue) by excors (subscriber, #95769)
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 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.