News HDMI Forum rejects AMD's HDMI 2.1 open-source driver

[mitch074]

Don't be so sure. If the GPU implements bitstream decryption in hardware and has memory encryption of the frame buffer, even a hacked driver might not give you access to the unencrypted data, in any form.


This was true for a long time*, until it wasn't.

​

https://www.phoronix.com/news/NVIDIA-2023-Highlights​

​

It does exist! It just has taken a while to get off the ground. Don't tell me that even after seeing how much trouble Intel had with their dGPU driver, you still don't appreciate what a big undertaking it is to write one!

* That's assuming we don't count the Nouveau driver, which Nvidia didn't officially support.

The part Nvidia is open sourcing is the kernel-side part of the driver - not the user-side, which remains a proprietary blob. That part of the driver allows you to initialize the card, and set its display mode. Period.
All the rest (2D accel, OpenGL, Vulkan, NVenc etc.) is part of the userspace part of the driver, and that one is actually still a blob.
There are talks to port Nouveau (the reverse engineered, 100% community-made driver) to use that kernel-side module, and THAT would make for a fully open source Nvidia driver, but it would have the exact same problem AMD has.

 

[UnforcedERROR]

wait CEC is a feature? i always thought it was a bug 😏

You're telling me people have trouble with CEC?!

DisplayPort still lacks some features like audio return channel (ARC) and embedded ethernet.

ARC is the biggest single argument for why HDMI is useful in the TV space, and why HDMI still has a place at all. It's what simplifies setups, so it's understandable that HDMI would take precedence over DisplayPort. This is mostly what I meant when I mentioned audio earlier.

Of those, I think VRR, DSC, and SBTM are likely of interest to some Linux users.

All of these are of interest, I'd imagine. People love VRR, and anyone who's seen the good aspects of SBTM would advocate for it I'd imagine.

 

[bit_user]

The part Nvidia is open sourcing is the kernel-side part of the driver - not the user-side, which remains a proprietary blob. That part of the driver allows you to initialize the card, and set its display mode. Period.

No, that's a ridiculous oversimplification. If that's all it did, then it'd be pointless and could've been done much quicker.

The Mesa NVK userspace is being worked on, against their open source kernel driver. Maybe not by Nvidia, but the subject of this thread was open source GPU kernel drivers, and that's what Nvidia is doing.

As for the rest of their userspace, they're obviously not going to open source CUDA. Suffice to say that Nvidia is making progress from where it was, but not as open as either Intel or AMD (not on track to match them). I don't think we need to get sidetracked any further on this.

 

[williamcll]

It's a shame that TVs don't use DisplayPort though. If you want to use a tv as a monitor, you have to use HDMI.

But more and more TVs are supporting USB-C Alt DP

 

[mitch074]

No, that's a ridiculous oversimplification. If that's all it did, then it'd be pointless and could've been done much quicker.

The Mesa NVK userspace is being worked on, against their open source kernel driver. Maybe not by Nvidia, but the subject of this thread was open source GPU kernel drivers, and that's what Nvidia is doing.

As for the rest of their userspace, they're obviously not going to open source CUDA. Suffice to say that Nvidia is making progress from where it was, but not as open as either Intel or AMD (not on track to match them). I don't think we need to get sidetracked any further on this.

No, that's really all the kernel part of the driver is supposed to do, while providing a stable interface for user space to interact with the hardware. Considering how many hacks NVIDIA used before and how many were closed, actually building the DKMS part has become the most frustrating part of installing an NVIDIA card on Linux - every new kernel build breaks it. That NVK is using it is the only excuse they needed to have it accepted in the kernel. And that's good, mind you, as NVK can then be used to run ZINK. That leaves out vidéo acceleration and, yes, CUDA (maybe a port of ZLUDA can help?)
But, it still comes down to the fact that HDMI 2.whatev can't run fully on open source drivers and at this rate, NVIDIA users won't be better off either.
Displayport FTW.

 

[bit_user]

No, that's really all the kernel part of the driver is supposed to do, while providing a stable interface for user space to interact with the hardware.

I'm not saying it's as complex as Mesa, but you're seriously trivializing it!

As of 6 months ago, amdgpu was sitting at about 550k LoC, not counting blanks, comments, or headers (which are primarily full of constants). That makes it about 2% of the total kernel sources, including all other drivers!

https://www.phoronix.com/news/AMD-5-Million-Lines
​

 

[digitalgriffin]

That's not true. You can trademark a name & logo. Anyone who uses it without certification could be subject to litigation via trademark infringement.

As for how development of the standard is funded:

​

"While VESA does not charge any per-device royalty fees, VESA requires membership for access to said standards. The minimum cost is presently $5,000 (or $10,000 depending on Annual Corporate Sales Revenue) annually."​

​

Source: https://en.wikipedia.org/wiki/DisplayPort​

​

You do have a point about the TM. But I've seen some plenty shady white label HDMI switches and dock hubs out of China that don't conform. "Can handle dual 4k 120Hz output" my tail.

 

[spongiemaster]

I think the cheap ones are probably just passive DP++ adapters. In other words, the DisplayPort controller detects when you're using them and simply switches its output to HDMI. According to the DisplayPort Wikipedia page, most DP connectors support DP++ - even when not explicitly indicated.

​

DisplayPort - Wikipedia

en.wikipedia.org

​

Dual mode display port is part of the DP 1.3 spec which is 10 years old. Anything that's been bought remotely recently will work with the passive adapters.

 

[bit_user]

Dual mode display port is part of the DP 1.3 spec which is 10 years old. Anything that's been bought remotely recently will work with the passive adapters.

I think you're missing the point, which is that passive adapters will not allow people to bypass the limitations of HDMI 2.0, as many here have suggested adapters would! Once you plug in a passive adapter, the port effectively becomes a HDMI port and will be treated as such by the GPU and its driver.

 

[cyrusfox]

You apparently never saw conference rooms for design collaboration (like building cars and stuff) -- they have extremely high resolution, color fidelity, and I guess by now also refresh rate, requirements. But then, those are probably using Windows or Mac to begin with.

These generally have USB-C cables sticking out that are running DP through USB-C, enabling a bit of USB-PD as well as DP output to the monitors. This change is welcome as it also enables phones and tablets to seamlessly jump in and utilize the space as well. HDMI presence in these work collaboration spaces is shrinking.

 

[spongiemaster]

I think you're missing the point, which is that passive adapters will not allow people to bypass the limitations of HDMI 2.0, as many here have suggested adapters would! Once you plug in a passive adapter, the port effectively becomes a HDMI port and will be treated as such by the GPU and its driver.

Active adapters are $15 which still qualify as dirt cheap. I don't see why you are wasting time arguing this.

 

[bit_user]

Active adapters are $15 which still qualify as dirt cheap.

And if those actually handle DP 2.0 -> HDMI 2.1, that's quite good!

Here's one, but it's $30 (which I still consider reasonable, FWIW):

https://www.amazon.com/CalDigit-DisplayPort-Adapter-Refresh-Eyefinity/dp/B0BY3SW376/
​

I don't see why you are wasting time arguing this.

Because more than one poster suggested cheap adapters as a workaround, but it turns out they're probably not. I think it's important to be aware of that.

Before yesterday, I didn't even know what that DP++ logo meant, so I thought it was reasonable to expect at least one other person in this thread might not, either.

​

Note: the Wikipedia article claims many/most DisplayPort ports are capable of dual-mode, even if they don't use this logo!

 

[mitch074]

I'm not saying it's as complex as Mesa, but you're seriously trivializing it!

As of 6 months ago, amdgpu was sitting at about 550k LoC, not counting blanks, comments, or headers (which are primarily full of constants). That makes it about 2% of the total kernel sources, including all other drivers!

​

https://www.phoronix.com/news/AMD-5-Million-Lines​

​

... covering several generations of AMD hardware - GCN 1 to 5, including iGPUs, RDNA 1 to 3, CDNA too. This also covers the video encoder/decoder components for each, and the HDMI sound, etc. As AMD really opened all the specs for their hardware since GCN 1 (older µarch, from r300 to r700, are covered by the radeon driver, older ones were part of the ati driver that has been archived and taken out of tree).
Making a kernel-side module for pieces of hardware as complex as a modern GPU is WORDY ! With 10 of them, you can quickly rack the number of lines of code, especially since there isn't a whole lot of redundancy between each of them, and on top of that AMD did include some rather potent debugging tools, including hardware monitoring and sensors and even a firmware flasher : https://www.kernel.org/doc/html/latest/gpu/amdgpu/index.html
So it's a GOOD THING the kernel-side part of the driver only does the bare minimum to allow the kernel to display a console emulator, otherwise the kernel would be a bit of CPU and a truckload of GPU code !

 

[bit_user]

... covering several generations of AMD hardware - GCN 1 to 5, including iGPUs, RDNA 1 to 3, CDNA too. This also covers the video encoder/decoder components for each, and the HDMI sound, etc.

As much of it as the driver does, yes. It's still an apples-to-apples comparison vs. what the Nvidia driver should eventually do.

Making a kernel-side module for pieces of hardware as complex as a modern GPU is WORDY ! With 10 of them, you can quickly rack the number of lines of code, especially since there isn't a whole lot of redundancy between each of them,

It's not as if there's not lots of kernel infrastructure that the driver utilizes. Also, I'm sure the GPU has a single way to deal with the GPU's MMU, its PCIe controller, manage DMAs, etc. which should be shared between all parts of the driver.

on top of that AMD did include some rather potent debugging tools, including hardware monitoring and sensors and even a firmware flasher

Calling them "tools" is a slight misnomer. They're more like facilities, than what most people would consider a tool, I think.

I'm not sure why you're so defensive about this point. The fact is that Nvidia's open source driver is real! Yes, they're developing just the driver and not the juicy Mesa userspace or opening CUDA, etc. But, unless you have info to the contrary, I expect it to do everything one would normally expect a GPU driver to do.

Furthermore, this article & thread is about GPU drivers, not userspace or anything else. So, I consider discussion about the rest of it to be off-topic. Just my opinion, but I'm not going to discuss userspace any further.

 

[mitch074]

As much of it as the driver does, yes. It's still an apples-to-apples comparison vs. what the Nvidia driver should eventually do.


It's not as if there's not lots of kernel infrastructure that the driver utilizes. Also, I'm sure the GPU has a single way to deal with the GPU's MMU, its PCIe controller, manage DMAs, etc. which should be shared between all parts of the driver.


Calling them "tools" is a slight misnomer. They're more like facilities, than what most people would consider a tool, I think.

I'm not sure why you're so defensive about this point. The fact is that Nvidia's open source driver is real! Yes, they're developing just the driver and not the juicy Mesa userspace or opening CUDA, etc. But, unless you have info to the contrary, I expect it to do everything one would normally expect a GPU driver to do.

Furthermore, this article & thread is about GPU drivers, not userspace or anything else. So, I consider discussion about the rest of it to be off-topic. Just my opinion, but I'm not going to discuss userspace any further.

But it does ! I didn't agree with you when you said the kernel part was a driver, because when it comes to actual usability there isn't much in it, and it is only half a driver - most of the other half of what makes a driver isn't from Nvidia, and the way things work (and going back to the discussion) means that if AMD's solution was refused, Nvidia blob or not will not be able to implement HDMI 2.whatev on Linux either.
Intel is in exactly the same situation as AMD, and we'll see a bunch of Android non-upgradable, proprietary media centers with Android 2.whatev support - right at a time when we finally see more open source Linux drivers somewhat supported by the manufacturers instead of half-baked blobs that work with a single kernel build.
So, to me, it IS actually rather relevant - the HDMI forum sucks here.

 

[randyh121]

This is one of those things that through-no-fault-of-their-own advertently or inadvertently ends up holding back open source.

[Someone tries a Linux live CD] *Boots to black screen* "Well it works on Windows, so I don't want to use Linux. None of this junk works."

"But [thing x] works just fine on Windows or my Mac" Yes, but it's not that the driver makers could not figure out how to do it, didn't have the time to do it, etc etc.

"Well, it doesn't work." &%@##!

It's the continual fight against both the chicken and the egg at the same time. AMD are trying to "do the right thing" here. HDMI forum are plain and simply saboteurs. The industry is fraught with them from this standpoint.

As much as I hate to say it as an avid anti-AMD poster, you are right.
HDMI has always been the lead. But it's time for it to die. All AMD was trying to do was save it here.
HDMI forum dug their own grave.

 

[bit_user]

I didn't agree with you when you said the kernel part was a driver, because when it comes to actual usability there isn't much in it,

It's the same as AMD's. For graphics, AMD's driver depends on userspace (either Mesa or proprietary), just like Nvidia's.

And yes, AMD does still have proprietary userspace OpenGL & Vulkan components, in spite of the fact that open source options in Mesa also support it. Phoronix often speculates they're trying to kill off the proprietary OpenGL runtime, but it's still a thing, as of today.

Unlike Nvidia (i.e. CUDA), AMD does have open source compute userspace (is their proprietary PAL still supported?), though I do hope Rusticle will support Nvidia's open source driver.

if AMD's solution was refused, Nvidia blob or not will not be able to implement HDMI 2.whatev on Linux either.

Yes, unless Nvidia finds a way to wall off HDMI into a proprietary blob, its open source driver won't be able to support HDMI 2.1+, either.

 

[mitch074]

Yes, unless Nvidia finds a way to wall off HDMI into a proprietary blob, its open source driver won't be able to support HDMI 2.1+, either.

And that's unlikely, because AFAIK that was what AMD attempted to do and the HDMI forum refused - probably afraid that an open source kernel-space module might allow reverse-engineering of the "advanced" features of HDMI 2.whatev found inside a blob (running as a piece of encrypted firmware).
For now the impact is small because not many people actually watch 8K@60 fps and gamers can use DisplayPort, but I don't give it more than a couple months after a compelling use case appears for someone to unearth the specs one way or another.

 

[bit_user]

And that's unlikely, because AFAIK that was what AMD attempted to do and the HDMI forum refused - probably afraid that an open source kernel-space module might allow reverse-engineering of the "advanced" features of HDMI 2.whatev found inside a blob (running as a piece of encrypted firmware).

Well, they weren't barred from implementing it in a closed-source driver, which itself needn't be encrypted and is therefore subject to reverse-engineering.

Anyway, Linux has time on its side. Once the patents used in HDMI 2.1 expire, Linux will probably still be relevant and an open source driver could implement support for it then. Hopefully, the HDMI folks won't take that long to come to their senses, but I wouldn't bet on it.

I don't give it more than a couple months after a compelling use case appears for someone to unearth the specs one way or another.

That's going to have to live as a patch set that you'll need to apply to the latest driver and build, yourself. I'm sure AMD won't allow the upstream version of their driver to be patched with HDMI 2.1 support, since they're responsible for it and could be punished for allowing the patches to be merged.

 

[Sleepy_Hollowed]

DisplayPort still lacks some features like audio return channel (ARC) and embedded ethernet. I use ARC to get sound through my A/V receiver, when the TV is playing a video stream or over-the-air broadcast.

BTW, here are some of the features added in HDMI 2.1:

• Enhanced audio return channel (eARC)
• Variable Refresh Rate (VRR)
• Quick Media Switching (QMS)
• Quick Frame Transport (QFT)
• Auto Low Latency Mode (ALLM)
• Display Stream Compression (DSC)
• Source-Based Tone Mapping (SBTM)

Of those, I think VRR, DSC, and SBTM are likely of interest to some Linux users.

It’s very moot if the spec is not open to be implemented in drivers.

 

[bit_user]

It’s very moot if the spec is not open to be implemented in drivers.

This only affects the open source drivers. It doesn't affect closed source drivers, like we have on Windows and like some that are still available on Linux.

The spec is available to dues-paying members and implementing it requires they pay a royalty. That's how it's been for over 20 years, before any open source drivers existed for hardware that supported it. Even today, most of the devices with HDMI ports don't have open source drivers for them.

BTW, there are other examples of standards like this. For example, the MPEG-4 specs cost money (but not a membership) to access and implement.

 

[mitch074]

Well, they weren't barred from implementing it in a closed-source driver, which itself needn't be encrypted and is therefore subject to reverse-engineering.

Anyway, Linux has time on its side. Once the patents used in HDMI 2.1 expire, Linux will probably still be relevant and an open source driver could implement support for it then. Hopefully, the HDMI folks won't take that long to come to their senses, but I wouldn't bet on it.

True. But I wouldn't bet on it for at least half a decade or so - see the shenanigans around h.264.

That's going to have to live as a patch set that you'll need to apply to the latest driver and build, yourself. I'm sure AMD won't allow the upstream version of their driver to be patched with HDMI 2.1 support, since they're responsible for it and could be punished for allowing the patches to be merged.

I'm not so sure, because while AMD people are maintaining that part of the code, it wouldn't be the first time that a kernel module is able to handle several pieces of hardware another supports too - so if anyone made a new DRM component supporting the latest AMD hardware with HDMI 2.1 added, and it were accepted in kernel, it might just go through - after that, it's a matter of distros blacklisting this or that module depending on detected hardware, it could be marginal or it could be huge.
Anyway, it seems Nouveau might be able to support HDMI 2.1 because contrary to AMD, NVIDIA does HDMI support in an encrypted blob - https://www.phoronix.com/news/NVIDIA-Firmware-Blobs-HDMI-2.1
That still sucks on an openness level, but oh, well... We'll see what Intel does.