AMD, Intel and Nvidia driver issues and last recommended version

[Klaus1189]

chros
Done.

all
I need info for the last three Nvidia drivers: Should I remove a point or can anybody confirm anything of it? I need to clean it up.

[huhn]

It does in PC mode, since almost all the image processing are disabled.
You're right in theory, but we can only be certain if we manage to test it, but until I won't get 10bit option ... :)

that'S not how this works... even more in the context trying nvidia to use dither even through there is nothing to dither with madVR and correct settings.

and if you want to test 10 bit use an old AMD card.

[clsid]

If problems only occur with specific driver version then they need to be reported here:
https://forums.geforce.com/default/board/33/

[janos666]

I hooked up my AMD 2500U Ryzen+Vega notebook to the LG C8 TV (same Win10 18362.145 build, same HDMI4 port on the TV, same cable, etc) using the latest AMD driver (19.5.2).
The 10bit 1000nit HDR10 gray-ramp test video (Mechanic set) looks virtually the same between 8, 10 and 12 bit Full RGB settings (it seems as if the switch doesn't really operate at all but remains stuck at 8bit, even though both the AMD control panel and Windows Settings confirm the change). Using YCC yields very similar results (it's a little bit worse, as expected, but nothing crazy). Limited RGB passed to the TV inside Full RGB (madVR set to Limited, TV set to Limited, GPU set to Full) is also roughly the same.
madVR's own dithering seems to make no obvious visible difference. I guess that's because it automatically dithers to 10bit while the real output is erroneously converted (truncated/rounded) to 8bit at some point.
These AMD results look "somewhat acceptable". It's clearly much better than the nVidia results. Although the TV's internal player yields substantially better results.

So, I guess this is Microsoft's fault (the new Win10 build / WDDM version broke some display driver functionality, as is tradition since ~2017) and the AMD driver/hardware simply does a little better job with that unwanted 10bit -> 8bit conversion than nVidia (it probably happens in better precision and/or finished with better dithering --- probably because dithering is always on for AMD but the nVidia driver has no reason to activate it for the 12bit output setting [it probably has no way to know what's going on in actual reality with this bug]).

I am sure this bug wasn't there a month ago because I used this notebook to calibrate the HDR Game mode and it looks fine with the TV's internal player. I guess the calibrated results would be all over the place with the internal player if all this banding and random colorization was present (nVidia has more luminance errors and "blocks", AMD has more magenta/cyan colorization all over the gray gradient).

[chros]

I hooked up my AMD 2500U Ryzen+Vega notebook to the LG C8 TV (same Win10 18362.145 build, same HDMI4 port on the TV, same cable, etc) using the latest AMD driver (19.5.2).

Thanks for testing with an AMD card.
Which mode of the TV did you test? Normal (HDMI) or PC mode?

The 10bit 1000nit HDR10 gray-ramp test video (Mechanic set) looks virtually the same between 8, 10 and 12 bit Full RGB settings (it seems as if the switch doesn't really operate at all but remains stuck at 8bit, even though both the AMD control panel and Windows Settings confirm the change).

Is it the same with the nvidia HTPC as well? Or you can clearly tell the difference with it between 8bit vs 12bit?
I can on my system.

So, I guess this is Microsoft's fault (the new Win10 build / WDDM version broke some display driver functionality, as is tradition since ~2017) ...
I am sure this bug wasn't there a month ago because I used this notebook to calibrate the HDR Game mode and it looks fine with the TV's internal player.

Hmm, interesting.

[iSeries]

398.11 wouldn't be enough: it blocks the usage of custom resolutions, even using CRU. So, you'd need go back to 385.28.

Custom res works fine for me on all drivers past 385.28 with both madVR and CRU. After a certain driver (can't remember which one) madVR is only able to create 8bit custom res, but CRU is still able to create 8/12bit custom res.

Also with my LG C8, PC mode is clearly worse than non-PC mode (banding), and 12bit output from nVidia is clearly worse on my TV than dithered 8bit from madVR (again, banding). I wouldn't use either.

[chros]

Custom res works fine for me on all drivers past 385.28 with both madVR and CRU. After a certain driver (can't remember which one) madVR is only able to create 8bit custom res, but CRU is still able to create 8/12bit custom res.
Thanks, I also could create them with CRU but madVR couldn't utilise them (fallback to the native 23Hz). And I wasn't the only one. Have you checked madVR's OSD to verify it?

Also with my LG C8, PC mode is clearly worse than non-PC mode (banding), and 12bit output from nVidia is clearly worse on my TV than dithered 8bit from madVR (again, banding). I wouldn't use either.
Yep, you're right, but you get chroma 4:4:4 in return. Something for something ...

[janos666]

Thanks for testing with an AMD card.
Which mode of the TV did you test? Normal (HDMI) or PC mode?

HDMI label, of course.
Although, if my memory serves, even the PC mode HDR10 should look better when fed with real 10bit than what I now get with the nVidia card (PC mode used to be roughly somewhere between actual 8 [not dithered] and actual 10 bit [not truncated] with the HDMI label when things were normal).
Actually, I started investigating after I noticed some incredibly bad banding in PC mode. I always knew PC mode had reduced precision but it wasn't this bad. Now the input already has some banding and tinting which is only made worse by PC mode, making it unusually bad (not just a hard compromise for 4:4:4 in HDR10 games but "WTF!?%" bad...).

By the way, there should be no difference between 10 and 12bit HDMI output formats since the buffer is either 8, 10 or 16 bit. I am not aware if any software uses 16 bit today (and let the GPU dither/truncate it to "whatever the output is"), so technically the conversion from 10bit to 12bit (by the GPU) and any sane truncating/rounding from 12bit to 10bit (by the TV's processor - IF there is any) should be completely lossless (in worst case it might activates unnecessary dithering but even that should be virtually unnoticeable but I think the TV's processor can take 12bit without truncating it first, especially since it supports 12bit DolbyVision, so there should be no difference between setting the GPU to 10 or 12bit, I guess that's exactly why nVidia decided to remove the redundant options - too bad they have no "automatic maximum" option and the NVCP keeps randomly forgetting the 12bit selection for lower resolutions/refreshrates).

[iSeries]

Thanks, I also could create them with CRU but madVR couldn't utilise them (fallback to the native 23Hz). And I wasn't the only one. Have you checked madVR's OSD to verify it?


Yep, you're right, but you get chroma 4:4:4 in return. Something for something ...

4:4:4 in exchange for horrific banding to watch material that only had 4:2:0 to begin with ;-) I'd consider the picture worse overall.

For CRU - https://forum.doom9.org/showpost.php?p=1868222&postcount=79

[Asmodian]

On my C9 banding is not an issue as long as the GPU didn't need to do a bit depth conversion. I get good results using 8 or 12 bit full range RGB output for SDR and HDR. I still end up using 8 bit all the time, I don't notice 12 bit being an improvement but it at least it isn't a negative anymore.

If I send 10 bit from madVR and have the GPU convert to full range 8 bit RGB I do get obvious banding but if I set the GPU to limited range or 12 bit it is fine. It looks like a dithering issue (or lack thereof) when using full range output. :mad::(

2080 Ti, 430.86, Win 10 1903.

[huhn]

try that again with FSE.

10 bit windowed with 8 bit GPU is known to be broken.

[Asmodian]

Exclusive looks the same, it really seems like the GPU does not dither when converting 10 to 8 bit. :(

[Klaus1189]

Can you post links to testfiles for banding issues so I can test here?

[huhn]

i tested windows 18343 with 430.86.

FSE doesn't work
old FSE banding
d3d overlay as always working perfectly.
WFS banding

i'm talking about over 1 cm width banding on an 24 zoll screen!
his has nothing do do with dithering just to make that clear.

10 bit:
~same 1 cm banding
WFS just more banding dithering related
FSE banding not dithering related edit: done with the compatibility mode FSE.


i will test another system with an 2018 build later and update the insider build on this system to a newer one if there is one.

[huhn]

http://www.bealecorner.org/red/test-patterns/Gradient-16bit.png

wait 30 sec between post got me:-)

[oldpainlesskodi]

i tested windows 18343 with 430.86.

FSE doesn't work
old FSE banding
d3d overlay as always working perfectly.
WFS banding

i'm talking about over 1 cm width banding on an 24 zoll screen!
his has nothing do do with dithering just to make that clear.

10 bit:
~same 1 cm banding
WFS just more banding dithering related
FSE banding not dithering related


i will test another system with an 2018 build later and update the insider build on this system to a newer one if there is one.

Yep its nuts, but seems fine using a wddm 2.5 driver (on my setup anyway) using build win10 1903 - 18898.1000

[huhn]

windows 17763 nvidia 430.86
10 bit WFS with the GPU at 8bit shows banding as always FSE is fine.
so the driver alone isn't the problem.
i wait for klaus for now but i can in theory test AMD too but i really don't want to replace hardware.

i have to add more informations to my insider test i used later the "original" FSE because the new one didn't work it's just saying in WFS and flickers from time to time.

[Klaus1189]

Perhaps stupid question but when is banding considered as an issue? Of course not 1cm here on a bigger monitor, but I need to know how far according the screen diameter I have to look at. Other things that are important to check?

[huhn]

fine: https://abload.de/img/finejikv2.png
banding from not dithering: https://abload.de/img/notditheredtojjj.png

the banding from not using dither is "always" the same. or with other words the step distance should always be the same.

[oldpainlesskodi]

The Spears_Munsil_Quantazation_Test_2160p.mp4 file is always very useful.

Here is a copy if anyone wants it:

https://jmp.sh/BzseoJO

With a wddm 2.5 driver, you get small banding at 12bit/8bit dithered on the 8bit plane (left window), and smoother on the 10bit plan (right window), however, using a wddm 2.6 driver on the latest win10, I get Rainbow bands, as Hunn described, about 1/2 inch wide on my 55 inch display, on both planes at any bit depth output, or range, FSE or WFS.

[huhn]

windows 18908 with 430.86 same issues.
if i have to point to somethign with no prove it would be the new super wet ink feature.

what so ever i have no clue why this should be related to dithering.

[oldpainlesskodi]

MS just pushed out 18908 on fastring - was hopeful, but......

Back to wddm 2.5 it is then.

[Klaus1189]

I checked with DxDiag and I have WDDM 2.6 and see banding, at least I think. I must admit I am not super sensitive to it, so to get conclusions a videophil guy must do that, I am sensitive to motion, but that is another story.
Perhaps I can learn, but on both screenshots I see banding, despite the notdithered has small steps visible, but both have wide areas which look not good, wehn watched 1:1 pixel scaled in browser.

And another starange thing, if I want to select 4:2:0 10 bit in Radeon 19.5.2 it jumps back to 4:4:4 8 bit, but if I play a file and check Radeon driver 4:2:0 10 bit is active, dispite I didn't selected it.
Not happy with 1903, but I am diggin...

I put the testfiles on an USB device and playing it with internal player and I see steps also here. I played Gradient-2k.mp4

[chros]

By the way, there should be no difference between 10 and 12bit HDMI output formats since the buffer is either 8, 10 or 16 bit. I am not aware if any software uses 16 bit today
MadVR works 16bit internally, if I'm not mistaken.

and any sane truncating/rounding from 12bit to 10bit (by the TV's processor - IF there is any)
That's my point (using PC mode).
I also checked normal mode, see below ...

NVCP keeps randomly forgetting the 12bit selection for lower resolutions/refreshrates).
Really? :)

On my C9 banding is not an issue as long as the GPU didn't need to do a bit depth conversion.
Have you tried PC mode as well on C9? I wonder about the difference between previous generation (C8).

try that again with FSE.
Just tested this on my config yesterday in normal mode (non-PC):
- FSW has more banding (?) or lack of dithering (?), but when I move the mouse to the bottom of the screen - to make the control bar visible - then the problem disappears (I remember when you first noticed this)
-- even the best case has major banding on the screen at the darker part
-- 8bit vs 12bit has just a slight difference
- FSE looks like FSW when the playback control is visible
-- it has major banding on the screen at the darker part

But FSE is unusable for me: HDR mode gets stuck on the GPU (hence on the TV) when I load an SDR video into MPC-BE after an HDR one :) (restart64.exe of CRU randomly solves the issue, reboot does all the time.)

So, in summary, my only real option is FSW, using PC mode, and there's only a slight difference between 8bit vs 12bit in real SDR content, although HDR content shows a bit more difference.

Can you post links to testfiles for banding issues so I can test here?
- sdr gradient: AVS HD 709 - mp4 version (https://www.avsforum.com/forum/139-display-calibration/948496-avs-hd-709-blu-ray-mp4-calibration.html) - Misc pattern - A-Additional - 1-Grayscale Ramp
- hdr gradients: Mehanik HDR10 (https://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set.html) - 03. Grayscale - 3.1. Grayscale ramps - and 1;2;5 are useful

What display do you have? Does it support HDR?

And another starange thing, if I want to select 4:2:0 10 bit in Radeon 19.5.2 it jumps back to 4:4:4 8 bit, but if I play a file and check Radeon driver 4:2:0 10 bit is active, dispite I didn't selected it.
Have you selected lower refresh rates as well, e.g. 30Hz?

[Klaus1189]

Have you selected lower refresh rates as well, e.g. 30Hz?

I tried it just now and then 4:2:0 is missing completely in the drop down list :confused:

[nevcairiel]

MadVR works 16bit internally, if I'm not mistaken.

Internally, yes, but it does not send 16-bit to the output, because while you can use many more formats internally for processing, for output only a small subset of formats are supported, and the only 16-bit format is ... weird.

So madVR will always give 8-bit or 10-bit to the OS/Driver for output.

[ashlar42]

See here: https://forums.geforce.com/default/topic/1082681/geforce-drivers/is-it-possible-to-quot-port-quot-dithering-from-nvidia-x-server-to-geforce-driver-/23/

And, there is an easier way to add dithering, try this app :

https://jmp.sh/NGf7DJj

the settings I use are 1 (enable) 2 (10bit) 4 (temporal). Then use task manger to kill, and vola...done

You can check by opening up regedit and going to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\nvlddmkm\State\DisplayDatabase/your driver (in my case 07e0_ed) and its all done (the app has added DitherRegistryKey).How would this dithering function interact with madVR dithering?

In my future I see an OLED TV, which I understand works better if the input is 8 bit, dithered by madVR. What would the above settings get me if outputting 8 bit? I would use 1, 1 and 4 but... would it make sense?

[oldpainlesskodi]

Good question - it could be that Madvr bypasses any driver dithering, I dont know.

Maybe Nev or Madshi could shed some light.

I think all I can say, is that myself, and a number of others, are having issues with, what looks like wwdm 2.6 drivers (nvidia) and some of latest versions of windows 10.

[huhn]

Just tested this on my config yesterday in normal mode (non-PC):
- FSW has more banding (?) or lack of dithering (?), but when I move the mouse to the bottom of the screen - to make the control bar visible - then the problem disappears (I remember when you first noticed this)
-- even the best case has major banding on the screen at the darker part
-- 8bit vs 12bit has just a slight difference
- FSE looks like FSW when the playback control is visible

we are testing if the nvidia driver dither or not so you have to make sure you are sending 8 bit with the GPU driver. because if you want to test GPU dithering you have to remove the viable of the end device.

you can't dither something that doesn't need dithering.
so yes madVR "bypasses" dithering if you like to say or better if you want your software to dither do it yourself and don't trust a GPU doing it for you because it doesn't have to heck it could even be considered to be wrong.

and most important right now the WDDM 2.6 related banding is not dithering related dither or not dithering will not do something like that.

[huhn]

edit: checking the same screen on a different PC.
edit2: nothing on a different PC so it doesn't matter what displays it and the issue is created at presentation or after i tested 2 different screen on the source PC so no both are not broken after the windows update. so it doesn't effect rendering which is good i guess.

the issue can be seen with screenshoots.
alt print: https://abload.de/img/screenshootofthebandiktj4f.png
madVR screenshoot function: https://abload.de/img/gradient-16bit.png_snpjjh4.png

[oldpainlesskodi]

Just tried the new Nvidia 435.27 driver....same 'ol same 'ol. Back to wddm 2.5....sigh.

If anyone wants it:

https://www.mediafire.com/file/pb67ea28aadwnf7/Nvidia+435.27.rar

[huhn]

can you make sure overlay avoids the issue for you too?
there is sadly a chance that nvidia has nothing todo with that issue...

[janos666]

I went back to 425.31 (Windows remains 18362.145) to compare the HDR10 1000 nit gray gradients. It's a lot better but the TV's internal player still gives me a distinctly better looking result. I can't remember if I ever compared them like this before. So, I wonder if there is still some small quality issue with this Windows build (independent of driver WDDM version) or these slightly older drivers (an older, small bug) or LG's player applies some sneaky de-banding on it's own volition (independently of the user controllable de-banding feature in the picture settings which can be turned off for both HDMI and internal sources). May be I should try 398.11 after all.

By the way... Was 398.11 thoroughly tested with HDR10? I remember 378.92 being the first and only driver for a long time which allowed a Frotbite3 games (like ME:Andromeda) to work in DolbyVision mode and some nV rep later claimed DolbyVision was broken by this same metadata bug (which resulted in a black screen in case of DV). Although, I remember DolbyVision started working temporarily with some (390? or) 400-series drivers (at least partially because the screen still turned black after closing the game but was playable in DV) until something broke it yet again (and eventually got fixed with the WDDM 2.6 / 430-series, though the screen still turns black after exiting from DV). So I am not sure these 380-410 series drivers are fully bug free either (since DV was broken for a long time with many of these).

I checked 378.92 and it's full of banding as well, similar to 430.86.:mad:
And this bug is not limited to madVR, HDR10 games also look better with 425.31 (the PC mode of my TV highlights the issue and it's easy to observe on the transparent effects of the game menu and HUD elements - there is a lot of magenta tinting on gray shades with 430.xx).

[oldpainlesskodi]

can you make sure overlay avoids the issue for you too?
there is sadly a chance that nvidia has nothing todo with that issue...

Can you explain what you mean? Do you mean enable windowed overlay in Madvr?

[Asmodian]

Yes, Windowed Overlay skips much of the WDM so it is an interesting test.

[oldpainlesskodi]

Ok thanks, will take a look.

Update - unfortunately, it made no difference on my setup. Back to 425.31.

Oh well.

[huhn]

did you make sure that stuff like d3d11 and FSE are disabled while testing with overlay?

[oldpainlesskodi]

did you make sure that stuff like d3d11 and FSE are disabled while testing with overlay?

No, will give it a try.

I also get it using MPC-Hc using stock EVR too. wddm 2.5 if fine. Wddm 2.6, huge banding...but I think you are right, im not sure its a dithering error, there is something else going on.

Update - Looks like i'll be on wddm 2.5 for some time. Tried dx9 on 430.97 and had a black screen whist audio playing, and madvr said dx9 failed to render, or something along those lines.

I just don't get why its fine on 425.31 (or any wddm 2.5 driver), but borked on anything 43x.xx (wddm 2.6) my end - not that I really want to update from 425.31(especially the alanfox2000 version) , but you know what's it like....

[janos666]

did you make sure that stuff like d3d11 and FSE are disabled while testing with overlay?

I didn't know the "overlay" required DX9. When I tried to enable it on an AMD machine (when it was new and didn't yet know what it really is) madVR clearly showed me a red warning message about how it's unsupported on the system. There is no warning like that when I enable it with DX11 (FSE needs to be disabled though because that takes priority otherwise). Can madVR even output 10bit without DX11, overlay or not? I though DX9 was practically limited to 8bit (may be there is some way but too quirky/complicated or needs proprietary extensions which were possible for DX9 but if I recall only AMD used something like that ... some 10+ years ago).

[oldpainlesskodi]

"madVR clearly showed me a red warning message about how it's unsupported"

That's what I got on my nvidia card too.

[j82k]

Just updated windows to 1903 and I'm having the same color banding issue. And yes disabling D3D11 and enabling overlay in madVR fixes it. My render times are about the same, so is there any disadvantage with d3d9 overlay compared to d3d11 non overlay?

[huhn]

ehm how should i put this...

first of all AMD never supported d3d9 overlay hell even intel does support it but that's a different topic.
i have no clue why someone things 10 bit is of any important when testing this.
overlay is d3d9 only so if d3d11 is ticked it not used by madVR and it can't use it the OSD clearly tells you that by simply not saying d3d9 overlay same for FSE it a different render path you don't need a red error massage for everything.
pascal clearly supports overlay so...

[oldpainlesskodi]

Ok will give it another try and make sure I set everything up correctly - will report back tomorrow, however, if it works, great, but its not a long term fix.

Edit - Hunn, which version of marvr are you using?

[huhn]

current release version.

[Asmodian]

Have you tried PC mode as well on C9? I wonder about the difference between previous generation (C8).

This is a complicated topic, I have tried to do a bunch of testing but do not feel like I can come to a definitive conclusion. :o

With that "don't take my word for it" out of the way... the small amount of banding that is present on my set does not seem to change depending on input type or PC/Game mode. It does move around if I change between PC and other HDMI modes but I do not think the magnitude increases any more. The difference between my C7 and my C9 is obvious.
Edit: I was running 8 bit D3D9 overlay for these tests, to try to remove any WDM issues, except for any 8 v.s. 10 bit tests, of course.

I have run autocal on the C9 via Calman and comparing non-calibrated modes to my calibrated ones with several banding test patterns also shows similar banding. Banding is also similar after a "full DCC reset" which seems to erase all color calibration for that mode, including the ones from the factory.

I probably gave the impression that there was no banding on my C9 with my previous comment but I should have said the banding wasn't any worse with 10 bit input. Just the normal (:mad:) minor banding similar to what my C7 has in its best (for banding) mode.

[huhn]

you at least gave me the impression that they fixed the banding issue with the 2019 re-release

[Asmodian]

Yeah, sorry. :o

It is still not perfect but it is better in 4:4:4 full range. That issue with noticeably worse banding with 10 bit input really annoyed me on principle so was too focused on that.

[janos666]

first of all AMD never supported d3d9 overlay
I knew that. I just noted how I get a clear error message on AMD (not unexpectedly) and how this tricked me into believing overlay works on nVidia when it's ticked in the settings and there is no such error message. It was a mistake, I see that now.

overlay is d3d9 only so if d3d11 is ticked it not used by madVR and it can't use it the OSD clearly tells you that by simply not saying d3d9 overlay same for FSE it a different render path you don't need a red error massage for everything.
pascal clearly supports overlay so...

Ok, may bad. I don't think I ever really used the overlay mode before. I had either no hardware or use case for it because I think it was added to madVR while I had a Radeon card but then the DX11 mode was also introduced before I switched to a Geforce again (and DX11 not just seems superior but even mandatory for HDR10).

i have no clue why someone things 10 bit is of any important when testing this.
That's because I initially noticed the banding on HDR10 content and thus started to check HDR10 test patterns. I obviously wish to output 10bit if both the source and the display are native 10bit. And I suspected these patters have banding because 10bit output is erroneously truncated to 8bit. How could I check if 10bit gets through (from source to display without truncation/rounding) if madVR deliberately converts it to 8bit? I wasn't aware if there was similar banding problem with 8bit material.

By the way, I checked this DX9 overlay mode now and it looks like it has some gamma issue. SDR movies look like they were converted to almost linear tone response (there is absolutely no shadow detail, everything is bright in night scenes and colors are "washed out", skin tones are bright yellow, etc). Since I have no past experience with this mode, I have no idea if this is by design or not.

[Asmodian]

By the way, I checked this DX9 overlay mode and it looks like it has gamma issues. SDR movies look like they were converted to almost linear tone response (there is absolutely no shadow detail, everything is bright in night scenes and colors are "washed out", skin tones are bright yellow, etc).

That does not sound right. Are you using a Windows calibration or something? Overlay looks correct on my system.

[huhn]

That's because I initially noticed the banding on HDR10 content and thus started to check HDR10 test patterns. I obviously wish to output 10bit if both the source and the display are native 10bit. And I suspected these patters have banding because 10bit output is erroneously truncated to 8bit. How could I check if 10bit gets through (from source to display without truncation/rounding) if madVR deliberately converts it to 8bit? I wasn't aware if there was similar banding problem with 8bit material.

not this again...
every* commercial file you play that is about to be converted to RGB is 32 bit float this counts for DVDs, BD, UHD BD. if a file is encoded in 8, 10 or 12 bit has nothing todo with this.

or with other words you could never check if a file gets out without truncation rounding or dithering because it's not possible.

*add unimportant number of exclusion here