> I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret.

Yes, I'd not argue with that, I also never wanted or implied that I shall be able to get said keys from the card.

AMD/ATI back in the day said that, they have intentionally coupled video decoders, related logic and HDCP to same IP block for performance and silicon real-estate reasons, but in order to keep their promises about open drivers and accessible hardware, starting with (then) next generation silicon, they'll move all HDCP stuff to another IP. In turn, they will allow unfettered access to all GPU including 3D and video related features sans HDCP. However, with that architecture, even open drivers can use HDCP related hardware and functions without compromising the security and licensing around it, as a result allowing identical experience and freedom (from a developer standpoint) regardless of the driver used.

This is something to praise for, IMHO.

I still don't really understand how this is relevant for the drivers. Even if HDCP is part of another IP block, that doesn't mean open drivers can't use it. That's just an implementation detail. You can use HDCP on any platform the same way the proprietary drivers would (if you implement the right knobs to control it). Do you have a reference with more detail?

Ultimately the open driver should always be able to do all the same things the closed driver does and get the same result. If there are any secrets in the closed driver that "can't" be exposed, that's a security flaw in the design.

In their previous setup, as per their word, it was impossible to access video decoders and related machinery without exposing some HDCP stuff, incl. the key related storage and other secret stuff.

So, they were unable to provide the access they wanted to provide (for video decoders, at least), on the previous (then current) architecture.

That's... very weird. What would that expose? If you can read the keys at all from the OS, directly or indirectly, that's a security flaw. AFAIK AMD GPUs have supported video decode on Linux across all generations, so what was unavailable?

Considering the history of ATI with video, and how they enabled GL shaders to work with video acceleration, post processing and effects before anyone was able to dream this thing (Readeon 8500 was able to use shaders to post-process and apply effects to the video), I think their silicon layout was very convoluted and unconventional for today's standards.

Considering HDCP came later, it might have just been slapped as a side module and some of their math magic might be offloaded to GPU even. I remember having old ATI drivers having a very cinematic look when video was accelerated by the GPU itself (it was surreally beautiful), but they had to throw all this machinery out from the driver when they started to modernize their stack (and they broke video playback for months due to not supporting proper overlay formats).

Similarly, I think closed source drivers were programming some of the cards during initialization, because I remember they're talking about moving all this init step to the BIOS itself, and opening some doors on the BIOS to tweak the card during the init (clocks, fans, temp reads, etc. IIRC) for allowing OS and open drivers to play nicer and with less effort with the cards in the long run.

The details are hazy, because these transitions were made almost a decade ago if not longer. However, while NVIDIA was playing the deaf, and Intel was just starting to provide good open drivers for their IGPs, AMDs move as a prime GPU vendor brought a lot of good light to them.

If you want, I can try to dig the history and create a timeline for you, but it might not be an immediate endeavor.

Oh, I know that AMD has done a lot to help out the open ecosystem (and even interop with the closed parts - heck, I got their closed AMDGPU-PRO Linux drivers to work on the PS4 without any patches, even though that's not a GPU variant offered elsewhere, because the amdgpu userspace/kernel interface is just so well designed). I recommend AMD for Linux users; lately, they've been doing good work while Intel drivers bitrot, especially on older hardware.

I'm just quite confused as to how HDCP factors into all that. HDCP really is just a hardware block that's part of the video output which you enable or disable; there is a bunch of nonsense associated with PAVP and other such stuff on Windows, but none of that should really matter to Linux, nor should whatever way HDCP is implemented affect other features of the open drivers. AMD certainly do deserve credit for their work on Linux support, I just find your specific HDCP story quite strange :-)