View Full Version : AMD, Intel and Nvidia driver issues and last recommended version
Asmodian
5th October 2019, 09:09
Windowed mode is fine, 8 bit output from madVR works too.
webbo
6th October 2019, 13:47
I have been successful with HDR passthrough on my LG C9 with 436.48.
Yes, but is the result displayed correctly?
If you check the First post of this thread, there was a number of drivers causing bogus metadata to be passed through
:rolleyes:
chros
7th October 2019, 12:15
I have been successful with HDR passthrough on my LG C9 with 436.48.
Do you happen to have any HDFury (or similar) device to check HDR metadata that the GPU outputs? (I'm asking because of this (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-215.html#post58649764).)
Or is anybody here who has one apart from @Manni?
Klaus1189
8th October 2019, 10:12
AMD released new Radeon Driver 19.10.1 with support for new Radeon RX 5500 models
huhn
11th October 2019, 16:52
they are not going to release a pretty much untested wddm version this time and this update is not like the other major updates because it's not changing much mostly bug fixes/performances and some small features are added.
chros
17th October 2019, 16:23
I have been successful with HDR passthrough on my LG C9 with 436.48.
Windowed mode is fine, 8 bit output from madVR works too.
Yes, but is the result displayed correctly?
If you check the First post of this thread, there was a number of drivers causing bogus metadata to be passed through :rolleyes:
@Manni just confirmed that v436.48 is OK (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-226.html#post58693494) and at the same time he stated that older drivers (that reported previously as OK) are broken. :)
@Manni, can I ask what exactly "broken" means? Which metadata values are affected?
Also, what does OK mean? Are *all* the metadata values correct? (maxCLL, maxFall, mastering values, mastering color coordinates, white point?)
Best to test the latter with a content that has different maxCLL than that mastering peak, e.g. with Guardians of the Galaxy (2014):
- "master luminance" 0.005/4000 ; maCLL/FALL 577/512
- sample (https://forum.doom9.org/showthread.php?p=1882771#post1882771), file name: "09-2160p_23fps_hdr0577-gotg.mkv"
I posted all this on doom9 before ...
10000 nit file
code values @ various nits from the white point setting:
760 nits: 669
1000 nits: 696
4000 nits: 713
passthrough: 713
Driver is nVidia's lastest, 436.48.
So, what I meant was: can you check a content like Guardians of the Galaxy (2014) sample (to have different values for maxCLL and mastering peak) and see that:
- using passthrough
- which code value is shown?
Question about 436.48:
- does it allow us to use custom timings (e.g. with CRU)?
- what happens to 12 bit switch in nVidia panel after playing 60fps content?
- did I miss anything important to ask? :)
Thanks!
iSeries
17th October 2019, 18:47
@Manni just confirmed that v436.48 is OK (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-226.html#post58693494) and at the same time he stated that older drivers (that reported previously as OK) are broken. :)!
I don't think he said drivers older than 436.48 are broken. He said passthrough is fine with recent drivers.
chros
17th October 2019, 19:04
I don't think he said drivers older than 436.48 are broken. He said passthrough is fine with recent drivers.
:) : "HDR passthrough is broken with old drivers (including 398.11)"
I've updated my above post (https://forum.doom9.org/showthread.php?p=1887757#post1887757) with a sample.
Manni
17th October 2019, 19:05
@Manni just confirmed that v436.48 is OK (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-226.html#post58693494) and at the same time he stated that older drivers (that reported previously as OK) are broken. :)
@Manni, can I ask what exactly "broken" means? Which metadata values are affected?
Also, what does OK mean? Are *all* the metadata values correct? (maxCLL, maxFall, mastering values, mastering color coordinates, white point?)
Broken usually means that HDR passthrough sends bogus metadata (usually the same for all titles). It can also mean that madVR doesn't manage to switch to HDR using the API, and that it stays in SDR. This is what happened to me with 398.11, and why I updated the driver to the latest. That solved the issue. I don't need HDR passthrough except for testing, and I need it more (and more often) than 3D, as I can use another source for that. No idea what broke it. Probably an OS update. In fact I wasn't able to install 385.28 or 398.11 without getting an error from the driver.
OK/correct means that *all* the metadata present on the disk is passed through, whether it's correct/complete, incomplete or invalid.
I don't think he said drivers older than 436.48 are broken. He said passthrough is fine with recent drivers.
Correct. :)
SamuriHL
18th October 2019, 00:45
So, what I meant was: can you check a content like Guardians of the Galaxy (2014) sample (to have different values for maxCLL and mastering peak) and see that:
- using passthrough
- which code value is shown?
696 with passthrough, 669 with 760 nit tone mapping. Not sure what you're expecting from this?
EDIT: Selected GotG2 when testing by mistake. Retesting now with GotG. One moment.
713 for passthrough, 669 with 760 nit tone mapping for GotG.
chros
18th October 2019, 12:32
... 398.11 ... No idea what broke it. Probably an OS update. In fact I wasn't able to install 385.28 or 398.11 without getting an error from the driver.
Very strange ... Thanks for the explanation!
Now I know (thanks to @SamuriHL's test) that 385.28 (on 1607) is fine as well, as you always told us so.
Can you do 1 more last test please, if you'll have time for it?
- use madvr pixel shader in "ouput HDR format" with the above posted GotG sample ("master luminance" 0.005/4000 ; maCLL/FALL 577/512)
- set 760 nits at real display peak
- What happens to the metadata values of: maxCLL, maxFall, mastering peak ?
Madshi said, they should be:
- mastering peak: 760
- maxCLL: 760 / 3 = 253
- maxFALL: ???
Thank You!
Not sure what you're expecting from this?
:) That's what I thought, but let's go over to the LG Oled thread.
Thanks for testing!
SamuriHL
18th October 2019, 14:57
Madshi said, they should be:
- mastering peak: 760
- maxCLL: 760 / 3 = 253
- maxFALL: ???
I don't see where they're changed in the OSD. I simply see:
master luminance: 0.005/4000
MaxCLL/FALL 577/512
So I doin't know if that's what you're looking for.
littleD
19th October 2019, 06:49
Added Support for YUV420 on Display Port for10thGen Intel Core processors with Iris Plus graphicsThey have ment probably Y′CBCR 4:2:0
chros
21st October 2019, 11:56
I don't see where they're changed in the OSD. I simply see:
master luminance: 0.005/4000
MaxCLL/FALL 577/512
These are the input metadata values on the OSD, but I'm curious the GPU output values when "ouput HDR format" is used, that's why we need @Manni's help.
SamuriHL
21st October 2019, 22:40
Yea I have no way of testing that at all.
Manni
22nd October 2019, 00:22
These are the input metadata values on the OSD, but I'm curious the GPU output values when "ouput HDR format" is used, that's why we need @Manni's help.
Alright then. But no more! :)
https://imgur.com/nnidZMv
You get the HD Fury Maestro input at the bottom and the JVC input at the top right (they agree).
So you don't need me or an HD Fury, just a recent JVC (or Oppo 203) owner with madVR :)
SamuriHL
22nd October 2019, 01:15
Are you blatantly trying to suggest that madvr is doing the right thing?! :P :D How dare you insinuate madvr is top notch software!! LOL I had very little doubt that'd be the case. It also means our drivers are finally working correctly, as well. Can't say the same for the LG but hey can't win em all. :D
huhn
22nd October 2019, 03:15
every end device could provide detail information about the stream the list is nearly for sure far longer then these to two.
and this isn't over HLG will take of soon.
Manni
22nd October 2019, 10:20
Are you blatantly trying to suggest that madvr is doing the right thing?! :P :D How dare you insinuate madvr is top notch software!! LOL I had very little doubt that'd be the case. It also means our drivers are finally working correctly, as well. Can't say the same for the LG but hey can't win em all. :D
There might be bug in madVR with [correction: pixel shader outputting HDR, not HDR passthrough] though: it shouldn’t raise maxCLL when it’s lower than peak brightness the way it does, because I don’t see any reason why it should go up. It should keep it at 577 instead of replacing it with the target. Only maxFALL should change in that case. It’s only if the target is lower than maxCLL that maxCLL should be lowered to the target.
Maybe madshi is doing this because he doesn’t trust the metadata, even when present and apparently valid, but it could give worst results with static tonemapping if the metadata is valid, because the display is expecting pixels above 577 when there are none. In this case, the difference is minimal, but with Blade Runner 2019 which has barely any pixel above 100nits (forgot what the metadata says, maybe around 200nits), it would be more significant.
SamuriHL
22nd October 2019, 11:01
Don't use static tone mapping then? [emoji16] No that could be problematic if that's the case. Hopefully madshi can find a way to fix it if it's truly a bug.
Sent from my SM-G975U using Tapatalk
Manni
22nd October 2019, 11:26
Don't use static tone mapping then? [emoji16] No that could be problematic if that's the case. Hopefully madshi can find a way to fix it if it's truly a bug.
Sent from my SM-G975U using Tapatalk
I never use static tonemapping or HDR passthrough except to run brief tests, but many displays do. :)
I only did this because of Chros' request.
It's not difficult to fix if it's a bug, madshi just needs to check and only replace maxCLL with target if maxCLL > real peak (760 in this example), and let it alone if maxCLL < real peak.
chros
22nd October 2019, 12:31
Alright then. But no more! :)
Thank You! :)
So you don't need me or an HD Fury, just a recent JVC (or Oppo 203) owner with madVR :)
Hmmm, good to know.
Is anybody here with the mentioned devices? (apart from Manni of course :) )
Can't say the same for the LG but hey can't win em all. :D
:D Not at all, I'll comment the LG thread as well ...
There might be bug in madVR with HDR passthrough though
Probably you meant "output in HDR format" (and not passthrough).
Good point! I missed this on your image :)
it could give worst results with static tonemapping if the metadata is valid, because the display is expecting pixels above 577 when there are none. In this case, the difference is minimal, but with Blade Runner 2019 which has barely any pixel above 100nits (forgot what the metadata says, maybe around 200nits), it would be more significant.
Blade runner is a good example, I think maxCLL was around 120 nits! :D
Manni
22nd October 2019, 12:54
Probably you meant "output in HDR format" (and not passthrough).
Good point! I missed this on your image :)
Yes I did, sorry for the confusion and thanks for the correction, I've edited my post. Of course that's what I used to take the screenshot :)
BTW I checked and BR2049’s maxCLL is 181. :)
SamuriHL
22nd October 2019, 14:06
I never use static tonemapping or HDR passthrough except to run brief tests, but many displays do. :)
I only did this because of Chros' request.
It's not difficult to fix if it's a bug, madshi just needs to check and only replace maxCLL with target if maxCLL > real peak (760 in this example), and let it alone if maxCLL < real peak.
Yea that seems reasonable. :)
kostik
22nd October 2019, 14:45
https://www.nvidia.com/en-us/geforce/news/call-of-duty-modern-warfare-game-ready-driver/
Nvidia GeForce 440.77 WHQL driver, new driver branch R440, will need a lot of testing.
It also adds support for windowed G-SYNC for OpenGL and Vulkan-based applications
Variable Refresh support for LG C9 TV's.(Needs confirmation / Beta firmware + Turing only)
SamuriHL
22nd October 2019, 15:03
Man I *JUST* looked about 45 minutes ago for new drivers and didn't see one out there. LOL Cause Windows had to do a full build install of 19h2 and I always reinstall my driver after that. Ok, I guess I'll go grab that and test it tonight.
ryrynz
22nd October 2019, 21:14
The variable refresh can work with other untested displays as well.
huhn
22nd October 2019, 21:51
they added free sync support over HDMI they are just trying to rename it to g-sync compatible with great success.
nevcairiel
22nd October 2019, 22:16
they added free sync support over HDMI they are just trying to rename it to g-sync compatible with great success.
They added HDMI VRR support. FreeSync is AMDs branding, "GSYNC Compatible" is NVIDIAs.
FreeSync never was the name of any specific technology, its just AMDs branding for either DisplayPort Adaptive Sync, or HDMI Variable Refresh Rate.
huhn
22nd October 2019, 22:47
screen are getting rebranded right now that.
SamuriHL
22nd October 2019, 22:49
I still don't see the driver on nVidia's download page. I'm missing something...
nevcairiel
22nd October 2019, 23:04
Its definitely there:
https://www.nvidia.com/Download/driverResults.aspx/152654/en-us
SamuriHL
22nd October 2019, 23:50
Yea I can get to it from your link but search is still bringing me to the october 1 driver. That's WEIRD! Downloading it now.
SamuriHL
23rd October 2019, 00:37
I'm already not a fan of this stupid driver. Really, nVidia? Previous drivers would often lose audio connection to my receiver when "idle". Which, ok, whatever. This new driver drops the connection back to stereo but it's constantly switching audio modes with the receiver. This probably doesn't happen for most people as I realize my equipment combination is probably unique, but, it was irritating before, now it's just downright obnoxious. My receiver CLICKS when it changes modes so having to hear it click constantly is stupid.
Manni
23rd October 2019, 01:01
Does the nVidia control panel take ages to load and is changing any setting super slow? Here it's unbearable. I didn't check the sound but I'm probably going to revert to the previous driver, where the control panel also takes ages to load but where at least changes are done at normal speed.
I'm not sure if it's the 1903 or the recent nvidia drivers, but I never had this issue (slow to load + slow to change settings) in the CP before.
SamuriHL
23rd October 2019, 01:31
I didn't have that issue. I'm running the potential 19h2 build so who knows what issue I'm having is. I'm likely to also revert if I can't figure out a solution to the audio issue.
el Filou
23rd October 2019, 02:09
I'm already not a fan of this stupid driver. Really, nVidia? Previous drivers would often lose audio connection to my receiver when "idle". Which, ok, whatever. This new driver drops the connection back to stereo but it's constantly switching audio modes with the receiver.Are you sure it's not some feature of 19H2? I'm using the same audio driver version that comes with r440 (1.3.38.21) but on 1809 and I don't have this.
FYI, you can 'fix' the audio stream drop when idle: search for 'PerformanceIdleTime' in the Registry & change it to 0 (you should find it in a PowerSettings subkey of the audio driver).
SamuriHL
23rd October 2019, 04:12
Are you sure it's not some feature of 19H2? I'm using the same audio driver version that comes with r440 (1.3.38.21) but on 1809 and I don't have this.
FYI, you can 'fix' the audio stream drop when idle: search for 'PerformanceIdleTime' in the Registry & change it to 0 (you should find it in a PowerSettings subkey of the audio driver).
I was running the previous driver on the same windows build earlier with no issues. So, yea, it seems this driver with my equipment changed the status quo. I'll look into the setting.
huhn
23rd October 2019, 05:57
the strange thing is the hd audio driver is the same as the last nvidia driver version.
SamuriHL
23rd October 2019, 12:33
I'll do a clean install of the driver later. Maybe something got corrupt. Always possible.
Sent from my SM-G975U using Tapatalk
Klaus1189
25th October 2019, 11:54
AMD released new Radeon Driver 19.10.2
huhn
25th October 2019, 17:55
Some Radeon RX Vega and Radeon RX 5700 series graphics products may intermittently experience a thread stuck crash or TDR when there is a high GPU load active.
finally.
ohh wait:
Stutter may be experienced when Radeon FreeSync is enabled on 240hz refresh displays with Radeon RX 5700 series graphics products.
for nearly 4 month now.
cremor
29th October 2019, 15:39
Since 441.08 now officially supports HDMI 2.1 VRR ("G-Sync compatible" for LG OLED TVs) I'd like to use this driver. Can someone please check if this driver version works correctly with HDR video?
Also: I've read somewhere that there was a problem with raised HDR black level in 440.97, I hope they fixed that.
nevcairiel
29th October 2019, 15:41
If you can't tell yourself if HDR is working correctly, does it ultimately matter? Does an issue affect you if you don't even notice?
cremor
29th October 2019, 16:41
I'm currently not using my PC as an HTPC, so I'm not sure if I would notice. But I'd like to use it as one in the future and therefore would like to have a "known good" driver version for both HTPC and gaming.
SamuriHL
29th October 2019, 18:57
Can I get another RTX owner to confirm something for me? I don't know when this changed so let me be clear on this. I'm using the 19H2 build of windows 10 and the driver just posted today. So that makes life difficult to determine when this changed. However, can someone confirm that they can now use D3D11 for presentation with 8 frame presented in advanced WITHOUT getting micro-stuttering issues that we previously saw? I am saying that i am able to play back with those settings and I'm not getting micro-stuttering anymore so I just want someone else to confirm this.
onekmilesbehind
30th October 2019, 02:14
@SamuriHL I've got a 2070 XC Ultra on driver 436.48 running on Windows 1809. I had it set to present 6 frames previously (and using D3D11 for presentation) with no micro-stutter issues, but bumped it up to 8 to test just now on a large 4k source file. No issues either. For me at least, the combo of forcing Vertical sync to "On" and power to "Prefer maximum performance" has done the trick.
SamuriHL
30th October 2019, 06:02
I wonder if nvidia fixed it at some point. In any case this is great news as it makes d3d11 useable again.
Sent from my SM-G975U using Tapatalk
webbo
2nd November 2019, 12:03
If you can't tell yourself if HDR is working correctly, does it ultimately matter? Does an issue affect you if you don't even notice?
Well, that's the point of the OP, right? To "agree" whether HDR is passthrough correctly or not :)
I keep asking about this here, but to no avail unfortunately :(
For example, someone new at the 4K HDR topic wouldn't be able to notice
el Filou
2nd November 2019, 15:00
People over at AVS Forum on the madVR tone mapping development thread have verified that with recent drivers (431.x and later at least), HDR passthrough is again working correctly on NVIDIA with correct metadata.
Sorry I can't find the exact post again, there's too many on that thread.
Edit: there it is: https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-225.html#post58689662
It has also been confirmed on this very thread: https://forum.doom9.org/showpost.php?p=1872629&postcount=179
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.