View Full Version : AMD, Intel and Nvidia driver issues and last recommended version
Manni
21st October 2020, 09:29
https://developer.nvidia.com/blog/nvidia-turing-architecture-in-depth/
Turing & Ampere has native HDR processing display pipeline & tone mapping, maybe that's why you see differences in GPU generations.
I am not using the GPU for HDR processing/tonemaping. madVR is doing the tonemapping with pixel shader. But for some reasons recent drivers lead this SDR content to be sent with bogus HDR metadata, at least with my GTX 1080ti.
Anyway, I'm only reporting issues so that others are aware that post 442.74 drivers can cause issues with pascal GPUs. I'm not looking for solutions, it's not the first time nVidia breaks something with their drivers :)
glc650
21st October 2020, 16:38
Thanks for the feedback, but are you using HDR passthrough or pixel shader tonemapping?
passhtrough
Manni
21st October 2020, 17:18
passhtrough
That's what I thought, and that's why you're not having any issues.
Thanks for confirming :)
SamuriHL
21st October 2020, 20:24
Thanks for the feedback. That's helpful, if not fully depressing. :D Man, nVidia, seriously....
VBB
22nd October 2020, 03:22
Another hotfix driver, apparently released quietly yesterday: https://nvidia.custhelp.com/app/answers/detail/a_id/5099/kw/hotfix
VBB
22nd October 2020, 22:48
Out of curiosity, I left everything at defaults after doing a clean install of this latest hotfix driver. Strangely enough, "optimal" seems to act like "adaptive" now. I did not notice any power fluctuations. Frames were stable and at the same ms. Can anyone confirm this?
huhn
23rd October 2020, 04:17
i reported something like this before. they seem to changed something about it. that why i found the stuck power managament mode.
Klaus1189
23rd October 2020, 16:57
https://www.igorslab.de/en/3dmark-in-ultra-hd-benchmarks-the-rx-6800xt-without-and-with-raytracing/
el Filou
23rd October 2020, 19:00
Please, we have this thread now for this: https://forum.doom9.org/showthread.php?t=181881 ;)
Klaus1189
23rd October 2020, 19:17
Sorry.
Any news about the Pascal vs. Turing or GTX vs. RTX last recommended driver?
VBB
23rd October 2020, 19:23
I can only comment on Maxwell and HDR pass-through, but I've had no issues with the new drivers, including the latest hotfix.
SamuriHL
29th October 2020, 13:48
Oh joy wonder what they broke this time. Lol
Sent from my SM-G975U using Tapatalk
Manni
29th October 2020, 14:49
Great news for the 3xxx series, 10bits over HDMI is finally unlocked, which means that 40gb/s is enough for 4K60p 4:4:4. I had missed that.
See https://www.youtube.com/watch?v=EtaMLPo3b8o
I'm waiting to hear more about the rumoured 3080ti with same 102 die as 3090, almost the same number of cores, full bus width and 12gb of VRAM. It's expected to cost under $1,000, possible as low as $899.
Depending on the clocks, it might end up as fast or even faster than the 3090 for much less money.
[EDIT: I grabbed a chance to pre-order a Zotac 3090 Trinity at non-scalping price expected to arrive on November 10. 24Gb still has an advantage over 12Gb for me, if I can get my hands on the card this year. We shall see!].
QBhd
30th October 2020, 15:43
there is one case with overblown HDR just chill for now.
edit: BTW. you complained about low YT quality right? there seems to be a major issue with the current AMD driver and web browser.
try this video https://www.youtube.com/watch?v=PRUrlZFty3A it looks horrific on my system if you load the same stream into let'S mpc-be it fine.
this is my last word about this in this topic if you want to discuss this in more detail feel free to do so in the driver thread.
So what are we supposed to be looking for? I just tested this clip and it looks fine to me... I have yet to see any "major issue" with AMD and web browser
QB
Klaus1189
30th October 2020, 16:00
edit: BTW. you complained about low YT quality right? there seems to be a major issue with the current AMD driver and web browser.
try this video https://www.youtube.com/watch?v=PRUrlZFty3A it looks horrific on my system if you load the same stream into let'S mpc-be it fine.
Yes I have one single video which looks awful. I used Firefox first and it is the same in MPC-BE. So I think it is encoded that way. Just to remember I was referring to the background:
https://www.youtube.com/watch?v=07FYdnEawAQ&t=47
this is my last word about this in this topic if you want to discuss this in more detail feel free to do so in the driver thread.
Why so harsh? I only read your vague comment in the madVR thread and asked for more details. I thought there might be something I missed.
Klaus1189
30th October 2020, 16:06
https://www.youtube.com/watch?v=PRUrlZFty3A it looks horrific on my system if you load the same stream into let'S mpc-be it fine.
I just watched that video. What issue(s) do you see?
huhn
30th October 2020, 16:07
extremely hard blocking on chromium based webbrowser in close to black details.
even using screenshoot fixes it so does playing it externally in a media player. i have no notice this on my nvidia system else i would not even assume AMD to be related to this issue.
my last word about webbrowser artefacts in the madVR thread not your general question compatibility.
Yes I have one single video which looks awful. I used Firefox first, and it is the same in MPC-BE.
ok should be a different issue.
Klaus1189
30th October 2020, 16:10
What is that "different" issue? How can I reproduce it?
huhn
30th October 2020, 16:17
you don't seem to have it. you really just have to watch the video and pause it is not impossible to miss.
i use vivaldi 3.4.2066.86 also tested a fresh install of chrome (has to go now) and the currently installed edge i'm on 19041 20H1 amd 20.10.1
Klaus1189
30th October 2020, 16:27
What info is displayed when you rightclick on the videoframe on your browser and click on "Statisiken für Nerds", sorry now it is "Interessierte". The video is available as MP4 with AVC encoded video and WebM with VP9 encoded video.
Perhaps that is also a point?
huhn
30th October 2020, 16:54
i tested these too it one of the first things i did. the browser uses VP youtubeDL in mpc-hc defaults to h264 mpc-be defautls to h264 so i DL the stream 248 and tested it locally.
what i just tested it in film and TV app it has the same issue a bit differently. taking a screenshoot and it's gone i have to move the player windows or go fullscreen to trigger it again.
that's such a mess. mpcVR is fine too with d3d11 (that kinda new BTW.) d3d9 is forced limited for me.
i guess reinstalling the system is faster then debugging this feels bad when i aim to replace it in 1-2 weeks.
does someone know if a program can know if a screen is taken from it?
VBB
30th October 2020, 18:29
After a clean install of 457.09, I noticed again that "optimal" behaves just like "adaptive". I've seen no reason to change it so far. YMMV
SamuriHL
30th October 2020, 22:15
Neat. I'm in the middle of doing a clean install right now. I was going to check HDR real quick and make sure they didn't break the metadata again. I've got the fury inline. I'll report back shortly.
SamuriHL
30th October 2020, 22:22
No change from previous drivers where HDR is concerned. Bringing up the player overlay will drop you back to SDR until you're back in full screen. Metadata is working as expected.
angmav
1st November 2020, 12:45
Can I ask a question are we nvidia owners that stupid that we need a thread with over 2000 posts to make sure our card works properly this is ridiculous that a massive company like nvidia cant hire someone to simply test this stuff I understand us home theatre pc owners are a small market share of sales but can any amd owners tell me if they have any issues because I think I am done with nvidia seriously every new driver fixes one thing and breaks another , now we have firmware that works different for different models then why release new firmware for it ,why not develop a different branch one for RTX , one for GTX , if I am wrong please tell me I am just over it
Sent from my iPhone using Tapatalk
huhn
1st November 2020, 13:42
for AMD the GPU driver where just dying for like 6 month when decoding VP9 they renamed this bug like 5 times in the known issue notes before fixing it and DXVA and D3D11 processing are utterly broken for like a year now(madVR doesn't really use this).
just to give you a reverence point nvidia user are currently complaining about HDR stops working when a player bar or something like this is presented something AMD was never capable of.
this was an issue that went under the radar: https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK/issues/33
webbo
5th November 2020, 13:18
No change from previous drivers where HDR is concerned. Bringing up the player overlay will drop you back to SDR until you're back in full screen. Metadata is working as expected.
So HDR basically works correctly again, but the SDR to HDR flicking when overlay is brought up. Hmm
What would be the latest driver not to resort to this behavior ?
:(
I used to use 442.74 , but I might need a newer one for certain games to properly work
SamuriHL
5th November 2020, 14:57
Much older drivers. I don't even remember the branch much less the specific versions at this point that don't show the sdr behavior when the overlay is shown. Seems to be an intentional change.
Sent from my SM-G975U using Tapatalk
el Filou
5th November 2020, 18:51
It is intentional: https://forum.doom9.org/showthread.php?p=1925280#post1925280
Judging from the way they phrased it in that KB article, I don't think they'll change that behaviour again.
Manni
5th November 2020, 20:13
Nope. Been running the fall update for a few weeks now with no problems. Had 2004 since it went release as well.
Sent from my SM-G975U using Tapatalk
How about 20H2? :)
VBB
5th November 2020, 20:59
20H2 is the fall update.
chros
5th November 2020, 21:37
So HDR basically works correctly again, but the SDR to HDR flicking when overlay is brought up. Hmm
...
I used to use 442.74 , but I might need a newer one for certain games to properly work
Just a short note (I'll write more later), the 442.74 doesn't change hdr metadata without restarting the player!
I went through lot of drivers (about 10 of them), including the last one and none of them is perfect.
So I went back to the good old 385.28 with the old pascal card.
Manni
5th November 2020, 22:32
20H2 is the fall update.
I know, I was asking if he (or anyone else) had any issue with 20H2 vs previous builds. :)
VBB
5th November 2020, 22:42
Ah, gotcha. Can't speak for Samuri, but I've had it installed since it was released, and I haven't found any issues compared to previous builds. Fresh install.
SamuriHL
6th November 2020, 03:29
No, no issues for me at all. I've been running it for a while now.
nevcairiel
6th November 2020, 11:03
I know, I was asking if he (or anyone else) had any issue with 20H2 vs previous builds. :)
Which is weird because you quoted a post from him already saying that the Fall update runs fine. :)
Manni
6th November 2020, 12:23
Which is weird because you quoted a post from him already saying that the Fall update runs fine. :)
Thanks, my mistake, I missed the first half, I thought he was referring to 2004... :o
No, no issues for me at all. I've been running it for a while now.
Thanks (again) for the confirmation :)
SamuriHL
6th November 2020, 18:18
And really the Fall update was not a huge update at all. Nothing structurally changed under the covers. But yea it's safe to upgrade to.
webbo
6th November 2020, 19:20
Just a short note (I'll write more later), the 442.74 doesn't change hdr metadata without restarting the player!
I went through lot of drivers (about 10 of them), including the last one and none of them is perfect.
So I went back to the good old 385.28 with the old pascal card.
Much older drivers. I don't even remember the branch much less the specific versions at this point that don't show the sdr behavior when the overlay is shown. Seems to be an intentional change.
Sent from my SM-G975U using Tapatalk
Ok, so for PotPlayer usage, Exclusive PotPlayer Mode would be the only choice in order to address the out-of-HDR-when-mouse-moving-GUI-displaying scenario.
It ain't that bad, all things considered.
Thanks for your inputs!
Asmodian
7th November 2020, 02:35
I cannot use resolutions that require DSC with a Club3D CAC-1085 adapter on my 2080 Ti with 457.09. With 456.71 it works normally.
I have also seen reports of DSC monitors not working on 3000 series cards using the same drivers.
peacetalks
7th November 2020, 07:55
Hello everyone, New poster here. I've been following this thread to get HDR on Kodi 17.6 Krypton with Dsplayer and MadVR working.
I have a 1050TI gtx, My current windows build is 1809, and i'm using Nvidia driver 385.28. This combination allows me to watch HDR videos within kodi 17.6 dsplayer madvr with it auto switching to HDR when the film starts and ends. I also have it set to change the refresh rate to 24hz (my tv is a native 120hz tv)
The issue i'm having is i'm noticing some banding on certain tv shows. When i watch them on my PC (RTX 2070 SUPER) I don't see the banding. This leads me to believe it's something to do with the Nvidia drivers as I don't have any banding when i watch Tv or play video games.
On windows build 1809 I also attempted to use the following drivers with the results below:
441.66 (hdr doesn't switch off when video ends and video flickers)
441.87 (hdr switches off when video ends but video flickers)
442.19 (hdr switches off but video flickers)
442.50 (hdr doesn't switch off - video flickers)
442.72 (hdr doesn't switch off - video flickers)
456.71 (hdr doesn't switch off - no flickering)
Originally I had the latest windows build, 2004 with the latest nvidia driver installed, but it wasn't switching the HDR on when watching HDR content - so i went back to 1809.
I hope i've provided enough information for someone to chime in with their experience or a possible solution. Thank you for your time and have a nice weekend folks.
Is there a version of windows that works best with a combination of nvidia drivers for Kodi 17.6 with dsplayer and madvr?
chros
7th November 2020, 10:22
The issue i'm having is i'm noticing some banding on certain tv shows. When i watch them on my PC (RTX 2070 SUPER) I don't see the banding. This leads me to believe it's something to do with the Nvidia drivers as I don't have any banding when i watch Tv or play video games.
What TV is it and when you say "on the PC" is it also connected to the same TV or a different monitor?
If not then I bet it's the TV :)
On windows build 1809 I also attempted to use the following drivers with the results below:
441.66 (hdr doesn't switch off when video ends and video flickers)
441.87 (hdr switches off when video ends but video flickers)
442.19 (hdr switches off but video flickers)
442.50 (hdr doesn't switch off - video flickers)
442.72 (hdr doesn't switch off - video flickers)
456.71 (hdr doesn't switch off - no flickering)
I can confirm your findings, as I mentioned here:
Just a short note (I'll write more later), the 442.74 doesn't change hdr metadata without restarting the player!
I went through lot of drivers (about 10 of them), including the last one and none of them is perfect.
So I went back to the good old 385.28 with the old pascal card.
Here is a bit more details on Win10 1809 with a 1060 6GB:
- 385.28 - 398.11:
-- almost all is good, except for multimonitor support is broken after sleep :) (newer drivers fix this so something was changed in Win10)
- 398.36 - 425.31:
-- HDR output with bogus metadata
- 430.53 - 442.74:
-- HDR output metadata is only correct when the first HDR video is launched in the same player!!! If you open another one in the same player metadata doesn't get changed! (it means you can't test/compare anything with madvr anymore)
- 442.92:
-- same as above
-- plus sometimes SDR video stuck in HDR after playing it in the same player after an HDR video (reboot fixes the issue for a short time)
- 456.71:
-- finally correct metadata again all the time
-- weird washed out colors and glitches upon UI interaction with HDR video (right click, when interface is up, etc)
-- and the above mentioned SDR video stuck in HDR straight away
So, this is where we are: this is completely unacceptable :)
Note that I mentioned "HDR ouput" and not passthrough (madvr pixelshader is used most of the time in my case).
So I went back to 385.28 and tried to "fix" the broken multimonitor support:
- this is how it should work: when playback is on TV, PC switches TV off then PC goes to sleep, then after waking up the monitor should be use automatically
- what happens instead: for whatever reason after waking up, the TV is still used as the audio device and not the AVR! And this doesn't happen if I switch off the TV without putting the PC to sleep!
So, that told me it's some timing issue. So what I did was added extra delay between switching the TV off and sleep. But due to how Oled compensation cycles work (TV doesn't get actually turned off until the comp cycle is finished), I had to add 9 minutes instead of 30 seconds :D And of course this doesn't handle the big 1 hour comp cycle :D
This is the final script that works like a charm:
cd d:\Progs\MPC-BE\
mpc-be64.exe && aiopylgtvcommand 192.168.1.78 power_off && timeout 540 && C:\Windows\psshutdown.exe -d -t 00
peacetalks
7th November 2020, 20:41
[QUOTE=chros;1927705]What TV is it and when you say "on the PC" is it also connected to the same TV or a different monitor?
If not then I bet it's the TV :)
It's a Vizio M65-F0, It's connecting to my receiver (Onkyo NR-777) and my PC is connected to the receiver. I've set everything up in the Nvidia control panel, as well as MADVR and Kodi as guides have suggested.
MY 2070 Super RTX is connected to a different screen (Asus Predator XB271HU) So maybe you are right and it is my TV? I tried doing a banding test (http://www.lagom.nl/lcd-test/gradient.php) on my HTPC connected to my TV and I didn't get the "Banding Bad Monitor" affect.
Also thank you for taking the time and providing all that information in your last response. I really appreciate it.
Is there another recommended build of windows 10/Nvidia driver combo that has better results than 1809/385.28?
Thanks again and have a great weekend.
webbo
8th November 2020, 15:15
One more question, please
Updated from 442.74 to latest driver version 457.09 without checking the "clean install" box.
I was experiencing freezes in PotPlayer (madVR) , SDR playbacks as well as HDR
Freezes, meaning, complete PC freezes, had to hard-reset the PC to be able to use it again
Did anyone else experience this or had this something to do with my "dirty" installation?
Is the clean install option always recommended?
Reverted to 442.74 - for the time being, safety measure :)
SamuriHL
8th November 2020, 18:31
When moving between branches I typically clean install and reset my settings. There's only a handful of things I change so going in there after a clean install doesn't take long. Make sure on older drivers to set the power option to optimal. That's one area that can cause....issues.
EDIT: Oops....that was meant to say switch the power option from optimal to adaptive. I've not slept well for the past few days for some....odd....reason. LOL
VBB
8th November 2020, 20:19
I always do a clean install, and then adjust the few things necessary after. If you don't game and don't have any other issues with your card, there's really only the refresh rate and color space/bit depth to potentially mess with. With the latest drivers, I find that changing the power setting from "optimal" to "adaptive" is no longer necessary. YMMV.
SamuriHL
8th November 2020, 20:54
yes, on the latest driver versions the Power setting can be left alone. But for older drivers, you definitely want to change that to avoid issues. As for clean installing the driver, it never hurts to do so. And in fact, we've seen MANY cases where NOT doing it causes problems with left over settings that didn't get cleaned up properly by the installer. So, I could go with the always advice.
jkauff
9th November 2020, 08:57
I haven't seen it mentioned here lately, but the free utility DDU will do a more thorough driver uninstall than Nvidia's clean install. Sometimes useful if you're still having driver problems after a clean install.
webbo
9th November 2020, 09:26
One more question, please
Updated from 442.74 to latest driver version 457.09 without checking the "clean install" box.
I was experiencing freezes in PotPlayer (madVR) , SDR playbacks as well as HDR
Freezes, meaning, complete PC freezes, had to hard-reset the PC to be able to use it again
Did anyone else experience this or had this something to do with my "dirty" installation?
Is the clean install option always recommended?
Reverted to 442.74 - for the time being, safety measure :)
Well, still having the same issue and it's getting definately annoying, because I've never had these problems for more than 2 years of madVR usage.
MadVR appears to be freezing the whole playback & PC when doing tonemapping using pixel shaders settiong (for 4K HDR playback)
When playing SDR titles, everything seems fine. No crashes
On 457.09 right now
The scenario is almost identical to http://bugs.madshi.net/view.php?id=553
I haven't seen it mentioned here lately, but the free utility DDU will do a more thorough driver uninstall than Nvidia's clean install. Sometimes useful if you're still having driver problems after a clean install.
Ok, thanks, I will surely try this one too.
chros
9th November 2020, 10:29
It's a Vizio M65-F0, It's connecting to my receiver (Onkyo NR-777) and my PC is connected to the receiver. I've set everything up in the Nvidia control panel, as well as MADVR and Kodi as guides have suggested.
...
MY 2070 Super RTX is connected to a different screen (Asus Predator XB271HU) So maybe you are right and it is my TV?
...
Is there another recommended build of windows 10/Nvidia driver combo that has better results than 1809/385.28?
Yes, it can easily happen that the TV is the culprit (as with LG Oleds in PC mode). If you can move the 2070S PC to the TV then you can easily try this out.
As you can see above, I don't think so (although I haven't tried newer Win10 versions).
385.28:
- is perfect with 1607 LTSB (there's no OS HDR option yet)
- "only" has the multimonitor issue with 1809, but if you don't care about this then it's fine as well
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.