AMD, Intel and Nvidia driver issues and last recommended version [Archive] - Page 3

Manni

17th March 2019, 20:43

It could be that Windows decides what are the min/max/avg luminance values that will be used for the tonemapping of the entire Windows desktop, and that's the value that gets reported to the display. The video player's advertised values will only be used to render the video player output properly in this shared desktop backbuffer.

Seeing it like this, the label of "passthrough" in madVR is a bit misleading, because madVR does not control what the compositing engine does. It's meaning is more like "madVR will not tonemap the material itself, and will specify for the swapchain the HDR metadata values of the stream" but then Windows decides what happens with this.

The point is that Windows should have no influence on the content when we're not using the OS HDR implementation. Whether in a game or madVR, as long as the nVidia HDR API is used and not the OS, there is zero reason for the OS to be involved.

Passthrough in madVR isn't misleading. If madVR isn't doing the tonemapping, it either reports to the display the original metadata (no measurements files) or the optimized metadata. You can ignore the measurements files if you want to keep them but not use them. The OS has nothing to do with this, and up until 398.11, it stays out of the process, as it should.

If it's not a bug, it's certainly not desired for the OS to interfere with the content.

If you're using the OS HDR, sure, but not if the player/game is using the NV HDR API.

I certainly hope that this bug is fixed. MS can do whatever they want with their HDR implementation, which isn't useful for a video player unless you want to convert everything to HDR. This isn't an option for projector users as you can't use the same calibration for SDR and HDR without losing a lot of performance.

By the way I went back to 397.93 because 398.11 occasionally leads my projector to detect HDR when I send SDR WCG. So for me the latest usable driver (as long as I want proper passthrough) is 397.93.

KoD

17th March 2019, 21:15

Manni

17th March 2019, 21:49

My understanding is that the manufacturer-specific APIs for HDR are to be deprecated after HDR support was made official in Windows.

What support exists will not be removed because there are games which were made before HDR support was made official in Windows by Microsoft, but I guess they don't care to properly support it anymore. The DV stuff is certainly only possible by using the graphic card manufacturer APIs, however.

This is not what Madshi has reported. He has discussed the issue with his contact at nVidia and is expecting it to be resolved.

Nevcairiel (developper of LAV) said a bit earlier in the thread that it might be fixed in the next major branch in April.

If you don't have any solid information, please refrain from posting :)

KoD

18th March 2019, 21:38

This is not what Madshi has reported. He has discussed the issue with his contact at nVidia and is expecting it to be resolved.

Nevcairiel (developper of LAV) said a bit earlier in the thread that it might be fixed in the next major branch in April.

If you don't have any solid information, please refrain from posting :)

What exactly did you find to be wrong in what I wrote, that you felt the need to tell me to refrain from posting?

I think I posted references for what I said in this thread, btw.

Manni

18th March 2019, 22:24

What exactly did you find to be wrong in what I wrote, that you felt the need to tell me to refrain from posting?

I think I posted references for what I said in this thread, btw.

You directly contradicted what two of the most influential developers (Madshi and Nevcairiel) had already stated, by suggesting that the issue with metadata passthrough might not be a bug or might even be desirable (it is a bug and it isn't desirable), and that the API support will be deprecated (it won't and the bug is expected to be fixed in the next major branch release). You also questioned the data that I've produced with the Maestro. The references you posted where not relevant for various reasons, which I explained. That's confusing and unhelpful. Have you read the thread, including the last few pages, or are you just posting randomly?

But if you want to keep posting on the subject, please go on, it's a free forum :)

nevcairiel

18th March 2019, 22:50

Actually I never stated any such thing. I actually think it would be beneficial to try to work with the OS, instead of around it.

huhn

18th March 2019, 23:21

the point is a bug like this is unlikely to be fixed in a new driver which is mostly made for some new games unlike a new branch driver.

the nvidia HDR api is unlikely to leave anytime soon unlike 3D vision none windows 10 gaming isn't dead yet and the dx12 support for win 7 clearly shows old OS still matter so the API is still needed.

SamuriHL

18th March 2019, 23:30

Actually I never stated any such thing. I actually think it would be beneficial to try to work with the OS, instead of around it.

Come on, you know you want to write some test code and send it to Manni so he can see if the metadata is being sent correctly. :P :D

Manni

19th March 2019, 00:13

Actually I never stated any such thing. I actually think it would be beneficial to try to work with the OS, instead of around it.

You didn't say in this very thread a few pages back that the HDR passthrough metadata bug with NV HDR might be fixed in the next major branch? :confused::eek::confused:

Though it is true that you said you had a preference for things to work with the OS instead of around it. That doesn't mean that the NV API bug isn't a bug, or I completely misunderstood what you said.

Come on, you know you want to write some test code and send it to Manni so he can see if the metadata is being sent correctly. :P :D

I offered to send a Vertex to Nevcairiel so that he could do all his tests but for some reason he didn't seem interested.

nevcairiel

19th March 2019, 00:30

You didn't say in this very thread a few pages back that the HDR passthrough metadata bug with NV HDR might be fixed in the next major branch? :confused::eek::confused:

What I meant to say was that IF such a fix is coming, it would be in a new major branch, and not some game-ready driver mid-branch.

I offered to send a Vertex to Nevcairiel so that he could do all his tests but for some reason he didn't seem interested.

I don't even have a HDR display currently, so that would probably be a bit fruitless.

Manni

19th March 2019, 17:13

What I meant to say was that IF such a fix is coming, it would be in a new major branch, and not some game-ready driver mid-branch.

Got it. Sorry I misunderstood / misquoted you. As madshi has already confirmed that 1) he has informed his contact at nVidia of the issue 2) that the NV API was not to be deprecated and 3) that a fix was on the way, I thought you were confirming when it was expected to be delivered.

I don't even have a HDR display currently, so that would probably be a bit fruitless.

OK. Let me know if that was to change.

Note that the Vertex is precisely meant for handling non HDR displays with HDR content. It can be configured to send the source any EDID, including telling it that the display is fully HDMI 2.0a / 600Mhz / HDR compliant. That allows you to get the source to send all the content and HDR metadata as if your display was HDR.

You can then configure the Vertex to strip the HDR metadata, so you can activate/select an SDR calibration on your non-HDR screen, as well as downconvert the output so that it fits the bandwidth limits of your screen (for example changing resolution, chroma or bit depth to fit a 300Mhz limit). It's basically an Integral and a Linker combined, with a few more things on top. The only thing it doesn't do is converting the frame rate (I used an X4 for that temporarily to drive a display that didn't support 23p, I can send it to you as well if you need that).

Yet, and that's the important part, you can still have the Vertex display in its OSD info the full incoming HDR metadata, even when it strips it so it doesn't reach your non HDR display. So you get to see exactly which HDR metadata a fully compliant HDR display would receive, even if you don't send it to your non-HDR display and downconvert/downscale the content for bandwidth or any other reason.

If this makes any difference and would allow you to run your tests, or if at any point you get a HDR display, please get in touch by PM/email, and my Vertex will be on your way (provided I still have it!). If it doesn't help, you can always send it back to me. If it helps, then you can keep it (as a gift). I'm not using it currently as it's been replaced by a Maestro.

If you don't need the decoded HDR metadata info on the OSD, I can send you my Integral (splitter) or my Linker (scaler). They give you the HDR infoframe in the GUI on a PC but they don't decode it (it's the raw data), so it's more time consuming for me to translate it, but it might suit a developper better! I also don't use them at the moment.

sat4all

21st March 2019, 10:26

Nvidia 419.67 Creator Ready Driver have been Released.
Going to check them tonight, maybe Manni will do first :D

huhn

21st March 2019, 10:29

did someone try this driver:
https://www.nvidia.com/download/driverResults.aspx/145411

this a driver with professional applications in mind like quadro cards.

this driver aims to improve workloads with video applications like adobe premiere pro so correct video playback should be far more important.

Manni

21st March 2019, 11:03

Nvidia 419.67 Creator Ready Driver have been Released.
Going to check them tonight, maybe Manni will do first :D

Not checking anything until the next major branch expected in April :)

[EDIT: unless someone reports any significant change, of course!]

chros

21st March 2019, 11:31

Not checking anything until the next major branch expected in April :)
Me neither until a new GPU/TV (which won't happen tomorrow) :D

j82k

21st March 2019, 13:37

Nvidia 419.67 Creator Ready Driver have been Released.
Going to check them tonight, maybe Manni will do first :D

- metadata still broken
- HDR still only trigger when madVR is set to 10-bit
- moving my mouse cursor disables HDR (this one is really annoying)

I surely won't be buying another nvidia card until this mess gets fixed....

sat4all

21st March 2019, 14:13

- metadata still broken
- HDR still only trigger when madVR is set to 10-bit
- moving my mouse cursor disables HDR (this one is really annoying)

I surely won't be buying another nvidia card until this mess gets fixed....

Thanks for reporting back, hopefully we get our fix in the next major branch which suppose to be released after Windows 10 april update aka 19H1.

XMonarchY

21st March 2019, 14:51

Thank You, guys, CRU 1.4.1 with DisplayID also solved my above mentioned issue. That's what I did:
- wrote down the madvr timings, removed the madvr created custom resolution, then restart
- in CRU 1.4.1
-- add DisplayID to Extension blocks and set it as the 1st entry
-- set madvr timings and set Pixel clock and Native as well

It's a big help to get rid of a major annoyance, now I can set 23p as the default refresh rate of the TV :)

Btw, I still use the Display Changer II (https://forum.doom9.org/showthread.php?p=1863306#post1863306) util to easily manage 2 displays.

I managed to get CRU to create proper refresh rate, but it also disappeared after a reboot... Oddly, DSR resolutions stick fine. The CRU-based resolution would disappear after reboot regardless of whether DSR was enabled or not. I didn't use Extension blocks though...

chros

21st March 2019, 15:43

I didn't use Extension blocks though...
Then use it :)

KoD

21st March 2019, 21:30

You directly contradicted what two of the most influential developers (Madshi and Nevcairiel) had already stated, by suggesting that the issue with metadata passthrough might not be a bug or might even be desirable (it is a bug and it isn't desirable), and that the API support will be deprecated (it won't and the bug is expected to be fixed in the next major branch release). You also questioned the data that I've produced with the Maestro. The references you posted where not relevant for various reasons, which I explained. That's confusing and unhelpful. Have you read the thread, including the last few pages, or are you just posting randomly?

But if you want to keep posting on the subject, please go on, it's a free forum :)

It would help if you would understand what I am saying.

The short version:
- applications that do not use fullscreen exclusive mode can not expect min/max/avg luminance values to be sent as-is to the display, because the Windows display compositor is the one that actually mixes the output of all the applications (some HDR, some SDR, each with their own settings) on a common surface, and the parameters of that surface are used to tonemap the content and get exposed to the display.
- an application which does use fullscreen exclusive mode however, might be entitled to expect its min/max/avg values to be the one advertised to the display; this is the only case where the issue may be seen as a bug.
- the presentation that I posted has the nVidia guy saying that turning HDR on changed with the release of Windows RedStone 2, which brought the initial HDR support in Windows; that doesn't mean the NvApi is not going to work anymore, but the path forward for proper support of HDR for windowed (borderless and not) applications is through the Windows DXGI API.
- I did not "question" in a malicious way what you did, as you seem to have interpreted it; I wanted a clarification out of curiosity; the explanation that the driver was simply advertising an avg luminance fit for your projector would have been simpler to explain the low 20 nits value you noticed; but since you added afterwards that you are getting the same with a display monitor, then this simple explanation is not true.

The references I have posted are very relevant and helpful. But you have to watch/read and understand them.

If madshi or nevcariel find what I said to be wrong, they can easily speak against it themselves. I doubt they will have much to speak against of, though.

Manni

21st March 2019, 21:45

It would help if you would understand what I am saying.

The short version:
- applications that do not use fullscreen exclusive mode can not expect min/max/avg luminance values to be sent as-is to the display, because the Windows display compositor is the one that actually mixes the output of all the applications (some HDR, some SDR, each with their own settings) on a common surface, and the parameters of that surface are used to tonemap the content and get exposed to the display.
- an application which does use fullscreen exclusive mode however, might be entitled to expect its min/max/avg values to be the one advertised to the display; this is the only case where the issue may be seen as a bug.
- the presentation that I posted has the nVidia guy saying that turning HDR on changed with the release of Windows RedStone 2, which brought the initial HDR support in Windows; that doesn't mean the NvApi is not going to work anymore, but the path forward for proper support of HDR for windowed (borderless and not) applications is through the Windows DXGI API.
- I did not "question" in a malicious way what you did, as you seem to have interpreted it; I wanted a clarification out of curiosity; the explanation that the driver was simply advertising an avg luminance fit for your projector would have been simpler to explain the low 20 nits value you noticed; but since you added afterwards that you are getting the same with a display monitor, then this simple explanation is not true.

The references I have posted are very relevant and helpful. But you have to watch/read and understand them.

If madshi or nevcariel find what I said to be wrong, they can easily speak against it themselves. I doubt they will have much to speak against of, though.

It looks like you are just dumping posts and not reading the thread, so I'm out :)

KoD

21st March 2019, 22:20

That... or you don't understand what I'm saying.

Manni

21st March 2019, 22:23

That... or you don't understand what I'm saying.

Sure. Still, I'm out :)

Klaus1189

25th March 2019, 16:27

What is the difference between these two?
419.67 GRD 2019-03-25
419.67 CRD 2019-03-20
The same version number suggests to me that it is completely the same, but I am not sure.
The GRD is WHQL, but other than that?

nevcairiel

25th March 2019, 16:31

Its the exact same driver. Its just marketing to advertise to both gamers and creators.

Asmodian

25th March 2019, 22:58

Nvidia hopefully has a slower QA group that tests the creator releases a bit more with such applications; both releases use the same development branch but the game driver is more likely to have a tweak for a particular game that unexpectedly hurts creative applications. The creative releases would be more stable but come out less often.

More cynically, I agree with nevcairiel, it is probably just a way to start including creative types in marking. Nvidia had been pretty exclusively marketing to gamers in the consumer space and science/engineering in the professional space.

Nicog

26th March 2019, 09:46

Hi,

Like a lot of RTX users I need to use FSE to avoid stuttering (which is very annoying with my videporjector because of HDR switch time - impossible to use top seekbar).

But with last drivers, even in FSE I had massive stuttering (419.37, 419.35 at least). I tryed almost everything with or without FSE I can find on the web.

Just before i wanted to put my RTX card on ebay, I tried 417.71 driver. And with this driver, it works in FSE (no stuttering).

Just to share my experience in case of someone has similar issue...

takenori

26th March 2019, 14:05

mpc-hc+madvr:
playing hdr video with the latest nvidia driver 419.67 resulted in sdr fallback after every overlay (volume, seekbar, rightclick) in fullscreen windowed mode.
before the update, the sdr fallback only happen when I quit the fullscreen windowed mode.

Nicog

28th March 2019, 21:40

hajosattila

29th March 2019, 20:51

425.11 (hotfix driver) massive stuttering... (RTX 2060/latest Win 10, MPC-HC, madVR)

Warner306

29th March 2019, 21:00

Maybe you should mention the stuttering issue only applies to RTX cards? Currently, it makes it appear like it applies to all Nvidia cards.

ryrynz

29th March 2019, 21:38

Indeed. I've experienced no issues on my 1060 and I update every release.

brazen1

29th March 2019, 21:44

Asmodian

30th March 2019, 00:00

I have been testing with 419.67 GRD, 2080 Ti, Win10 1809, Zoom Player, and madVR v0.92.17.

Now everything seems fine for me, HDR needs 10 bit to trigger but works without FSE. I get smooth playback at 24 and 60 Hz and I tested using 1080p24, 4Kp24, and 4Kp60 sources.

I started my testing today because I noticed some reproducible stutter. I already had 419.67 installed through GFE. I went to Nvidia's site and downloaded 419.67 CRD and did a clean install using that and after rebooting all the stutter went away. I then did the same with the GRD and nothing changed. I don't really have anything else to add, I tried to test a lot of stuff and I swear I noticed some reproducible bad behavior, but now I cannot reproduce any of if, everything looks good. :confused:

I was also worried about bad behavior of my 2017 LG C7 OLED at 24 Hz but all my testing today has convinced me that when accepting 8 bit RGB at 24 or 60 Hz, and with the input set to PC, I get proper playback out of it. 24 Hz isn't exactly smooth, of course, but I do not have any judder. :)

XMonarchY

30th March 2019, 23:11

Then use it :)

OK, awesome, it worked, the custom refresh rate now sticks, BUUUT... madVR does not auto-switch to it. The custom refresh rate is labeled as 24Hz, stands separate in NVidia CP, madVR refresh rate modes are set to "1080p23, 1080p24", and yet when 23/24hz is launched, madVR doesn't use the custom resolution, but switches to generic 23Hz...

When I press CTRL+J, what is the indicator that custom or correct refresh rate is used? I ask because even when I remove madVR "1080p23, 1080p24" refresh modes (leave that line blank) and just force it to use custom NVidia CP 24Hz refresh by selecting and applying it in NVidia CP, CTRL+J info seems identical to the ones shown for standard non-custom 23Hz... "1 frame skip every 10-12 minutes" or so...

Klaus1189

31st March 2019, 11:38

I agree with Warner above. Not only the differences between RTX and GTX cards should be noted but other important variables. I use my nVidia card for more than just one player. I think testers are just testing one or two players and passing driver reports off as perfect. For instance, using DVDFab Media Player, HDR stopped switching after driver version 416.81. Some of us use more than simply MPC-HC/BE. If this thread is exclusively for madVR compatible players only, you should state such imo. I use 5 players for example and only two are madVR compatible. 416.81 is fine with all of them. It should be noted 'fine' for video drivers. Audio drivers have been screwed up since 388.59. I edit the installer appropriately using the last fully working versions of each aside from the no 12 bit retention after a reboot issue that doesn't affect me. This is just nVidia. No idea AMD or Intel quirks but at least you've provided a gathering spot to share driver reports and this is mine.

OK, I added some info to the first post. If I did something wrong or missed anything, correct me and I update it.
As you wrote it, indeed there was an audio issue. I can remember now but I can't find the exact problem. Can you please post it here again?

I have been testing with 419.67 GRD, 2080 Ti, Win10 1809, Zoom Player, and madVR v0.92.17.

Now everything seems fine for me, HDR needs 10 bit to trigger but works without FSE. I get smooth playback at 24 and 60 Hz and I tested using 1080p24, 4Kp24, and 4Kp60 sources.

I started my testing today because I noticed some reproducible stutter. I already had 419.67 installed through GFE. I went to Nvidia's site and downloaded 419.67 CRD and did a clean install using that and after rebooting all the stutter went away. I then did the same with the GRD and nothing changed. I don't really have anything else to add, I tried to test a lot of stuff and I swear I noticed some reproducible bad behavior, but now I cannot reproduce any of if, everything looks good. :confused:

I was also worried about bad behavior of my 2017 LG C7 OLED at 24 Hz but all my testing today has convinced me that when accepting 8 bit RGB at 24 or 60 Hz, and with the input set to PC, I get proper playback out of it. 24 Hz isn't exactly smooth, of course, but I do not have any judder. :)

For the stuttering issue I need info from two or more of a specific driver version. What driver version has really the problem as Asmodian has no more stuttering.

As already mentioned I cannot test as I don't have any Nvidia card.

chros

31st March 2019, 12:37

OK, awesome, it worked, the custom refresh rate now sticks, BUUUT... madVR does not auto-switch to it.
Which nvidia driver version do you use?
Have you read this (https://forum.doom9.org/showthread.php?p=1869139#post1869139) and this (https://forum.doom9.org/showthread.php?p=1869139#post1869139) ?

brazen1

6th April 2019, 17:53

OK, I added some info to the first post. If I did something wrong or missed anything, correct me and I update it.
As you wrote it, indeed there was an audio issue. I can remember now but I can't find the exact problem. Can you please post it here again?

No auto switch from stereo to multiple speaker setup in Windows Audio considering if AVR state is On or Off.

https://forum.kodi.tv/showthread.php?tid=229692&pid=2721301#pid2721301

SamuriHL

11th April 2019, 15:10

Manni can you check 425.31 and see if the metadata issue is resolved? It would be most appreciated. Thanks!

Sent from my Pixel XL using Tapatalk

nevcairiel

11th April 2019, 16:27

Contrary to its version number, this is still a 418-series driver (they ran out of numbers). The "new" major driver release should be 430+ later this month, probably ready for Windows 10 1903.

SamuriHL

11th April 2019, 16:33

Well THAT sucks. I really would like them to release it NOW LOL!

P.S. That driver SUCKS! They fixed NOTHING from the previous release. Move the mouse, HDR goes away just like the last driver. Come on, nVidia, get it together man!

Manni

11th April 2019, 17:41

Contrary to its version number, this is still a 418-series driver (they ran out of numbers). The "new" major driver release should be 430+ later this month, probably ready for Windows 10 1903.

Thanks Nevcairiel, saves me a test. :)

SamuriHL, I'll check the 430+ later this month.

SamuriHL

11th April 2019, 18:13

Yup, much appreciated. I wouldn't care as much as I do if it weren't for the fact that I use nVenc HEVC encoding on that machine and would like to update my ffmpeg instance, but, it requires a later driver because they switched to the latest nVidia API (which is a good thing and what I'd like to use). But I'm stuck with the last driver that actually works for passthrough at the moment. As SOON as they release the new driver I'll be testing it, as well.

cremor

13th April 2019, 09:35

425.31 GRD 2019-04-11 need info for any possible fixes, but it seems to be nothing fixed of any HTPC related stuff

I don't have stuttering problems with 425.31 on a RTX 2070 (with V-Sync at it's default setting). But I've never tested any 419.x version so I can't say if the stuttering others reported is fixed or my system is just not affected.

TechnoPeasant

16th April 2019, 13:51

Now everything seems fine for me, HDR needs 10 bit to trigger but works without FSE.

Just wanted to pop in and say this behavior was the same for me. I had to drop back down to the last known good driver in order to use 8-bit + dither + HDR together.

Klaus1189

16th April 2019, 18:02

I don't have stuttering problems with 425.31 on a RTX 2070 (with V-Sync at it's default setting). But I've never tested any 419.x version so I can't say if the stuttering others reported is fixed or my system is just not affected.

Thank you cremor.

For verifying cremor's results, I need some info from other Nvidia users. Is the stutter issue for RTX cards fixed or probably it was just a setting which was misconfigured by default during installation, I think I have read something like that from ryrynz somewhere...

ryrynz

16th April 2019, 23:59

AFAIA CLSID's Nvidia inspector profile resolves it in every case but it also seems it either has been fixed or is a rare occurrence when upgrading. Perhaps keeping track of which versions caused it isn't worthwhile at all. Does anyone still have this issue?

clsid

17th April 2019, 00:05

This is NVIDIA Profle Inspector tool with an optimized profile for MPC-HC/BE.

Download (https://www.sendspace.com/file/ohoudl)

Most important settings it uses:
Power management mode = Adaptive
VSync = on
GSync = off
SLI = off
Prefer NVIDIA on Optimus systems

NM20

17th April 2019, 21:50

Manni

18th April 2019, 10:01

I am on the latest Nvidia drivers and all of a sudden when playing a frame packed 24p film via MPC with Mad VR it has the magenta display no matter whether I pick 8 bit or 12 bit on the Nvidia CP.

I am using a JVC projector, but on an earlier driver this didn't happen and 3d films were fine. What can I do?

Go back to an earlier driver (385.28 recommended) or upgrade the projector. :)

The magenta bug is gone on the new (2019) 4K models, it doesn't happen in 8bits or 12bits, at any frame rate, which makes using 8bits an option again.

With older models, 385.28 only has the magenta bug at 4K60 8bits. There is no magenta bug at 12bits (though colorspace is forced to YCC 422 internally when using RGB or YCC444, irrespective of the frame rate, which hopefully will be solved on the new models, it won't be on the old ones).

Every driver post 385.28 breaks something. The only advantage to using a more recent driver with a GTX card is 3D. Otherwise stick to 385.28.

I think 391.24 is the last driver where the magenta bug is not with 12bits as well as 8bits, at all frame rates. However the video levels are borked in 12bits if using video levels, and you can't select 12bits in a custom res. Of course 3D only improved with 391.35, so it's one or the other. Then after 398.11 you lose HDR passthrough as well.

Again, 385.28 is the driver to use with GTX (not an option with RTX), unless you really have to use a more recent driver for whatever reason, or a frame drop in 3D every 13min instead of every 3 minutes is good enough motivation to deal with all the other issues.

Hopefully the next major driver branch coming up this month should allow at least some of us to upgrade, especially if HDR passthrough is supported again.

Klaus1189, if you think it's useful, please could you link to this post in the first post, as a "note to JVC projector owners with nVidia GPU"? Thanks!