Documentation is ONE PART. It says what the design was supposed to be like.
Then you have errata and variations - when some of the hardware doesn't correspond to the documentation and acts differently.
Then you have examples - where someone shows you how to, e.g. draw a simple triangle using the documented opcodes and all of the boilerplate and set up necessary.
And then you have actual working code. Where you give away, for example, a complete implementation that conforms to a higher, standardised API and issues instructions to the hardware to perform those actions.
Out of all of those, documentation is the easiest thing to do. You can just (for example, just flicked through a PDF from that site) say that instruction X transposes a matrix. No idea of performance, whether that's the recommended way, what it contends with, how it works, whether the Intel drivers use that themselves, whether it's a legacy function, whether it has huge constraints on its use.
Without some code, it's all just fancy tech sheets. Sure, better than nothing, but a long way from actual co-operation. I'm not saying Intel don't co-operate in other areas, but documentation like this? That's the "quick reference" stuff for when your thousands of lines of existing example code don't act like you expect when you tweak them and you look up what that operand is supposed to do and how.
Put a hardware driver author in front of a documentation pack and a compiler, and tell him to write a driver, and he'll tell you to fuck off.
Put a hardware driver author in front of many working examples of device, with debug-level access, with example source (that he can't just copy due to licensing), errata, a direct line to cooperative hardware engineers AND this documentation and he'll start.
This is why I've never been that bothered by documentation releases, or even unmaintained source-drops. Supposedly Broadcom did something similar for the RPi's graphics chips. I think we're still waiting on anything that's not a binary driver there. And we have this sort of stuff for some ancient 3D graphics cards - it's just not as easy as reading it all and then sitting down to write a driver.
Intel, nVidia, ATI: Give us drivers with code that have no reliance on "black box" information/code, and we'll be happy. Until then, it's just lip-service. And you know that. That's why you don't release this kind of stuff for graphics chips, and nor does anyone else. Because you can drop this in someone's lap and years later STILL end up being pestered to the ends of the earth for an open-source driver (or assistance to help write one) because it doesn't exist.
Code is a lot more than writing things to perform a protocol described in the documentation. If only it were that easy.
It's been a few years since I worked in hardware, but even when you build it for a commercial company; not open source, you don't get the things you (poster) think are important.
In the past I found AMD far more helpful than Intel, and I was building high end workstations then (Motorola and MIPS based, but lots of AMD chips). MIPS and AMD at least gave you the documentation for free if they thought you were serious: that was LOTS of thick books. Sometimes they helpd you figure out if things didn't work properly.
If you are in a small company, even when you buy a reference design kit you don't get any help. you have to work it out for yourself, even if there are some errata sheets. No properly working drivers for the reference design. No source.
These days I'm glad I have a little company in China making our boards, that while being a bit clumsy are very fast to fix things. Things get broken as quickly.
I'm even more glad that there are less complier bugs than I had to deal with on Microsoft compliers, or GNU on obscure ARM architectures I tore my hair out over.
Luckily I have a lot of hair.