Basically all native libraries inevitably have bad or difficult to follow documentation like this, proprietary or open source. Vulkan is the exception as it's a standard so needs to be very clear so all stakeholders can implement it correctly.

Usually I find if you're using an open source library you need the whole source checked out for reference, better than proprietary libraries where you need to pay and sign an NDA to get that access or equivalent support.

▲

socalgal2 4 hours ago | parent | next [-]

Vulkan spec is missing tons of stuff. Implementers check they pass the conformance tests (tho those also miss stuff)

directx also has conformance tests.

The directx specs are arguably better in many ways than the vulkan specs. They go into bit level details how various math is required to work, especially in samplers

	▲	veltas 2 hours ago \| parent [-]
		I'm sure it misses stuff, but generally a 'spec' is better than a 'doc' for the reason that you need enough info to at least guess how a spec is implemented, whereas a doc can leave everything out and as long as the programmer has headers and some examples they can probably do 90% of what is needed.

▲

pjmlp 4 hours ago | parent | prev [-]

Extensions to Khronos standards are hardly that greatly documented.

A TXT dump of the proposal, with luck a sample from the GPU vendor, and that is all.

Vulkan was famously badly documented, one only has to go to LunarG yearly reports regarding community feedback on Vulkan, and related action points.

OpenGL 4.6 never has had a red book editon, Vulkan only had a red book for 1.0, OpenCL and SYSCL just have the PDF reference, not all Khronos APIs have a cheatsheeet PDF on Khronos site.

	▲	veltas 2 hours ago \| parent [-]
		And the red book isn't that good either.