AMD, Intel and Nvidia driver issues and last recommended version

[Manni]

Originally Posted by KoD

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]

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.

[Manni]

Originally Posted by KoD

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]

Originally Posted by Manni

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]

Originally Posted by KoD

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]

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]

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]

Originally Posted by nevcairiel

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

[Manni]

Originally Posted by nevcairiel

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?

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.

Originally Posted by SamuriHL

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

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]

Originally Posted by Manni

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?

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.

Originally Posted by Manni

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]

Originally Posted by nevcairiel

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.

Originally Posted by nevcairiel

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]

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

[huhn]

did someone try this driver:
https://www.nvidia.com/download/driv...ts.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]

Originally Posted by sat4all

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

Not checking anything until the next major branch expected in April

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

[chros]

Originally Posted by Manni

Not checking anything until the next major branch expected in April

Me neither until a new GPU/TV (which won't happen tomorrow)

[j82k]

Originally Posted by sat4all

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

- 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]

Originally Posted by j82k

- 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.

Originally Posted by chros

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 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]

Originally Posted by XMonarchY

I didn't use Extension blocks though...

Then use it

[KoD]

Originally Posted by Manni

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.