Log in

View Full Version : AMD, Intel and Nvidia driver issues and last recommended version


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

Calvi
12th September 2019, 02:39
elFilou: Thanks, you are right, that's the one setting I hadn't tried yet. Assumed it wouldn't be relevant for 25fps content. Should never assume anything.

If I disable IVTC then DXVA2 CB does handle the rolling balls correctly. There is still a difference to CUVID though. There is shimmering (as you mentioned) most noticeable in the broadcast logo, especially if you pause or resume, or frame by frame. Its there at playback speed though as well.
This does not happen with CUVID with IVTC ON or OFF so I'm still getting a different (and better) result with CUVID.

You are right that I don't have a lot of need for IVTC being in Australia as most of our content is PAL and some derivative of 25fps. Of course there may be cases where I get a video that is converted from NTSC but this in unlikely to be something I am too fussed about picture quality.

Your observations with Radeon are identical to mine. It's a bit late to detect the first ball and the same on the last (would be because of the delay for the last ball to appear).

huhn: Possibly IVTC is broken in CUVID as turning it On or OFF makes no difference to the result (on this source).
I would need to try a source that requires IVTC to verify this.

IF DVXA2 CB needs IVTC off to work properly and CUVID can't do IVTC (not confirmed) but de-interlaces better than DXVA2 CB then I am still staying with CUVID for my sources.

My whole reason for starting this discussion is that I had read that CUVID and DXVA2 CB use identical de-interlacing firmware and that CUVID was no longer recommended so I tried converting over to DXVA2 CB but was not getting the same results.

Perhaps it would be good for Nev to check this out and I am all for the switch to NVDec if it gives the best of both worlds.

I will add though the power saving of DXVA2 over CUVID is overstated if using MadVR to near max the card as this will end up using the same power anyway. If not using MadVR then DXVA2 will be a fair bit more efficient as it throttles the clock much more aggressively.

On the flip side CUVID changes clock frequencies in huge steps and stays stable with fluctuating loads so the need to change the driver from optimal to power-adaptive etc is also not required.

huhn
12th September 2019, 02:55
NVDEC is just a repack CUVID.

nvidia can't IVTC(or noone has an implementation of it) it is just there name it will not recreate the original frame rate.

el Filou
12th September 2019, 19:53
You mean it doesn't decimate?
I feel like we've had this same discussion before, but with 25 PsF content even if it doesn't decimate I definitely see a difference when I check the 'use ivtc' box or not (I remember watching a HD stand-up show with colored metallic ribbons in the background, and the shimmering was horrible with ivtc off), so it's at least detecting the 2:2 cadence. I don't know for the others.

huhn
12th September 2019, 20:50
i didn't say it doesn't do anything. 60i in gives 60p out with that setting or without.

Klaus1189
13th September 2019, 07:59
AMD released new Radeon Driver 19.9.2

Klaus1189
16th September 2019, 10:19
I have found some typos in Radeon driver and already submitted them to AMD, but it isn't fixed yet. Here you can see screenshots of these two typos:
"% 2" has to be "%2", so there is one space, where it shouldn't be and the wildcard doesn't work (https://drive.google.com/file/d/1ZV6cmqWHkWm6FfhIZK7Y-Lwe6lVrXp6_/view?usp=sharing)
"Zurücksetzten" has to be "Zurücksetzen", so there is one "t" too much (https://drive.google.com/file/d/1zdnT9yjAz3uYsRruECmFCrcVOg7ZMWAI/view?usp=sharing)

What else can I do to reach the real people who are programming or translating that?

el Filou
16th September 2019, 11:15
AMD Forums?

janos666
20th September 2019, 21:17
I have some kind of tinted banding with Win10 18362.356 and Geforce 436.30 while having the Calibration Loader disabled in Task Scheduler.
Everything is fine as long as I keep the Desktop in SDR mode but some elusive magenta tinted posterization shows up on certain scenes if I switch to HDR mode which persists until a reboot.
Using madVR with NVAPI HDR doesn't trigger this bug, only Win10 HDR does (and no other software is needed, simply flipping the HDR switch does the trick).
I only notice this magenta thingy on HDR content but I guess it's always there (just even less visible). But strangely enough it's not obvious to spot. W,R,G,B,C,M,Y gradient ramps look mostly fine (nothing is ever completely *perfect* but none of these look obviously broken). Most of the scenes in any random movie look fine until some problematic shades bring this out (but then it's clearly noticeable because grayish shades tend to turn into a distinctly magenta shade...).
I am not sure when this started because I didn't use the OS HDR mode. I recently started using the Netflix app from the Windows Store and that requires the OS HDR mode for HDR content. That's when the problems started (and it was hard to figure out where it comes from).

Klaus1189
21st September 2019, 08:40
Did it came with Windows update? Are/Were previous drivers also affected?

janos666
21st September 2019, 11:32
Did it came with Windows update? Are/Were previous drivers also affected?

Unfortunately, I can't tell. I preferred to use madVR with NVAPI HDR for the sheer convenience of seamless auto-switching (these days the transition happens without any flashing to black or noisy screen, it's really neat).
The sole reason I started flipping that Win10 HDR switch was the Netflix app. (I used to go for the TV's built-in app but that's harcdoded to use DolbyVision for HDR and the TV's latest firmware has some tone response curve issues in DolbyVision mode, so I tried to get around that with the Win10 app which is HDR10-only...).
The only other time I flipped this switch (or more precisely: had it toggled automatically for me by a user software) was when I played an HDR video game (Anthem doesn't support NVAPI HDR, or even DolbyVision for that matter). But I didn't play that game since late July and this is so subtle and elusive that I doubt I could even spot this in a colorful sci-fi game (it could easily look like a poorly compressed texture or strange design choice of colors in that context).

Edit: Well... It's worse than I thought. I decided to try taking some photos (NV / OS comparison) to show how it looks like but the magenta tint was already there with NVAPI! I am sure nothing triggered the Win10 HDR mode since the last reboot. I didn't mess with anything in the Win10 Settings. The only change was the switch from 60 Hz 8bit to 23 Hz 12bit in NVCP. Yesterday I kept rebooting with 23Hz 12bit.

Anyways, here are some bad quality photos (-> see the attachments below). It looks worse in real view. Look at the outlines of the white clouds. I saw something similar in a different movie on white shirts in dark rooms.
Even now, I don't see any anomalies on the SDR desktop (I am using this same TV as a PC monitor to type this) and I don't see anything similar on gray ramp test patterns either (neither in SDR, nor in HDR mode). I think it affects a limited amount of shades close to white (but not quite exactly pure white).

Edit2: Ridiculous.
- I didn't even reboot, just switched back to 60Hz 8bit, then launched MPC-HC again with the same movie. madVR automatically switched to 23Hz and the bit depth automatically flipped to 12bit (this is the expected behavior if that resolution+refresh mode was used with 12bit earlier) and there is no magenta tint on the clouds now.
- Then I switched the Windows Desktop to HDR (while in 60Hz 8bit) and there is still no tinting (madVR yet again switched to 23Hz and 12bit came along with it).
- Finally, I switched the display from 60Hz 8bit to 23Hz 12bit manually from NVCP (with Win10 HDR mode ON), launched MPC-HC (obviously there was no display mode switching by madVR now) and the clouds show tinting again. The same thing happens if I switch to 23Hz from Window's advanced display settings (so it's not NVCP but the NV driver or the OS).

Workaround (a stupid one): set the desktop to 60Hz 8bit, toggle Win10 HDR, start MPC-HC to get madVR switching to 23Hz (and 12bit along with it), start the Netflix app and watch HDR content. (LOL)

Klaus1189
22nd September 2019, 11:45
AMD Forums?

Thanks, I registered and posted it there:
https://community.amd.com/thread/243762

janos666
22nd September 2019, 17:57
I checked my AMD Vega based notebook (2500U with 19.9.2) with the same TV and it's worse than the nVidia Pascal (GTX1070) based desktop PC. The AMD one doesn't show distinct magenta tinting but the banding is much worse (at least with >8bit) and something is wrong with the HDR10 color gamut (wrong metadata?). The colors are much less saturated than they should be (faces look pale, etc).

By the way, the VGA calibration LUT is always set to something "fuzzy" after any changes are made to the Windows display settings (with the CalibrationLoader disabled in Task Scheduler) on both systems.
When it's a custom non-neutral but smooth curve then the graph plot of DisplayCAL starts showing a lot of aliasing (it gets distorted each time I apply a change in Windows display settings but smooths out again if I reload the curve with DisplayCAL).
When it's neutral (no custom ICM profile) the plot looks mostly fine, except it's slightly drifted: 255 maps to 254.1, etc. (This is not so crazy but still clearly distorted.)
But this disturbed LUT is not the only issue. The banding remains after I manually clear the LUT with DisplayCAL. This is just yet another bug (although they might be related).

I initially thought the common denominator will either be <60Hz or >8bit (applied manually from Windows display settings) but it's not so easy. The AMD system doesn't seem to care about these (although the banding is much worse with 12bit than 8bit but that's probably just AMD's always-on dithering).
The color saturation bug (AMD only) seems to require some "trigger" to get stuck (but I didn't pinpoint this yet, it's probably a switch to HDR10 mode with either Win10's or AMD's private API, I am not sure yet).

This is incredible. Several months have passed and 1903 is still garbage. And they didn't even have a real 1909 to work on.
I decided to switch the notebook to the Fast ring and see how that goes. -> No luck, the current 20H1 build behaves the same way on the AMD system (I already rolled the update back).

Edit: This never ceases to amuse... TV nVidia PC lost the magenta tint (which only appeared in certain display modes) when I switched the LAV Video Decoder from DXVA2(native) to D3D11(native). But I didn't find any working option for the AMD system (that one has much more serious banding, that's something else).

Asmodian
23rd September 2019, 23:56
Thanks for the diagnostics on these very odd and evil issues with 1903! :thanks:

chros
24th September 2019, 10:06
Edit: This never ceases to amuse... TV nVidia PC lost the magenta tint (which only appeared in certain display modes) when I switched the LAV Video Decoder from DXVA2(native) to D3D11(native).
That's interesting.
Anyway, just use D3D11(native) in LAV with madvr, it's the fastest (https://forum.doom9.org/showthread.php?p=1878815#post1878815) mode.

el Filou
24th September 2019, 11:08
@janos666 which build of madVR are you using, and are you doing passthrough or processing?
I just tried DXVA2 native because I found it strange that it would give different rendering results (I never use it due to NVIDIA lossy issue), and noticed that at least with beta test build 86 it skips some HDR rendering steps (and gains alot of time in the process!).

With D3D11VA native it's (2160 to 1080 with scale chroma separately and full HDR processing including highlights recovery):

1. DXVA11 Interop
2. Image downscaling
3. HDR Blur Dif; Blur; Frequency Split
4. Chroma
5. rest of HDR processing
6. HDR Final
7. Final Step

With DXVA2 native, apart from step 1 that is obviously replaced by something DXVA2-specific, madVR completely skips steps 3 and 6 (which I think have to do with highlights recovery).

janos666
24th September 2019, 23:37
@el Filou - v0.92.17 (the public build from the neighbor topic), passthrough (metadata included), minimalist setup (no post-process filters or overly fancy resamplers). I am not sure why I had LAV set to DVXV2, I guess I kept flipping it around while fighting the old Win10 1903 banding issue (with the Calibration Loader) and forgot about it.
NVIDIA lossy issue - Hmm? Is DX11 supposed to be of higher quality? I didn't use the DXVA2 resampler (in madVR's settings) if that's what you mean, I am aware that's broken (results in visible color luminance errors).

huhn
25th September 2019, 00:23
DXVA2 native and only native lowers image quality the rest is bit perfect.

Klaus1189
25th September 2019, 16:01
AMD Radeon driver 19.9.2 is available as Recommended (WHQL)
@RX 5700 (XT) card owners: Does this driver run without issues like BSOD for RX 5700 (XT) cards?

huhn
25th September 2019, 16:27
the main BSOD problem was the hardware acceleration one that's "fixed".
now the driver crashes instead and usually recovers.

this is still in the known "issues":
"Discord™ may experience an application hang on Radeon RX 5700 series graphics products when HW acceleration is enabled."

things that some people help are.
don't use PCIe 4.0.
don't use 240hz and at best only 60hz.
use abba if available why this should have anything todo with the GPU i don't even wanna known.
use 1903 or newer see just a couple of post a top.

there are system that in general run that's usually a single 60 hz system.
that's the same driver with WHQL which is not worth much these days.

Klaus1189
26th September 2019, 17:41
@GTPVHD: I want to create the Intel list but I must admit that I don't get the version numbering sheme of Intel and what chip is supported in each of the long version numbers. If you want you can create a short list and point me in the right direction, for example all version xx.xx are only for this chip / generation of intel processors.

GTPVHD
26th September 2019, 19:40
https://www.intel.com/content/www/us/en/support/articles/000005654/graphics-drivers.html

I don't know if this is enough to help you, but you can try reading it.

The version number will increase to 27.20.100.7xxx in the future because the next 1909 release of Win10 will be WDDM 2.7.

huhn
26th September 2019, 21:48
as far as i know a new WDDM version isn't planned.
the next update that is planned for this month is not like the others.

they are slowing it a bit down with the live releases and i hope do more quality control which i think is the right direction as long as new insider builds are provided.

janos666
27th September 2019, 00:53
An updated 1903 is already 1909 with a few (unintresting) features disabled (a ~20kb update can enable those). 20H1 is also available for testing (with WDDM 2.7) but it seems to be the same as far as these graphics quality problems go (although I didn't see any WDDM 2.7 drivers from AMD yet).

huhn
28th September 2019, 18:11
But in driver 19.9.2 the pixelformat is "RGB 4:4:4 Full RGB" ("4:4:4" for those who don't know that RGB is always without chroma subsampling.)
But madVR and VMR 9 windowed is fine. Strange, at least for my understanding.

not related to it. the GPU driver always assumes the windows desktop is full range (and that the video that is rendered there is too). so it only means full range RGB do "nothing" and limited range do a full range to limited range conversation.

this is an example for nvidia which effects EVR: https://abload.de/img/videorangeplkyj.png

Klaus1189
28th September 2019, 18:15
OK, thanks for the info. But I nevertheless don't understand why only EVR and EVR custom presenter is affected.

huhn
28th September 2019, 18:19
they use DXVA processing so the GPU driver is in charge of YCbCr -> RGB conversation and if that it done to limited range and not fixed later it will be washed out.

if you have the issue with nvidia you can change the showed setting and force it to full range.

you can try the mpc renderer settings output and change the range to full range.

janos666
28th September 2019, 18:22
OK, thanks for the info. But I nevertheless don't understand why only EVR and EVR custom presenter is affected.

madVR is also affected if you enable the "trust DXVA color & levels conversion" performance option (and I guess this obviously needs DXVA2 decoding, but I am not sure if it applies to native only or copy-back as well, I also never tested this with D3D11 decoding) but it used to cause issues with HDR10 videos (the last time around I tried it, roughly 1-2 years ago).

Klaus1189
28th September 2019, 18:23
If you are referring to the videorender page in options in both MPC-BE and MPC-HC, it is already set to 0-255, I already tried to set it to 16-235, if it changes anything, but it did nothing.

Klaus1189
28th September 2019, 18:26
madVR is also affected if you enable the "trust DXVA color & levels conversion"

Thanks, I tried it but madVR is still fine. :confused:

janos666
28th September 2019, 18:26
If you are referring to the videorender page in options in both MPC-BE and MPC-HC, it is already set to 0-255, I already tried to set it to 16-235, if it changes anything, but it did nothing.

No, this one (-> see the attached image below).

Thanks, I tried it but madVR is still fine. :confused:
Did you try both NVCP choices while having this madVR option enabled and the decoder set to DXVA2 Native? (Things might have changed over the last year...)

Klaus1189
28th September 2019, 18:30
Sorry post #640 was referring to huhn.
@janos666: I found it in madVR -> rendering -> trade quality for performance -> 2nd last feature. (I can not open your pic, because: "Attachments Pending Approval")
But as in #641 already posted, it is still fine, which I also don't understand.

huhn
28th September 2019, 21:22
with my RX 5700 XT i'm limited to limited range too.

looks like AMD dropped the ball again.
the rendering output range is ignored.

janos666
28th September 2019, 23:27
So, it turns out the heavy banding on the AMD Vega based notebook was also caused by the DXVA2 Native setting in LAV (I still can't remember why I set both to DXVA2, though I didn't know it was known to be fundamentally broken quality wise). The video image is clean with D3D11.
However, the color space metadata bug is unrelated and random. I found the signal info banner on the TV OSD (click anywhere once and then click on the HDMI icon on the top-left corner for LG) and "rec2020" disappears from the list when I see unsaturated colors. It seems to happen with both the AMD private API (madVR) and the Win10 HDR desktop modes (same movie file, the madVR OSD shows clearly recognized Rec2020 but even the converted Windows desktop GUI colors look off, so...). The latter is 50/50 (sometimes it's fine, other times it's off) but I don't remember seeing correct colors with the former (could be a coincidence or the private API is still useless, it was also obviously very dark with older drivers all the time).

Klaus1189
29th September 2019, 09:08
with my RX 5700 XT i'm limited to limited range too.

looks like AMD dropped the ball again.
the rendering output range is ignored.

I going to make a thread at AMD forum, but I am not sure how to make it 100% clear for the devs what exact range in the driver is affected. Can you help me finding the right descripion for this issue?

What I got now is that the "video output range setting" outputs 16-235 regardless what is selected 0-255 or 16-235. Note: It is not the output setting of the pixelformat.

huhn
29th September 2019, 09:45
words are not my strong point.

the pixel format should be ignored it should always been outputted as full range from the video renderer even if the pixel format is set to limited or it will not match.

the problem doesn't trigger with the windows movie app so that hints that it is a directshow issue because it looks like it works with media foundation.

thanks to mpcVR(i use an old version) we get another hint that it is coupled with DXVA2 processing because it works fine with D3D11 processing.

the next problem is that this is a video issue and these companies usually don't really care about this as long as there is an image. the 5700 series is a just a driver nightmare i would say they have more important things to do.

so i would use something like:
videos are outputted in limited range in a directshow video player when DXVA2 processing is used.

for example play a video using MPC-HC using the default enhanced video renderer (custom presenter) the output range will be limited.

driver version card.
and add an dxdiag they love these like candy.
finding the driver where they broke this wouldn't be bad too.

Klaus1189
29th September 2019, 09:45
I just tested MPC Video Renderer with MPC-BE and it is also affected in standard settings:
DirectX 9
Graphics adapter: AMD Radeon RX 5700 XT (1002:731F)
VideoProcessor : DXVA2 ProgressiveDevice
DeinterlaceTechnology: none
Display Mode : 3840 x 2160, 59 Hz

But when checking Use Direct3D it looks fine to me:
DirectX 11
Graphics adapter: AMD Radeon RX 5700 XT (1002:731F)
VideoProcessor : D3D11

Klaus1189
29th September 2019, 09:47
thanks to mpcVR(i use an old version) we get another hint that it is coupled with DXVA2 processing because it works fine with D3D11 processing.

Yes ;)

huhn
30th September 2019, 09:56
just to add more to the fire they broke yet again deinterlancing on my system too.

so we currently have wrong ranges in DXVA2 "processing" NN as an "de"interlacer truncated 10 bit to 8 bit DXVA2 native decoding.

Klaus1189
30th September 2019, 16:00
"de"interlacer truncated 10 bit to 8 bit DXVA2 native decoding.

Sorry, but I don't get that, can you please explain it so I can decribe it deeply on the AMD forum?



I just browsed on YouTube and came across the following videos:
https://www.youtube.com/watch?v=_rxFxdvO3fQ
https://www.youtube.com/watch?v=TY4s35uULg4

Could this method help Nvidia users to get more accurate 23 Hz timings out of the box?
And perhaps can then the madVR image processing be done in the Nvidia card and Framepacked 3D be sent over an AMD card or perhaps an Intel iGPU which lots of users also have already in their HTPC.
Just an idea, but perhaps it is helpful ...

huhn
30th September 2019, 18:47
i already talked and tested this.

yes it can be done when windows allows you to and it is dodge as hell.

about the decoding issue with native will try to make screens and such but this is a very old issue pretty much ignored because it is DXVA2 native which has issues with madVR in general.

Klaus1189
30th September 2019, 19:54
What do you mean with dodge?

huhn
30th September 2019, 19:57
dodgy.

it hard to pull of and may not work at all.

Klaus1189
30th September 2019, 20:36
So hard to setup and unreliable? I am sure you are from Germany, so a german description will help me understand the drawbacks better.

And of course two different drivers with all its broken features at the same time...

Looking forward for your screenshots when you have time. Do not rush.

huhn
30th September 2019, 21:33
mein deutsch ist auch mist. das ganze ist monate her ich muss denn post finden.

the 10 bit DXVA native bug was easy to test.
the here used test has rounded or truncated 8 bit at the bottom half the top is 10 bit and looks like it is dithered too:
software decoding: https://abload.de/img/amddxvabug2bqkm5.png
DXVA2 native: https://abload.de/img/amddxvanativebug4gkwu.png

source file: https://www.avsforum.com/forum/139-display-calibration/2269338-10-bit-gradient-test-patterns.html

Klaus1189
1st October 2019, 09:44
AMD released new Radeon Driver 19.9.3

grendelrt
3rd October 2019, 14:56
Does anyone know if the bug where forcing the BT2020 flag for Nvidia not clearing correctly for 709 content was ever fixed? I never knew if it was on the Nvidia side or the MadVR side. I know Manni confirmed the issue back when I posted it in May. Here is my original post from back then:


I have a weird issue. I used the report 2020 to display option to do some testing, and now even when I am on the desktop and in SDR on 709 material, my display is still getting reported BT2020. If I switch sources to my Oppo player it clears, but no matter what I do now on my computer it is stuck sending the BT2020 flag. Is there any way to clear this?

Edit: A full DDU uninstall of the drivers seemed to have fixed it. Isnt that option supposed to work as a toggle though? If I uncheck it, shouldnt it turn that flag off that nvidia is sending?

grendelrt
4th October 2019, 13:38
Does anyone know if the bug where forcing the BT2020 flag for Nvidia not clearing correctly for 709 content was ever fixed? I never knew if it was on the Nvidia side or the MadVR side. I know Manni confirmed the issue back when I posted it in May. Here is my original post from back then:

Follow up on my own post, not sure if it was fixed in drivers or a madvr build (prob drivers since I dont update madvr a lot) but the newest nvidia drivers do not have this bug. I gave it a shot yesterday.

webbo
4th October 2019, 20:38
Hello

436.48 nVidia Driver - is it "okay" for HDR Passthrough for 4K HDR movies?
I simply can't use the old 430.39 - my games keep closing, hardly playable
Any reply / thoughts are welcome

Thank you very much

Asmodian
4th October 2019, 23:53
I have been successful with HDR passthrough on my LG C9 with 436.48.

Klaus1189
5th October 2019, 08:35
Is exclusive mode required or is windowed mode sufficient for HDR passthrough with Nvidia 436.48?