With a quick Google search, I found no results, so I came here to ask: How is Vulkan implemented? Even on older Intel APUs. I have a 2014 laptop (Intel APU only) and using open source graphics, how magically can I now run Vulkan without buying a 2016+ video card.
I know Vulkan was meant to be the lowest level (like C) of graphics, but where does that come from? Does OpenGL read Vulkan, is Vulkan right on the hidden side called OpenGL or does it run like an old arcade game machine but using a video card?
Vulkan is an API specification.
IHVs develop the drivers conformant to the specification. On Linuxes various contributors also do it in Mesa project.
Firstly some factors that helped quick and wide deployment:
the spec needs several drivers to know it covers pragmatic concerns, not just being decided by comitee (or dictator) from thin air. So there would be drivers for HW older than 2016 (i.e. public release of the specification)
GPU architectures change incrementally. So it is not so hard to backport from architecture rehash to older architectures (e.g. across GCN architecture versions)
Vulkan API is thin and requires little at minimal configuration; unoptimized minimal driver could be made relatively fast
NV and AMD seem to want it to succeed. Both update regularly, and cover old enough GPUs. Meanwhile major Engines also seem to like it.
Not the lowest. Just lowest common abstraction (like C); or at least that’s the aspiration. It has its own problems to negotiate the API (e.g. I am somwhat annoyed you cannot work with a carry bit of a CPU in pure C; I can only hope the compiler does the right thingTM for me).
Not quite how things work. A GPU has ISA, which is unlike Vulkan, OpenGL, DirectX or whatever. And it is a device to which you talked with a mapped memory, and maybe some interupt requests (which is the “actual” driver you would see e.g. in Windows Device Manager). E.g., BS example, if you want your device to make an operation O, you would write 0x42 to address 0x1337, then you would read address 0x1338 by which the device tells you it accepted the operation. The Vulkan “driver” translates your code in this sane API, to whatever protocol the device uses.
OpenGL does the same thing, except that it is less explicit API than Vulkan. That only means that more stuff is hidden as implementation detail from you, and you cannot be sure what given OpenGL command will cause. E.g. glCreateBuffer will allocate memory, or reuse memory, or schedule allocating memory for later when you actually use the buffer, or whatever it feels like, and it can choose whichever memory it feels like. The API contract is only that you get a buffer handle that you are allowed to use in OpenGL. Meanwhile this is explicit in Vulkan. You allocate the Buffer yourself directly, and choose when that happens, and what kind of memory it is supposed to use.