Display Stream Compression (DSC) support

[edisionnano]

DSC allows people to drive 4k/240hz and 8k/60hz displays with DP 1.4 and HDMI 2.1. The NVIDIA driver for Windows supports this however the Linux one doesn't. Many people in the Linux Gaming community want this and moving into the future 8K or high refresh rate 4k will become more common for movies or gaming. Linux is a great choice for building a media center pc and nvidia cards are best in class for decoding video such as 8k60 so such a feature would be more than welcome

[aritger]

Yes, thanks. The Linux driver in general does support DSC, but not yet at the higher rates that you're referring to. I don't have an ETA for that, but we know it is an important feature that many people are asking for. Thanks.

[robertswiecki]

One of the real-world examples where it's needed are 5120x1440@240Hz monitors like Samsung Odyssey (neo) G9, which seems to be moderately popular among gamers.

[Evernow]

Yes, thanks. The Linux driver in general does support DSC, but not yet at the higher rates that you're referring to. I don't have an ETA for that, but we know it is an important feature that many people are asking for. Thanks.

Thank you for confirming this.

[dragonifnotifiswat]

Just bought a 3080, while I dual boot into windows for some games I'm kinda disappointed this was not supported.
Yes I don't necessarily game on Linux its still nice to have that extra refresh rate for overall smoothness.

[robertswiecki]

Hi Nvidia folks.

The lack of DSC support in Unix drivers is problematic at this point. More and more display require it ti use their full spectrum of modes: 5120x1440@240Hz (Samsung Odyssey G9 (Neo)), 4k@>120Hz (Acer XB323K, Samsung Neo G8, Samsung Ark, Sony Inzone M9, Acer X32 FP, Samsung Neo G7, HP Omen 32u).

[3dpt]

Thank you for your answer @aritger . Also have an Odyssey G9, and I have kept Windows separately for this reason. It was also buggy and took a long time to solve on Windows, both from Samsung and from NVIDIA, but it was eventually sorted. At least bring us some kind of compatibility with DSC at these refresh rates (which are quite common nowadays). AMD at least gives the option to set the resolution and refresh rate. There is visual noise and artifacts but people found a way to solve it. At least give us the option. Thank you.

PS: Is there any kind of ETA since this is a problem with over 2 years now?

[aritger]

Yes, we definitely appreciate the priority of this. We're trying to get this support in place for our 530.xx release series, but dates are always in flux, so I can't give a firm ETA.

[rakuri255]

@3dpt & @aritger But the problem is still not solved on Windows. The dsc always crashes when you have a full screen app/game and a windows popup appears. Especially the samsung g9 goes black.

[3dpt]

@rakuri255 I used to have that problem in Windows as well when I bought my G9. What firmware are you on? Check the monitor firmware version, update to newest version, and check if you have newest nvidia drivers available. Make sure you uninstall previous drivers (you can use Display Driver Uninstaller for this). I can guarantee that the problem is solved in Windows, and has been for a few years now. If you have that problem with newest monitor firmware and graphics drivers, you can check online if there are other fixes, but in the meantime, you can contact Samsung, as you might have a defective unit.

[rakuri255]

@3dpt thanks for the help! The G9 is up to date. I tried a few driver versions and found that the problem has been occurring since version 526.47. I am now using the older version 522.25 where it currently works.

[Drostina]

I also have a G9 Odyssey, which I have had since release and never have been able to use the 240hz 5120x1440 side of it. Very interested to see this implemented

[rakuri255]

It works sometimes on my neo g9. But when you get an popup in win11 (like the volume bar) it crashes and goes black screen.

[khris190]

It works sometimes on my neo g9. But when you get an popup in win11 (like the volume bar) it crashes and goes black screen.

You might be in the wrong repo my dud

[rakuri255]

Yeah i seen that to late :D

[SamSanai]

I also have a G9 Odyssey, which I have had since release and never have been able to use the 240hz 5120x1440 side of it. Very interested to see this implemented

Same here. Would love to see that implemented

[galister]

Not having DSC also prevents the majority of modern VR headsets from running on their native resolutions. With SteamVR being usable on Linux, it's actually an issue now.

[nosachamos]

With 8k monitors coming in 2023,, would be great to see this released... we cannot expect people to use 8k in 30hz, specially with these monitors costing as much as they will cost. 8k @ 60hz is a must for basic productivity.

[olealgoritme]

Not having DSC also prevents the majority of modern VR headsets from running on their native resolutions. With SteamVR being usable on Linux, it's actually an issue now.

NVIDIA have still not released necessary drivers to support high pixel clock modes for DSC. It's been years, and still nothing. What a complete joke.

[dllu]

I've had an 8K display (Samsung QN800A) for almost two years now and still stuck on 30 Hz haha. In fact, an 8K display is not that expensive nowadays, you can get one for $2000. It's like having four 4K displays in a grid, it's amazing for looking at terminals. But I am excited about driver version 530 which will hopefully finally enable 60 Hz.

[guillaumevds]

Hi all,

Any update on this implementation ?
It's been working for ages on Windows and I didn't even know it would not be implemented on Linux.
Not knowing that I bought an ultra wide display for productivity. It's better than the old HD display I used to work with but I'm stuck with that low refresh rate unfortunately, and I can definitely perceive it.

Hey, nvidia, please prioritize this, please :-)

Cheers!

[aritger]

I apologize again for the delays in delivering this. This is still prioritized and receiving engineering attention. Unfortunately, I do not have an ETA at this time. Thanks for your patience.

[3dpt]

Without giving an ETA, can you tell us if this feature is still planned for 530.xx drivers, as you mentioned a few months ago, or if it is being pushed back further?
Thank you in advance for all your feedback regarding this issue.

Best regards,

[aritger]

We're working to provide this feature, but I can't say for certain whether it will be in 530.xx. Thanks again for your patience.

[ElRoberto538]

Well, looks like it didn't make the 530 drivers cut :( @aritger are you able to tell us if they have actually started work on it? Wondering if I sell my GPU and buy an AMD.

[Midar]

@ElRoberto538 You're always better off with AMD on Linux, so if you can switch, I'd highly recommend it. The situation will not get better, only worse: AMD is actively working on HDR support for Linux, so AMD cards will be among the first to support it. Meanwhile, NVIDIA on Linux is still struggling with the basics and far away from anything new that's a little more complex such as HDR. And if you want to use Wayland, well, then AMD is basically still your only option (plenty of applications still only render a black window, night mode etc. still don't work, etc.). And you can't even fix things yourself or implement new features, like with AMD, so if NVIDIA isn't working on the fixes/features you want, you're just out of luck.

// Edit: To be clear here, I am not blaming the engineers. This is a management problem at NVIDIA, which still does not prioritize Linux work.

[KickAssDave]

@ElRoberto538 You're always better off with AMD on Linux, so if you can switch, I'd highly recommend it. The situation will not get better, only worse: AMD is actively working on HDR support for Linux, so AMD cards will be among the first to support it. Meanwhile, NVIDIA on Linux is still struggling with the basics and far away from anything new that's a little more complex such as HDR. And if you want to use Wayland, well, then AMD is basically still your only option (plenty of applications still only render a black window, night mode etc. still don't work, etc.). And you can't even fix things yourself or implement new features, like with AMD, so if NVIDIA isn't working on the fixes/features you want, you're just out of luck.

// Edit: To be clear here, I am not blaming the engineers. This is a management problem at NVIDIA, which still does not prioritize Linux work.

Not sure why your comment was down-voted tbh. It's not going to taste well sitting on an nVidia related discussion, but it's definitely the truth.

Had I known a while back now how much I was going to get in to Linux I honestly wouldn't have bought my RTX 3090.

Is it nice to have the ability to run LLMs locally and all that jazz? Yeah it is... but the near constant frustrations I have had on Linux with Nvidia have cost me countless hours of problems.

In one case I had 2 separate Linux images on 2 USBs, and I couldn't get either to boot for the EXACT same reasons. Being Nvidia driver issues. Yes other distros worked, but it seems to be a consistent issue in some form or other.

Now just after purchasing this monitor, and having a (now known to be fruitless) play around with cabling, switching on/off, kernel updates, driver updates and Googling around.. I find that just shy of 3 YEARS after this monitor released, Nvidia have failed to provide any support in their drivers.

That is... insane.

They say they are working on it, but I work in the tech industry, that answer is absolutely meaningless without a date attached, and I could almost guarantee they literally have no deadline they are expected to meet to get this working.

We don't have the numerical fortitude to get them to actually prioritise this and it's just extra frustrating in that my only options to get it are to switch to Windows (why should I have to??) or give it back.

I had a look back at some Reddit posts and they were releasing hotfixes for Windows back in 2020 for their drivers and this screen resolution.... I repeat... it's just under 3 YEARS later, and we still don't have any Linux support. That should tell you all you need to know about how much they care.

[ephos]

Came here to add my support for this functionality being added. I am hoping it does make the 530 release because being locked into lower refresh rates isn't ideal. Hoping this gets more prioritization!!!

Kind of surprised how long these requests have been outstanding! This needs to get more traction!

[aritger]

Yes, we're actively working on the support to drive these high resolutions. I think if you look at the changes in src/nvidia-modeset/ for 530.03.02, quite a bit of the ground work is there (the "apiHead" vs "hwHead" separation, to allow multiple heads to be used to drive one extreme high refresh rate), but it unfortunately was not complete in time for 530.03.02.

[dmayle]

530.41.03 has, for example, newDev->dscCaps.bDSCDecompressionSupported = true;, is it working? My HDMI input isn't coming up at boot time when I install it, so I haven't been able to verify

[aritger]

DSC has been supported in the NVIDIA Linux GPU driver for quite some time. To drive these extremely high pixelclock modes on current NVIDIA hardware requires reprogramming the display hardware in a special way, ganging multiple "heads" together to drive these pixelclocks. That's really what this thread is asking for, and what I hope we're finally close to shipping. Thanks for your patience.

[dmayle]

@aritger I know, you've explained it before, but from the end user's point of view, these modes which have a pixelclock rate greater than HDMI bandwidth without DSC don't work, and all of the modes that have a bandwidth that don't require DSC work. With the lack of better terminology (since we don't have an easy way to describe it), users are looking for DSC support to get these high bandwidth modes working. In any case, I've managed to get 530.41.03 installed, and as you've confirmed, these high bandwidth modes are not yet shipping.

[aaronp24]

The terminology is kind of confusing and I apologize that we've been struggling to explain the limitations clearly. You're right that DSC is needed in order to push the number of pixels required for these high-bandwidth modes through HDMI. DSC is also used for DisplayPort and having it enabled allows modes to work on lower-bandwidth links that would otherwise be rejected. That part is working today.

However, the HDMI or DisplayPort link isn't the only bandwidth limit within the GPU. The problem we're running into here is that even though DSC unlocks higher effective bandwidths over HDMI or DP links, the part of the display engine that fetches pixels from memory and formats them for transfer over the physical display link has its own internal bandwidth limit. In the driver source code here, you'll see this unit referred to as a "head". In upstream DRM terminology it's referred to as a "CRTC". You can consider those to be synonymous.

As Andy mentioned, in order to push enough pixels into the display connector to support high bandwidth modes, we need to program the GPU to use two heads simultaneously. That's the part that we're working on now.

[pro4tlzz]

thanks for the explanation @aaronp24

Spawn that async head worker!

[KickAssDave]

Nvidia.. (note: a company whose 2023 revenue was $27billion), haven't been able to get this working on Linux after 3 years. I find this near insulting as a consumer of your products since I was a teenager. That is over 20 damn years of buying Nvidia graphics cards going back to a Geforce3 Ti200. I, personally, have spent £1000s of my personal cash on your products and I'm at a point now where I've realised I have absolutely no reason to show any brand loyalty to Nvidia anymore and will be jumping ship the minute my current card has had it's time.

It's worse than this, the main advertising page for the RTX 3090 (the card I own personally) actually states this right in bold text:
"
8K HDR Gaming
Connect, play, capture, and watch in brilliant HDR at resolutions up to 8K with GeForce RTX 3090 Ti or RTX 3090. Capture up to 8K HDR footage with the GeForce Experience™ ShadowPlay™ feature and play back smoothly with AV1 decode.
"

Well that's not true is it? And it's more annoying that the "up to" was likely legal jargon to allow you to say that given it doesn't actually work on some operating systems right?

This monitor, (I say that like it's the only really high res screen in existence (it's not)), came out just shy of 3 years ago... no support.

Someone asks on here, May 2022 (likely ran out of patience already)...
-- May 2022 response:
"I don't have an ETA for that, but we know it is an important feature that many people are asking for. Thanks."

-- November 2022 response:
"Yes, we definitely appreciate the priority of this. We're trying to get this support in place for our 530.xx release series, but dates are always in flux, so I can't give a firm ETA."

-- Feb 2023 response:
"We're working to provide this feature, but I can't say for certain whether it will be in 530.xx. Thanks again for your patience."

-- End of Feb 2023 response:
"Yes, we're actively working on the support to drive these high resolutions. I think if you look at the changes in src/nvidia-modeset/ for 530.03.02, quite a bit of the ground work is there (the "apiHead" vs "hwHead" separation, to allow multiple heads to be used to drive one extreme high refresh rate), but it unfortunately was not complete in time for 530.03.02."

-- April 2023 response:
"DSC has been supported in the NVIDIA Linux GPU driver for quite some time. To drive these extremely high pixelclock modes on current NVIDIA hardware requires reprogramming the display hardware in a special way, ganging multiple "heads" together to drive these pixelclocks. That's really what this thread is asking for, and what I hope we're finally close to shipping. Thanks for your patience."

If you worked for me and you didn't have something working on Linux that you had working on Windows 3 YEARS ago, you'd be sacked.

Of course, the issue and the problem itself isn't actually the technical skill or knowledge of their engineers.. it's the fact that it is a mega profit-driven organisation who quite clearly under no drive to devote any time to niche consumer problems.

I almost want my 3090 and my Intel i7 to die at this point, as it's a tiny push at the end of a long road of pushes for me to completely switch to AMD.

[edisionnano]

https://www.phoronix.com/news/NVIDIA-535.43.02-Linux-Driver

[dmayle]

"Added support for driving very high pixel clock mode timings such as 8K @ 60Hz. Please see the "MaxOneHardwareHead" X11 ModeValidation token in the README for details."

[ramialkawadri]

Can I get a link for the README file?

[aritger]

http://us.download.nvidia.com/XFree86/Linux-x86_64/535.43.02/README/xconfigoptions.html
(search for "MaxOneHardwareHead" in that page)

But, starting with 535.43.02, these higher refresh rate modes should work by default; MaxOneHardwareHead is just there as a way to turn that off if it causes

[KickAssDave]

No... way.
Did my comment reach someone higher up or remind Nvidia to show more care for the folk that got them where they are now lol...

I tried it temp on random Arch build.. yup. It works.

Waiting for AUR nvidia-beta to be updated. Tried to modify/create my own PKGBUILD and it went miserably... so I will just wait for the community to catch up (Arch user).

[1000001101000]

It appears to be working for me (4k@144Hz), though somewhat surprisingly still via just one hardware head like when it last worked with 470 drivers.

I believe the referenced setting is only needed if you want to limit it to one hardware head for some reason:

   o "MaxOneHardwareHead": The display hardware of the GPU has a pipeline
         that produces the images that are sent to each display device. One
         unit within this pipeline is the "head", which generates the mode
         timings for the display device. Some extremely high pixel clock mode
         timings, such as 8K @ 60Hz, exceed the capabilities of a single head.
         On Turing and later GPUs, the NVIDIA GPU driver can use multiple
         heads within the GPU to produce the mode timings for one of these
         display devices; the driver will do so implicitly when needed. In the
         "Display Device Information" pages within nvidia-settings, this case
         will be indicated by reporting "Number of Hardware Heads Used" as "2"
         rather than "1". However, NVIDIA GPUs have a total of four hardware
         heads. Using two of them to drive one high pixel clock display device
         will mean that there are only two available to drive other display
         devices in the desktop (thus, the GPU may only be able to drive a
         total of three display devices if one of them requires the use of two
         hardware heads, or the GPU may only be able to drive a total of two
         display devices if each of them requires the use of two hardware
         heads). Set the "MaxOneHardwareHead" ModeValidation token to force
         the driver to use at most one hardware head to drive the display
         device, falling back to a lower refresh rate or resolution, if
         necessary.
    
         Note that the ability to use two hardware heads to drive one display
         device requires hardware support only available in Turing and later
         GPUs. Also, the use of two hardware heads with one display device is
         not currently compatible with Quadro Sync.

[aritger]

I'm glad it is working for you, now. That it worked for you in 470.xx makes me suspect there was some other bug that was causing your problem, and not missing support for the functionality that "multiple hardware heads" enables.

But, in any case, I'm glad your issue is resolved.

[1000001101000]

somewhere I saw a credible theory at one point that some hard-coded threshold that forced either DSC, multiple hardware heads or both may have changed causing some configurations that worked despite lack of support for those things to break. I figured if that was true that support for those things should also fix my issue, which one way or another seems to have happened.

Thanks for all the updates as this worked its way through the development process!

[1000001101000]

for completeness, here is the info under 470 drivers. Seems like back under 470 it would drive it via dual connection link where as of 535 it now works again but as single link. I assume this means some other issue with the drivers 490-530 made it always try and fail to use a single link rather than dual, now with DSC it succeeds with a single link. I do wish I had a method to force dual link to allow it to work while these new drivers work there way out of the beta stage.

[pauldorman]

Thank you NVIDIA! Just installed the 535.43.02 beta driver into my Ubuntu Lunar system. I'm sure there will be the odd problem, but the big news for me is... [image: Screenshot from 2023-05-31 23-36-49.png] Woot! 240-ish Hz at last! It will be interesting to see if this has any effect on the issue with my crappy Samsung Odyssey G9 Neo, which likes to randomly go blank four or five times a day. I really doubt it though and feel I must resign myself to the regular chore of long-pressing the power button until it turns off before turning it on again (which works about 90% of the time, sometimes I need to turn it off at the wall). Until at least I get up the courage to pack up this monster again (the first one was even worse) and lug it over to Samsung, who will then deprive me of any monitor while they "investigate". Looking forward to the final release! Paul

…

On Wed, 31 May 2023 at 16:44, KickAssDave ***@***.***> wrote: No... way. Did my comment reach someone higher up or remind Nvidia to show more care for the folk that got them where they are now lol... I tried it temp on random Arch build.. yup. It works. Waiting for AUR nvidia-beta to be updated. Tried to modify/create my own PKGBUILD and it went miserably... so I will just wait for the community to catch up (Arch user). — Reply to this email directly, view it on GitHub <#238 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLNF32QGMEFT3ERPXK4PTXI3EARANCNFSM5W45JYWA> . You are receiving this because you commented.Message ID: <NVIDIA/open-gpu-kernel-modules/repo-discussions/238/comments/6045185@ github.com>

[edisionnano]

We won. Tiled display support next? VAAPI perhaps?

[pro4tlzz]

Lovely, can't wait to use 280hz on my desktop

[zoliben]

For those who were struggling on Ubuntu with installing the beta from the nvidia download portal, add the beta repo:

sudo add-apt-repository ppa:graphics-drivers/ppa

Then do the general apt update, then from "Additional Drivers", install the nvidia-driver-535 option. It'll ask for a UEFI password. During the next reboot, you'll need to import the key to UEFI, then after reboot it works as expected.

[KickAssDave]

Been having a nightmare trying to find a package manager that actually packages the latest beta in a timely manner.

Not updated on AUR yet and manual steps are a bit.... prone to issues...

I'll patiently wait for it to appear on AUR. I've tested it and it does work though. Finally.

[edisionnano]

nvidia-all by frogging family

[Midar]

(Since multiple people did this now:) This is not really the right place to discuss your distribution's packaging. This is about the kernel module for the NVIDIA driver and what downstream distributions do with it belongs on a distribution's bug tracker, not here. Discussing your distribution here a.) spams NVIDIA employees who get less motivated to fix bugs b.) makes it easy to miss regressions someone reports c.) spams everyone who is subscribed to this bug, most of which are not using your distribution.

[dmayle]

As a follow-up, I can report that an RTX 3080 with a TCL 65R648 (8k 6-series from 2 years ago) works fantastically at 8k60Hz!

[crimist]

When reading about the new ability to use multiple heads in 535.54.03 I noticed the following:

Note that the ability to use two hardware heads to drive one display device requires hardware support only available in Turing and later GPUs

I'm a bit confused by this - I have a 1080 Ti and my 3440x1440 display has no problem reaching 160Hz with the Windows driver but is limited to 144Hz on Linux. I imagine this is then unrelated to the multiple heads issue? For reference the display has a built in "overclock" feature that is enabled and allows it to reach 160Hz.

@aritger

[crimist]

No 160Hz option presented. I switched to daily driving Linux at driver 515 and haven't ever been able to go above 144Hz. I'll have to try 470 when I'm free.

[Midar]

You probably have the same LG monitor I had. It doesn’t need nor does it support DSC, so that’s entirely unrelated to this issue.

The monitor stops reporting 160 Hz when using a HDR mode, so maybe some initial HDR support was added to the NVIDIA driver and that’s the reason.

[crimist]

It's the 34GP83A-B and HDR is disabled but perhaps there is some bug around that. This issue is probably best asked in the NVIDIA Linux forum.

[aritger]

@crimist: Yes, I think your issue is unrelated to the DSC + multiple-heads-driving-one-monitor-behind-your-back functionality of this Issue.

It would probably be best to start a new thread on the NVIDIA Linux forums. I would suggest adding the "ModeDebug" X configuration option to your X config file (nvidia-xconfig --mode-debug, or add it manually), then restart X11, and look at the X log. The log should list why each mode was considered valid or invalid. That should tell us why the driver is invalidating the 3440x1440@160Hz mode.

[crimist]

@aritger Thanks for the suggestion. For anyone following along I've filed the issue on NVIDIAs Linux forums here.

[aritger]

The support requested in this discussion is available in the 535.xx drivers. I'm going to go ahead and close this discussion thread. Please start new threads if there are specific problems with the functionality.

[itay-grudev]

@aritger

I upgraded to 535.129.03 but I am observing some visual artifacts when running at 5120x1440@240Hz.

Frequency	Sample	Description
120Hz		Normal pixel blending
240Hz		Note how every second pixel row is brighter.

I think it's some kind of compression artifact or a bug that is quite annoying to look at. I also don't know if this is a driver issue or a problem with my monitor. Is this normal when running at maximum data rates?

[itay-grudev]

I'll wait for feedback and then I'll create a new thread if this is an issue that should be reported.

[Midar]

You seem to have an Odyssey Neo G9 (or maybe also non-Neo). This is a known defect with this monitor. Some exhibit it more than others, but it is an issue with the panel and I suggest you RMA it and try the lottery of getting one without issues again.Am 15.11.2023 um 16:07 schrieb Itay Grudev ***@***.***>: @aritger I upgraded to 535.129.03 but I am observing some visual artifacts when running at ***@***.*** Frequency Sample Description 120Hz Normal pixel blending 240Hz Note how every second pixel row is brighter. I think it's some kind of compression artifact or a bug that is quite annoying to look at. I also don't know if this is a driver issue or a problem with my monitor. Is this normal when running at maximum data rates? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[PcChip]

I'm having an issue with 3440x1440@240hz on the latest 535, 545, and 550 drivers
in X11, I can see the background window flickering through the foreground window
Setting the monitor down to 144hz causes this problem to stop
I assume this is related to DSC?

[aamaanaa]

i have a odesy g7 neo miniled, 4k 165 herz. the option 165 hertz 4k is aviable, but selecting it causes the monitor to go into a infinite loop of going on and off again.

it does work 144 hertz

the problem is not the hdmi cable