The Linux graphics stack in a nutshell, part 1

Posted Dec 21, 2023 11:16 UTC (Thu) by farnz (subscriber, #17727)
In reply to: The Linux graphics stack in a nutshell, part 1 by kolAflash
Parent article: The Linux graphics stack in a nutshell, part 1

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.