Vulkan update: version 1.2 conformance for Raspberry Pi 4

When OpenGL was designed, the thinking was that graphics programming is hard, and so the API should do the heavy lifting and make the application's job easy. It turns out, though, that graphics programming is so hard that the majority of folk tend to use even higher level graphics libraries to write their applications.

The folk writing those graphics libraries want to make their libraries as optimally performant as possible, and the abstract nature of the OpenGL API stands in the way of doing that. They would rather just directly access the hardware. Vulkan is an API that gives that direct access, within the limitations of running in an unprivileged userspace process.

OpenGL holds a lot of implicit state in the driver. This makes writing your code a lot easier as you don't have to track all that state yourself. If you want to learn 3D graphics, I'd either start with OpenGL or some "engine" that makes an abstraction that looks a lot like OpenGL.

The problem is that OpenGL state is implicit. Every driver does it differently and there is no way to get at the state via OpenGL. This becomes an issue when you want to optimize--either for maximum performance or for maximum battery life.

Vulkan, on the other hand, makes EVERYTHING explicit. This means that every single transition, barrier, matrix change, byte transfer, etc. is all in your hands. You know exactly what is going on because you have to specify it exactly. But don't get it wrong or your pixels will get eaten by a grue. This is precisely what you want when you absolutely need to optimize your graphics, but, man, is it painful to get right.

One side benefit of the explicit nature of Vulkan carries over to concurrency. Vulkan can actually do multithreading--OpenGL has no hope because of all its implicit state.

Vulkan fixes that by stripping these problematic higher-level abstraction layers from the GL. Instead, Vulkan provides low-level access to the GPU hardware.

The triangles are still there usually, but the Vulkan has no GL-like high-level APIs to render them. Instead, in Vulkan we create and update GPU buffers and textures with the source data, create pipeline states (an object containing shaders, input layout, alpha blending, and quite a few other relevant parameters), and finally submit draw calls rendering triangles from buffers, using some pipeline state.

It's not actually “closer” to the hardware than OpenGL was though, it's just an attempt to define a more predictable abstraction. The underlying architecture of two Vulkan GPUs can be wildly different.

modern graphics hardware does not work well in this model. they’re really much closer to whole other systems. you want to push the triangle data into the card in a single (or few) API calls, then submit as few draw calls as you can manage.

fun fact, OpenGL 3, originally code named “longs peak”, was supposed to upend the stateful model, and advance the API ahead of its proprietary counter part(s) - DirectX. for what ever reason this completely fell apart, and OpenGL just sort of.. stopped improving :/

we have Vulkan now basically thanks to AMD opening their more modern GPU oriented Mantle API, and valve for running with it.

Both entertaining and (very) insightful; one of my favorites ever :)

It can't be summarized, although the most significant quote probably is:

> Nearly every game ships broken. We're talking major AAA titles from vendors who are everyday names in the industry.

It’s one of the reasons OpenWRT has poor support for Broadcom SoCs and Broadcom WiFi-controllers, and in general Broadcom-based devices are shunned in the OpenWRT community.

It seems to be a company-wide thing.

Also, as the article mentions, there's a fork of Android that runs on a Raspberry Pi, and there are already Android games that will take advantage of Vulkan 1.2 support.

Also probably Android games.