AMD, Intel and Nvidia driver issues and last recommended version

[VBB]

@Manni Did you have madVR set to 8-bit or 10-bit/auto? With 8-bit it doesn't switch using newer drivers.

[Asmodian]

I had to restart after installing the new drivers but HDR passthrough works the same in 419.35 for me. madVR needs to send 10 bit to the driver (on startup, if I change to 8 bit while playing HDR stays active) but I don't need FSE to activate HDR on my LG C7 OLED. I cannot see what metadata is actually being sent to the TV but HDR does activate.

Edit: This is using standard v0.92.17, not any of the new HDR test builds.

[Manni]

@Manni Did you have madVR set to 8-bit or 10-bit/auto? With 8-bit it doesn't switch using newer drivers.

Ah OK, yes I was using 8bits because there is a bug in RGB 12bits with my JVC rs2000, it forces YCC422 internally and messes up levels...

I'll try again with 12bits and will report back.

[Manni]

I had to restart after installing the new drivers but HDR passthrough works the same in 419.35 for me. madVR needs to send 10 bit to the driver (on startup, if I change to 8 bit while playing HDR stays active) but I don't need FSE to activate HDR on my LG C7 OLED. I cannot see what metadata is actually being sent to the TV but HDR does activate.

Edit: This is using standard v0.92.17, not any of the new HDR test builds.

Here I do need FSE to enable HDR (with nVidia CP set to 12bits and madVR set to 10bits or +), which I didn't need with former drivers (even recent), so that's a step back.

And sadly the metadata is still bogus :(

[SamuriHL]

And sadly the metadata is still bogus :(

Of course it is. I suspect nev is correct in that 1) we won't see this fixed until another major branch and/or 2) the way it is supposed to work has changed and the code needs to be updated to reflect that.

[Manni]

Of course it is. I suspect nev is correct in that 1) we won't see this fixed until another major branch and/or 2) the way it is supposed to work has changed and the code needs to be updated to reflect that.

I was not expecting it to be fixed. :)

I was not expecting it to be worse than in 419.17 though, as that version didn't need FSE. That was a disappointment.

Anyway, back to an older driver.

I'll test again at the next major branch change.

[nevcairiel]

I'll test again at the next major branch change.

As far as I can tell, that should be the 421 branch ready for Windows 10 19H1 (presumably in April)

[Manni]

As far as I can tell, that should be the 421 branch ready for Windows 10 19H1 (presumably in April)

OK thanks, I'll try that then. I'm back to 397.31 for now, as that's the first release with better 3D that doesn't need CRU to get custom refresh rates working in 12bits. Fingers crossed I won't have to go back to 385.28 and lose the better 3D...

[Manni]

Sadly no custom refresh rates in 12bits with 397.31, so back to 385.28, at least while I need to do tests with HDR passthrough.

Unfortunately I can't transpose my madVR custom refresh rates into CRU with the RS2000, for some reason they don't work, I think because the front porch parameter is limited to 1023 in CRU and madVR comes up with 1276, so CRU isn't an option. It used to work fine with the rs500.

[Manni]

@Manni Did you have madVR set to 8-bit or 10-bit/auto? With 8-bit it doesn't switch using newer drivers.

Updating my excel nVidia bug tracking Excel spreadsheet, does anyone know with which driver version (even roughly) this started?

Thanks!

[j82k]

The first time I noticed the "hdr only triggers when madVR is set to 10-bit" problem was with driver 417.35 as mentioned here:

https://forum.doom9.org/showthread.php?p=1860410#post1860410

[Manni]

The first time I noticed the "hdr only triggers when madVR is set to 10-bit" problem was with driver 417.35 as mentioned here:

https://forum.doom9.org/showthread.php?p=1860410#post1860410

OK thanks.

[iSeries]

Unfortunately I can't transpose my madVR custom refresh rates into CRU with the RS2000, for some reason they don't work, I think because the front porch parameter is limited to 1023 in CRU and madVR comes up with 1276, so CRU isn't an option. It used to work fine with the rs500.

You have to add a DisplayID extension block in CRU, and within that you can add a new detailed resolution with higher limits.

[Manni]

You have to add a DisplayID extension block in CRU, and within that you can add a new detailed resolution with higher limits.

That's interesting but I'm not sure what you mean.

In CRU (V1.3.1 on windows 10 x64), if I try to create my custom resolution in one of the slots left in the CEA-861 extension block for my display [2 detailed resolutions, 8 data block (HDMI 2.0), 1 slot left as I've already created one that doesn't work with the rs2000], I can't go above 1023 for the front porch value.

Which new extension block are you suggesting I create? Another CEA-861, or VBT-EXT? Neither allows me to create a custom res with a 1276 front porch value if I add one.

Thanks.

[iSeries]

That's interesting but I'm not sure what you mean.

In CRU (V1.3.1 on windows 10 x64), if I try to create my custom resolution in one of the slots left in the CEA-861 extension block for my display [2 detailed resolutions, 8 data block (HDMI 2.0), 1 slot left as I've already created one that doesn't work with the rs2000], I can't go above 1023 for the front porch value.

Which new extension block are you suggesting I create? Another CEA-861, or VBT-EXT? Neither allows me to create a custom res with a 1276 front porch value if I add one.

Thanks.

At the bottom window ('Extension blocks'), click 'add' and add a DisplayID there, and from there you can add a new detailed resolution

[Manni]

At the bottom window ('Extension blocks'), click 'add' and add a DisplayID there, and from there you can add a new detailed resolution

Sorry if I'm being dense, but when I click "add" at the bottom window (extension blocks), it opens a window "extension block" and the only thing I can choose is "type", which can be CEA-861 extension block, VBT-EXT Video Timings Block, or Default Extension block.

Irrespective of the option I choose, there is no option that I can see to ad a DisplayID.

I can either add detailed resolutions or data blocks if I create another CEA extension block, or detailed resolution and standard resolutions if I add a VBT-EXT block.

EDIT: by the way, I already have an active display ID. Should I change something there? I can see Vrate, Hrate and max pixel clock there.

[iSeries]

Sorry if I'm being dense, but when I click "add" at the bottom window (extension blocks), it opens a window "extension block" and the only thing I can choose is "type", which can be CEA-861 extension block, VBT-EXT Video Timings Block, or Default Extension block.

Irrespective of the option I choose, there is no option that I can see to ad a DisplayID.

I can either add detailed resolutions or data blocks if I create another CEA extension block, or detailed resolution and standard resolutions if I add a VBT-EXT block.

EDIT: by the way, I already have an active display ID. Should I change something there? I can see Vrate, Hrate and max pixel clock there.

That's odd. On mine, I click add, then in the 'type' dropdown I choose DisplayID, then click add, and then another box comes up where I click 'detailed resolution'. Here's what toastyx told me to do: https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU?pid=8028#pid8028

[nevcairiel]

I also get a DisplayID block as the type choice. But if his EDID already has a DisplayID block, then thats probably why a new one cannot be added. Should modify that and add the detailed resolution there.
The DisplayID block takes detailed resolutions just like the CEA-861 block, but its more flexible in which values it can accept.

[Manni]

That's odd. On mine, I click add, then in the 'type' dropdown I choose DisplayID, then click add, and then another box comes up where I click 'detailed resolution'. Here's what toastyx told me to do: https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU?pid=8028#pid8028

I also get a DisplayID block as the type choice. But if his EDID already has a DisplayID block, then thats probably why a new one cannot be added. Should modify that and add the detailed resolution there.
The DisplayID block takes detailed resolutions just like the CEA-861 block, but its more flexible in which values it can accept.

Thanks both.

Are you using the same version I do (V1.3.1)?

Also I tried to modify the Vrate and Hrate up to the max in my display ID, that doesn't allow me to go above 1023 for front porch.

[Manni]

OK I found 1.4.1 :)

[nevcairiel]

Apparently DisplayID support was new in 1.4, so yeah, that would explain it.

[Manni]

No problem, and thanks again to you and iSeries for helping to solve this.

Apologies to everyone else for the brief OT :)

[Manni]

Not to re-open the OT, but I was able to create a custom res with 1.4.1 that worked with the rs2000.

Unfortunately, this custom res wouldn't be selected automatically, and even when selected manually before playback, the nVidia CP would revert to the native refresh rate and the dropped frames every 4 minutes. Otherwise, I was able to select 8bits or 12bits with it, as expected.

So as I'm not using 12bits at the moment, I reset all the CRU entries and I'm using the madVR custom res, which works fine with that driver and is selected automatically/remains the default.

At least I'm able to stay with 397.93 (I couldn't find 398.07), which allows me to have the better 3D and HDR passthrough, broken with 398.11.

If you have any suggestion, please contact me by PM so as not to keep discussing this specific issue of mine in the thread, unless it's considered on topic :).

[Klaus1189]

No problem with the topic. It suits best here.

Maybe you meant 399.07 from 2018-08-27 instead of 398.07? There is no 398.07.

[Manni]

No problem with the topic. It suits best here.

Maybe you meant 399.07 from 2018-08-27 instead of 398.07? There is no 398.07.

Thanks :)

No I meant 398.07. I thought that was the last driver before 398.11, which breaks HDR passthrough.

I was only looking for it because I think Huhn mentioned it was the one he was using. Maybe he's using 399.07 and I misread or he misspelt [EDIT: I found the post, I misread/misremembered, he is using 399.07]. Either way, 399.xx isn't an option for now because HDR passthrough won't work and I need it for some testing I'm doing at the moment.

If 398.07 doesn't exist, that would explain why I can't find it :)

I don't mind using 397.93, which is the last driver I have before 398.11.

[Manni]

Okay one last post on the subject in case it helps someone else, thanks to iSeries who kindly PMed me, I was able to get the CRU custom res to load by default by moving the Display ID custom res to the top of the list (using the small arrows at the right of the box).

So now I have a working CRU custom res for 8bits and 12bits.

Thanks again everyone for all the help in getting CRU to work here, much appreciated :)

This will be most helpful when I can use 12bits again with the rs2000.

[sat4all]

Hi,

Lately i was experiencing some nasty banding when watching HDR contents using HDR output, the solution was to switch from windowed to FSE mode.
While investigating on the previous matter, i found this:
Normaly after each new driver installation i was always creating custom 23,976 resolution using CRU, toggle "use nvidia settings" in NV CP, set Full RGB 10bit for 23,24,25,29,30fps and 8bit for the rest. Now, i left nvidia CP set to "use default settings" instead of "use nvidia settings" and made madvr switching between 8 and 10bit using rules:

if (bitdepth=10) "10-bit"
else "8-bit"

So, now when watching SDR madVR use D3D11 8bit Exclusive and the NV output is 8bit, Full RGB while for HDR it use D3D11 10bit Exclusive and the gpu output: NV HDR, 12bit, Full RGB.
It's like D3D11 is controlling the output! is this known? or this is new, maybe some sort of windows update feature?
Anyway, this is great as you will have near perfect bit depth chain based on content and the 12bit output will stick arround even after an OS reboot.
Btw, i'm using 398.11 drivers but Newer drivers behave the same except sending bogus metadata.

[Manni]

Does 398.11 still send the correct metadata in HDR Passthrough?

[Manni]

I checked, 398.11 does indeed still send valid HDR metadata, but when I select HDR passthrough in HDR it selects an invalid RGB mode that the Maestro reports as “reserved”.

Unfortunately, so does 397.93.

Tomorrow I’ll try to trace when that starts, as I don’t remember seeing this with 385.28. It could be due to the fact that I was using my LG 4K monitor and the JVC wasn’t on. I’ll update if I find anything conclusive.

[Manni]

Just a quick update. The "reserved" RGB in passthrough happens even with 385.28, even with native res.

So I'm back to 398.11, which indeed still passes through HDR metadata, using CRU 1.4.1 and custom res.

Thanks again everyone.

[chros]

So I'm back to 398.11, which indeed still passes through HDR metadata, using CRU 1.4.1 and custom res.
@Manni, do/did you have the same behaivor as this (https://forum.doom9.org/showthread.php?p=1860337#post1860337)?
I always have to switch to 60Hz at first to madvr correctly recognise the custom 23p.
Thanks

[Manni]

@Manni, do/did you have the same behaivor as this (https://forum.doom9.org/showthread.php?p=1860337#post1860337)?
I always have to switch to 60Hz at first to madvr correctly recognise the custom 23p.
Thanks

The reporting of 24p for the custom refresh rate instead of 23p in the NCP is a known bug, but it's cosmetic only.

I set the 23p custom rate (created by CRU) as my default, and I don't have the issue you mention.

MadVR switches to 60p (or other rates) if necessary, but I mostly play 23p content and my custom rate is always selected by defaut (now that I've put the DIsplay ID custom rate at the top of the list, thanks iSeries!).

But I don't use my HTPC for gaming or anything else, and I used CRU to create the custom refresh rate, not madVR because with recent drivers madVR created custom rates don't work in 12bits (8bits is forced in the NCP).

So quite a few variables/difference from what you're doing.

[ashlar42]

So we're past nine months without new Nvidia drivers that correctly passthrough HDR data? Am I getting this right? Nvidia really doesn't give a damn about people with HTPC/gaming setups... :rolleyes:

[grendelrt]

So we're past nine months without new Nvidia drivers that correctly passthrough HDR data? Am I getting this right? Nvidia really doesn't give a damn about people with HTPC/gaming setups... :rolleyes:

Madshi had posted on the official Geforce forums he had passed it on to a dev friend at Nvidia last month. Wonder if he ever got any confirmation back.

[Manni]

Madshi had posted on the official Geforce forums he had passed it on to a dev friend at Nvidia last month. Wonder if he ever got any confirmation back.

Nevcairiel said earlier in the thread (https://forum.doom9.org/showpost.php?p=1867867&postcount=60) that it was unlikely to be corrected before the next major branch, maybe in April.

[grendelrt]

Nevcairiel said above that it was unlikely to be corrected before the next major branch, maybe in April.

It does also affect gaming, so I am surprised it is taking so long to fix. Probably because most people don't pay attention to the metadata coming in (consoles don't even send any). I will cross my fingers super hard and hope they fix it :D

[SamuriHL]

There will be a new branch in April as it brings some pretty big changes. The end of Kepler support and no more 3D vision support.

Probably should have added a source for that rather bold statement. LOL Sorry about that.

https://www.engadget.com/2019/03/11/nvidia-ends-3d-vision-support/

[huhn]

don't forget that for nvidia HDR movies are pretty unimportant to say it friendly but to get HDR games to look as "good" as they want and work as good as possible.

[SamuriHL]

I realize us HTPC users are a small segment of their market, but, after their crypto nonsense went bust they probably shouldn't completely discount us.

[chros]

@Manni, do/did you have the same behaivor as this (https://forum.doom9.org/showthread.php?p=1860337#post1860337)?

You have to add a DisplayID extension block in CRU, and within that you can add a new detailed resolution with higher limits.

I set the 23p custom rate (created by CRU) as my default, and I don't have the issue you mention.

MadVR switches to 60p (or other rates) if necessary, but I mostly play 23p content and my custom rate is always selected by defaut (now that I've put the DIsplay ID custom rate at the top of the list, thanks iSeries!).

But I don't use my HTPC for gaming or anything else, and I used CRU to create the custom refresh rate, not madVR because with recent drivers madVR created custom rates don't work in 12bits (8bits is forced in the NCP).

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 :)

Couple of notes:

The difference between CRU and nvidia created (by madvr) custom timing is:
- nvidia adds a new one to the already existing ones: that can confuse applications which one to use (e.g. madvr)
- CRU replaces an existing one with the custom one on the OS level, so there won't be any confusion

When you create custom timings with madvr (http://madvr.com/crt/CustomResTutorial.html):
- always start from the default one (EDID) and pay special attention to the "sync" attributes (e.g. + , +):
-- don't select a mode that is different!
- don't deviate a lot from the default EDID values
-- remember, this approach is modifying "back porch" (horizontal and vertical values) only!
- the above 2 wrong settings can easily modify the response of the panel! (e.g. modifying gamma curve, causing black crush, etc.)
- if you get >= 10 hours after the first optimisation then it's already really good, you don't need to do more runs

Examples, original EDID timing:

EDID/CTA:
front sywi back pixels sync
hor 1276 88 296 1660 3480 5500 +
ver 8 10 72 90 2160 2250 +
picl 296.70 mhz
23.9757575757576
OSD result: 23.97791Hz (~4.41 minutes)


Result after the first optimisation run:

Custom:
front sywi back pixels sync
hor 1276 88 356 1720 3480 5560 +
ver 8 10 72 90 2160 2250 +
picl 299.94 mhz
23.9760191846523
OSD result: 23.97537Hz (~22 hours - 1 day)



About nvidia driver versions:
- some of them can block custom timings completely (doesn't matter how they were created)
- so always check in madvr OSD whether your timing is applied if you install a new driver

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

[KoD]

398.82 is the first driver in a very very long time where they fixed the Dolby Vision switch on LG OLEDs with firmware newer than 4.70.x. Says so in the driver release notes, and I've seen this in Mass Effect: Andromeda, this is the first driver version in a long time where DolbyVision works again. So, for some gamers, using anything older (like 398.11) is not a good choice. And 398.11 was, in fact, the previous released driver version.

As a side-note, it would be nice if madshi would enable switching on DolbyVision in the renderer for nVidia cards. The DV metadata is preserved in mp4 and mkv files, and the x265 encoder can now store DV metadata in the stream as well. There's documentation from nVidia on how to do that using the NvAPI, like in the slides from this GDC presentation: slides (http://on-demand.gputechconf.com/gtc/2017/presentation/s7394-tom-true-programming-for-high-dynamic-range.pdf), video (http://on-demand.gputechconf.com/siggraph/2017/video/sig1702-thomas-true-programming-high-dynamic-range-rendering.html). I don't know if there is a similar documented way for AMD graphic cards, except contacting Dolby and asking for their DolbyVision gaming SDK (they have a Dolby Developer site).

Btw, I recommend anyone interested to have a look at the video presentation and the slides, it is a nice overview on what is HDR, what are color spaces, tone mapping, how programmers should configure the backbuffer and the swap chains and what data to use in order to have HDR content displayed. It also shows what the rendering pipeline is in the nVidia driver (have you noticed that the nvidia driver does dithering sometimes? well, you can see here where it happens). The nVidia HDR whitepaper that can be downloaded from this page (https://developer.nvidia.com/high-dynamic-range-display-development) is also a great introduction in all this.



@Manni:
I do have one question though: have you tried to see what the HDR metadata values are when you connect a LCD monitor to your graphics card instead of your projector? Because the driver takes into account the capabilities of the display as reported by EDID. Digital cinema projectors have a max luminance of 48 nits, so that 20 nits average frame luminance value you noticed seems suitable for a projector, and might be in fact the value reported by the EDID of your projector. If that's the case, what we see might in fact be just a workaround used in the driver to avoid having the displays misbehave when presented with values outside their supported range, as the displays are supposed to tonemap themselves according to these values and their capabilities. I agree, that's not "passtrough" of the metadata though, but it might make the display device not apply any of its custom tone mapping up to that average frame luminance - so it displays the video as it was tonemapped by the source up to that luminance value - a passtrough of the source video through the display device, so to say.

[j82k]

I knew about the mp4 dolby vision remuxes (which work when fed directly to the TV) but I was under the impression that it wasn't possible within an mkv container.
But anyway, if DV playback could be made working with madvr that would really be amazing.

[nevcairiel]

MKV definitely doesn't store out-of-band Dolby Vision metadata. If its part of the video stream itself, it would work with any container, since remuxes are not supposed to take anything out.

[j82k]

So, theoretically could at least the DV mp4 remuxes made with mp4muxer (https://github.com/DolbyLaboratories/dlb_mp4base/tree/master/bin) be made playable from a PC with madVR?
The DV metadata is a seperate video stream within the mp4 file.
What exactly needs to happen to make this possible? Would this be LAVs or madVRs job?

[SamuriHL]

It'd be both. LAV needs to know how to decode it and madvr needs to know how to render it. In theory I think I saw somewhere that nVidia added preliminary Dolby Vision support to their API but I wouldn't get all excited about that. Does not mean we're anywhere even close.

[chros]

So I'm back to 398.11
I wanted to try out this version but I couldn't create custom resolution with it (not in madvr, not in cru), I always got ~12 minutes for 23p.
So, I'm back to 385.28, all is good, having ~13 hours for 23p (used cru).

Here's also a good tool if you don't want to install too much crap which are bundled nowadays in nvidia drivers such es telemetry https://www.techpowerup.com/forums/threads/nvcleanstall-clean-installer-for-nvidia-drivers-alpha.249085/
Remove your old driver with DDU first

Thanks for this, I also used nvcleanstall util to install both drivers, selected Recommended option (only display/audio driver and physics were selected and MSI Afterburner works fine for underclocking/volting).

[Manni]

@Manni:
I do have one question though: have you tried to see what the HDR metadata values are when you connect a LCD monitor to your graphics card instead of your projector? Because the driver takes into account the capabilities of the display as reported by EDID. Digital cinema projectors have a max luminance of 48 nits, so that 20 nits average frame luminance value you noticed seems suitable for a projector, and might be in fact the value reported by the EDID of your projector.

This isn't the case for a few reasons:
1) I have an HD Fury Maestro in the chain that reports to all sources the EDID with the same full capabilities (HDR, BT2020, 600Mhz bandwidth, full sound etc) and then deals with what might need to be done to comply with different displays connected. So it doesn't matter one bit which display is actually connected. And both my rs2000 and my LG 4K monitor can take the full, unchanged content, without requiring any down-scaling or conversion.
2) This metadata isn't supposed to be changed in passthrough mode. It's not the business of the source to change the metadata, at least when playing UHD content. Remember that I get the *same* bogus metadata irrespective of the *known* metadata for each title.
3) Digital cinema projectors, especially consumer ones, are not limited to 48nits. My rs2000 can go up to 200-250nits and more depending on settings and screen. The EDID is certainly not reporting a 48nits max. Even Modern digital cinemas go above this, which is the SDR reference white. Dolby Cinema uses a peak of 107nits for example with HDR titles.

So for all these reasons (and a few others), I can confirm that the metadata sent in passthrough by the recent drivers is simply bogus. It isn't what it should be, especially when playing UHD bluray content, where the original mastering metadata should *always* be reported, as it's not the business of the source to know about the limitations of the display if it's not doing the tonemapping.

[Manni]

I wanted to try out this version but I couldn't create custom resolution with it (not in madvr, not in cru), I always got ~12 minutes for 23p.

Are you sure that the custom resolution is actually applied and that the display is active both in CRU and in madVR?

Otherwise it can be a limitation of your display.

Here 398.11 works just as well as any other version with CRU after our debugging group session here a few days ago.

Did you try to export your CRU config valid in 385.85 and import it in 398.11, to make sure you rule out any user error in recreating the refresh rate?

[chros]

Are you sure that the custom resolution is actually applied and that the display is active both in CRU and in madVR?

Here 398.11 works just as well as any other version with CRU after our debugging group session here a few days ago.

Did you try to export your CRU config valid in 385.85 and import it in 398.11, to make sure you rule out any user error in recreating the refresh rate?
Thanks Manni, I can't state that it wasn't a user error :) but since it worked straight away with v385.28 both times ...
Anyway, since there's no performance difference between the 2 driver versions and I don't use any of the affected issues (hdr passthrough, 3d, etc.), I stick with v385.28 until I change something in my system.

I also created the following custom resolutions for my BenQ GL2450HM 1080p monitor that only exposes 60Hz (in CRU with madvr's help):
1080p47, 1080p48, 1080p50, 1080p59, 1080p60

[KoD]

This isn't the case for a few reasons:
1) I have an HD Fury Maestro in the chain that reports to all sources the EDID with the same full capabilities (HDR, BT2020, 600Mhz bandwidth, full sound etc) and then deals with what might need to be done to comply with different displays connected. So it doesn't matter one bit which display is actually connected. And both my rs2000 and my LG 4K monitor can take the full, unchanged content, without requiring any down-scaling or conversion.
2) This metadata isn't supposed to be changed in passthrough mode. It's not the business of the source to change the metadata, at least when playing UHD content. Remember that I get the *same* bogus metadata irrespective of the *known* metadata for each title.
3) Digital cinema projectors, especially consumer ones, are not limited to 48nits. My rs2000 can go up to 200-250nits and more depending on settings and screen. The EDID is certainly not reporting a 48nits max. Even Modern digital cinemas go above this, which is the SDR reference white. Dolby Cinema uses a peak of 107nits for example with HDR titles.

So for all these reasons (and a few others), I can confirm that the metadata sent in passthrough by the recent drivers is simply bogus. It isn't what it should be, especially when playing UHD bluray content, where the original mastering metadata should *always* be reported, as it's not the business of the source to know about the limitations of the display if it's not doing the tonemapping.

I see. The 48 nits value for Digital Cinema was in the nVidia presentation, btw. I do realize that home projectors are able of more though.

Then it's either a bug, or working as intended. While initially HDR was only supported in Windows in full screen exclusive mode (and in this mode it makes sense to pass the application set min/max/avg values to the display), Microsoft then added support for windowed mode as well, both borderless and with borders. This means that one application window which was created for SDR content looks as it did before while another application window on the same display is able to display wide gamut content with high luminosity. In order to do that, the compositing engine has to work in wide gamut mode all the time, for everything in Windows.

What this means: if one of the applications tries to say "oh, my min/max/avg luminance is <this>", that's not information that should be passed to the display, because your other SDR application that you have on the screen at the same time must be rendered properly too.

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.



Regarding Dolby Vision, there's clearly support in the graphics drivers for sending the metadata to displays (TVs, as I don't know of any monitor supporting DV), otherwise all the games that make use of it would not work. It's possible however that the DV metadata during a gaming session is sent to the display only by means of a Dolby supplied library, for which a license is required. The code in the slides posted by me shows only how to switch the display to DV mode and how to configure it initially, it does not show how to send DV metadata while the video game is running.

Dolby has a Dolby Developer website, as I was saying. In its whitepaper found there it says the metadata and the video can be in a single stream, but there's a two stream approach as well. It also says they have DolbyVision decoders, and display managers, for PCs, mobile devices, game consoles, etc. So they clearly have a way to display this content on PCs. And if you make an account on their Dev site to access the DolbyVision FAQ, a contact is given for requesting access to the SDK and an example to try out. I would be surprised if the next CyberLink PowerDVD version that should be announced in a month or two will not have DV support.