View Full Version : madVR - high quality video renderer (GPU assisted)
huhn
17th October 2018, 02:02
HDR conversation is relative free in dumb mode.
the MeasureLuminace /StrechRect shaders is significantly faster with d3d11 native is there a reason for that? i'm talking about a factor of 2-3x times faster.
madshi
17th October 2018, 08:08
Thanks guys!
isn't black bar detection essential for many? You lose that with native.
Yes, and yes.
At 1080p, a GTX 1050 Ti can't do tone mapping for 60 fps content with highlight recovery enabled. highlight recovery is the killer, as it pushes rendering times way over 16ms. This is with scale chroma separately enabled.
Is that with copyback? Does using D3D11 native decoding change anything?
Yes! :thanks:
This is without highlight recovery, though, I guess? What happens if you enable that, too?
And while we're at it, which NGU Upscaling quality (Luma only, chroma set to "normal") can the 1050 Ti do for 1080 -> 4K? Medium or High?
huhn
17th October 2018, 08:25
a 960 is very similar to a 1050 ti and is can do 1080p23 with NGU high easily. it uses about 20ms ~ for NGU high alone.
and be aware that the 1050 3GB is on paper faster than the 1050 ti and cheaper at the same. just a matter if you can work with the 3GB it has.
not a lot of versions to choice from but the price is great: https://geizhals.de/?cat=gra16_512&xf=9808_11805+-+GTX+1050+(3GB%2F96bit)
mytbyte
17th October 2018, 08:47
Were you trying to find a target nits that perfectly tracked BT.2390 all the way to 100% output? The only commonality I see is that the brightness does seem to get to white too slow or too fast at the top. Maybe that is something that is lost in translation with SDR? And maybe it is close enough?
No, I want to work with measured nits but I am wandering why MadVR generated BT.2390 curve (as measured) drifts gradually (and significnatly) away from HCFR reference BT.2390 curve and then returns to being spot-on at 70% but then gets clipped at 80-90% stimulus if we know the "formula" is defined in the papers and should be the same in HCFR and MadVR. Is the 80-90% clipping part of the formula to mantain some HDR effect with low peak brightness?
If translation to SDR was the cause, I expect the PQ curve tracking would drift as well but it is not. :confused:
That part don't make no sense. Only the 8-bit pattern should display correctly, but you shouldn't fail the black clipping test if you are clipping correctly to 175 nits. The gradient should go from right-to-left until Bar 16.
hmm...there is no bar 16, there is a clip with 64-80 bars and there is a clip with C64-C111 gradient (0.0-0.07 nits). In the former I can, with great effort and in pitch black room notice that bars 76-80 are flashing, almost un-noticebly. In the gradient clip I can see the gradient becoming VERY slightly lighter, from left to right, than the bottom black part, so I am guessing there is no crush but also that near black gradation is so barely noticable - don't know if that's a problem and it should be more noticable.
RainyDog
17th October 2018, 09:32
He's saying clock speed is dynamic and ideally you need to log gpu speed and load for a good minute or so and calculate the average from that. Simpler tasks can show higher render times since the GPU can clock a lot lower.
Madshi, any chance we could get an average rendering statistic in the OSD? Ideally being able to see clock speeds on the OSD would be useful too.
D3D11 is quite a bit more efficient on my 1060.
Or set your GPU to maximum power state then the render times will be comparable on a level playing field.
For some reason, I can't get D3D11 native to work in 10bit exclusive mode on my 1060 :confused: It just freezes when I try going fullscreen. DXVA2 native is fine though.
ryrynz
17th October 2018, 09:55
The usual uninstall/reinstall graphics drivers and reset madVR. Does it work with 8bit?
For anyone downscaling 4K HDR to SDR HD, make sure you have 'scale chroma separately' checked.
Also 'Are you nuts!?' highlight recovery for HDR does wonders for clouds and other highlights and looks nicer than very high, you really want this option enabled at either of those settings I think.
SSIM 2D downlscaling for 60fps 4K content is just out of reach for a 1060 6GB and my 1080 can't quite do full madVR 4K HDR -> 1080 SDR (SSIM 2D downscaling, NGU AA chroma, ED2 Dithering, highlight recovery etc), I have to enable scale chroma separately.
chros
17th October 2018, 10:20
and be aware that the 1050 3GB is on paper faster than the 1050 ti and cheaper at the same. just a matter if you can work with the 3GB it has.
I know it was discussed couple of times but can you remind me what it can't do with 3GB? I'm interested in <=30fps content only.
Does anyone use a 3GB card here?
Maybe I can upgrade my laptop to another one with 1060 3GB version...
huhn
17th October 2018, 10:30
i don't have a 3 GB card so i can't say.
but i can use more than 3 GB Vram with madVR by using ngu on chroma and luma by leaving the rest in madVR normal.
because 2Gb doesn't work easily on UHD with subtitles and we are using PC you just recommend 4 gb because that's more common.
ryrynz
17th October 2018, 10:36
You won't have any problems with 1080P or below on a 2GB card.
mytbyte
17th October 2018, 10:39
For anyone downscaling 4K HDR to SDR HD, make sure you have 'scale chroma separately' checked.
Also 'Are you nuts!?' highlight recovery for HDR does wonders for clouds and other highlights and looks nicer than very high, you really want this option enabled at either of those settings I think.
I protest - at l(e)ast there is a standard now and we still seek to tweak it. :D
ryrynz
17th October 2018, 10:42
Enabling it absolutely destroys performance better used in other places, I do prefer to not have it ticked though. Prefer not to trade quality where possible.
Definitely the last thing to untick from that section.
Manni
17th October 2018, 10:57
that's more than odd. there is nothing that should be able to push your CPU to full load when hardware decoding is used.
Thanks, you were absolutely right, something was wrong when I took my power readings: I didn't notice that Teamviewer was running in the background :). That's why the CPU load was abnormally high. Because that didn't impact on my rendering times, I didn't think of it.
The GPU clock was maxed though, and the task manager performance monitor was correct by the way (checked with GPU-Z and CPU-Z). It usually is fairly reliable here.
I did more tests without Teamviewer running in the background (!), using Pacific Rim for a worst case scenario (as it's a 16/9 UHD HDR movie), the readings are normal (I think). I also used a kill-o-watt to measure the actual power use for each mode (rough average). Idle use is 93W.
DVXA2 NT: 18ms CPU 12% GPU 50% 230W
DVXA2 CB: 21ms CPU 30% GPU 75% 320W
D3D11 NT: 18ms CPU 15% GPU 55% 270W
D3D11 CB: 21ms CPU 30% GPU 75% 320W
I wish it was possible to use DXVA2 native as it's clearly the most power efficient mode but if I remember correctly there are banding issues with it. Both CB modes seem to use the same amount of power roughly, so unless there is a very strong reason to use DXVA2 CB, it looks like I'm going to use D3D11 native with manual picture shift, as I'll lose the black bars detection. I can't really justify 50W just for that convenience. I'll just have to select thelens memory on my iPad for each film, that's not too bad.
I have everything enabled with pixel shader with peak brightness measurements, restore highlights, no compromise, NGU High chroma upscaling, plus a 3D LUT, plus some enhancements, so it's a maxed out scenario. Still Asmodian's times with a 1050ti seem significantly lower, so I might try to disable some enhancements later to see if I get similar results.
Thanks again for pointing this out, it doesn't make any difference in real use but my results were wrong, as you pointed out.
He's saying clock speed is dynamic and ideally you need to log gpu speed and load for a good minute or so and calculate the average from that. Simpler tasks can show higher render times since the GPU can clock a lot lower.
Madshi, any chance we could get an average rendering statistic in the OSD? Ideally being able to see clock speeds on the OSD would be useful too.
D3D11 is quite a bit more efficient on my 1060.
Thanks for the translation/explanation. I'm aware that clocks are dynamic, and I had checked that, it wasn't the explanation :)
I agree that an average rendering stat in the OSD would be great.
Not sure why your D3D11 mode is more efficient, there is little to no difference here with CB and DXVA2 is significantly more efficient in native.
huhn
17th October 2018, 11:07
blackbar detection still runs even on a movie that doesn't need it so your comparison is not fair.
and don't you think it's odd that 70% GPU load is 21 ms and 50-55 %is 18 ms.
with DXVA native even measure peak brightness is disabled which is a couple of MS if it it used.
because i can't look into your system you have to make sure all use the same settings and no setting is used that the other mode can't do.
Manni
17th October 2018, 11:23
blackbar detection still runs even on a movie that doesn't need it so your comparison is not fair.
and don't you think it's odd that 70% GPU load is 21 ms and 50-55 %is 18 ms.
with DXVA native even measure peak brightness is disabled which is a couple of MS if it it used.
because i can't look into your system you have to make sure all use the same settings and no setting is used that the other mode can't do.
I wasn't trying to do a fair comparison, only to show what results I get with my current settings if I simply change the mode.
I didn't use a 16/9 movie because I thought black bars detection wouldn't be active, I used it because it has more pixels to handle than a 2.40 title, hence worst case scenario re render times (as I said).
I'm only posting results for the settings I was currently using. I'll adapt settings depending on whether I decide to use native or copyback.
Measure peak brightness isn't disabled when running DXVA2 native, not sure where that comes from.
You are correct though that if I was to disable the CPU features used in CB that cannot be used in native, the render times would go down in CB. I guess I'll have to test that.
huhn
17th October 2018, 11:40
you can not call one mode more efficient if you didn't test them fair.
and did madshi change this in a new test build?
https://abload.de/img/itcomesfromherec1cmv.png
Manni
17th October 2018, 12:37
you can not call one mode more efficient if you didn't test them fair.
and did madshi change this in a new test build?
https://abload.de/img/itcomesfromherec1cmv.png
Fair enough, the only thing I can say is that whatever CB is doing, with my settings, I can't justify the power use it causes as I only need it for black bars detection. So it's more efficient for me, unless/until I can see something I lose in PQ or functionality apart from black bars detection.
I'm using ordered dithering, and although disabled black bars detection shaves 2ms and drops the CPU use from 25% to 15% (MPC-BE only), that doesn't explain the whole difference.
My picture enhancements cost me around 2ms.
Re the DXVA limitation, I don't know if it's effective or not, I can only report that the measured brightness is displayed with DXVA native as well as with D3D11 (I checked). Maybe Madshi can explain if the text in the settings still applies and if it does how come the OSD shows the measurements with DXVA native.
huhn
17th October 2018, 12:48
it doesn't run with version 17. easily checked with the advanced OSD.
mytbyte
17th October 2018, 12:57
The plot thickens! How come the 100% stimulus HDR pattern is reported as 10000 nits measured/average by MadVR when content metadata says maximum content light level is 1000 nits?
Manni
17th October 2018, 12:57
it doesn't run with version 17. easily checked with the advanced OSD.
I have no idea what you are talking about. As I said, measure peak brightness works just as well with DXVA2 as it does with D3D11, at least according to the OSD. Both the measured brightness and the histograms show. I'm using V17 with the latest test build.
https://imgur.com/a/ASXPoRq
huhn
17th October 2018, 13:01
create an empty folder called ShowRenderSteps in the madVR folder.
but judging from your OSD limited information it is clearly working with that version.
chros
17th October 2018, 13:05
You won't have any problems with 1080P or below on a 2GB card.
Sorry, I meant 4k UHD/1080p/720p contents on 4k/2k displays.
but i can use more than 3 GB Vram with madVR by using ngu on chroma and luma by leaving the rest in madVR normal.
we are using PC you just recommend 4 gb because that's more common.
Thanks, that's not a good news for me :)
Manni
17th October 2018, 13:20
create an empty folder called ShowRenderSteps in the madVR folder.
but judging from your OSD limited information it is clearly working with that version.
Yes, it's clearly working, as I said.
https://imgur.com/a/rql9XUw
huhn
17th October 2018, 13:24
4 shaders ok he change something in your test build.
Warner306
17th October 2018, 15:34
Is that with copyback? Does using D3D11 native decoding change anything?
Already using D3D11 decoding. Highlight recovery is just really slow. It is not an issue with 24 fps content.
Warner306
17th October 2018, 15:43
No, I want to work with measured nits but I am wandering why MadVR generated BT.2390 curve (as measured) drifts gradually (and significnatly) away from HCFR reference BT.2390 curve and then returns to being spot-on at 70% but then gets clipped at 80-90% stimulus if we know the "formula" is defined in the papers and should be the same in HCFR and MadVR. Is the 80-90% clipping part of the formula to mantain some HDR effect with low peak brightness?
If translation to SDR was the cause, I expect the PQ curve tracking would drift as well but it is not. :confused:
There is likely something different about the BT.2390 used by HCFR and the BT.2390 used by madVR. madVR does additional processing, but testing luminance alone should yield a similar curve, I would assume. Your display is tracking PQ values accurately.
The brightness response of BT.2390 is also very different than straight PQ clipping because tone mapping deviates far off the original PQ curve. The SDR gamma curve would have to be contorted a bit to make it look right.
It would be hard to say what would be causing the differences without knowing if there are differences in the tone curves. I would try testing different mastering peaks (lower than 10,000) with target nits values in madVR that are above your display brightness because that's how most would use pixel shader. If I set my display to 175 nits and the target nits to 175 nits, the image is washed out. I don't think that is intended by BT.2390.
hmm...there is no bar 16, there is a clip with 64-80 bars and there is a clip with C64-C111 gradient (0.0-0.07 nits). In the former I can, with great effort and in pitch black room notice that bars 76-80 are flashing, almost un-noticebly. In the gradient clip I can see the gradient becoming VERY slightly lighter, from left to right, than the bottom black part, so I am guessing there is no crush but also that near black gradation is so barely noticable - don't know if that's a problem and it should be more noticable.
I would doubt you are crushing black given the accuracy of your calibration. The 8-bit bars are represented along the bottom of the 8-bit clipping pattern. They are hard to see, but they are there.
Warner306
17th October 2018, 15:53
The plot thickens! How come the 100% stimulus HDR pattern is reported as 10000 nits measured/average by MadVR when content metadata says maximum content light level is 1000 nits?
Bad metadata or lack of metadata. The measurement would be more accurate. The metadata is just available to assist with tone mapping.
madjock
17th October 2018, 15:56
As an HDR -> SDR user on an normal 1080p LG TV, is there anything to be gained by all these new settings and selections ?
Asking for an ignorant friend :).
Warner306
17th October 2018, 15:57
I would check measure each frame and enable highlight recovery. You would gain by using both settings.
Siso
17th October 2018, 16:55
NGU medium vs NGU high is it really worth it? NGU high gives me 65% GPU load and rendering times ~ 22 ms. GTX 1050 ti.
SamuriHL
17th October 2018, 17:18
On my 6gb 1060 I stick with medium. It's very subjective but most people aren't going to see a HUGE difference between medium and high and on lower end equipment where performance matters more it's certainly not worth it IMO.
madshi
17th October 2018, 17:21
@SamuriHL, just to get a speed impression, with your 1060, I suppose you can do the following with ease:
1) "NGU High" Luma upscaling with 1080 -> 4K at 60fps? (Chroma set to "normal").
2) Tone mapping including highlight recovery and measurements at 4K 60fps?
Correct? Thanks!
Siso
17th October 2018, 17:30
On my 6gb 1060 I stick with medium. It's very subjective but most people aren't going to see a HUGE difference between medium and high and on lower end equipment where performance matters more it's certainly not worth it IMO.
Good point.
mytbyte
17th October 2018, 17:37
Bad metadata or lack of metadata. The measurement would be more accurate. The metadata is just available to assist with tone mapping.
Well, I took the HDR clipping pattern that is also marked as 1000 nits max and when I set peak brightness in MadVR to 10000 nits, I get visible flashing bars all the way accross so there IS data all the way up to 10000 nits in the file and madVR detects that, apparently.
I would doubt you are crushing black given the accuracy of your calibration.
Just measured that my near black tracking is rising slower than the BT.2390 reference (up to 8% stimulus), so it is darker than it should be, but data is there.
SamuriHL
17th October 2018, 18:13
@SamuriHL, just to get a speed impression, with your 1060, I suppose you can do the following with ease:
1) "NGU High" Luma upscaling with 1080 -> 4K at 60fps? (Chroma set to "normal").
2) Tone mapping including highlight recovery and measurements at 4K 60fps?
Correct? Thanks!
1) Rendering is hanging out around 27ms or lower average with NGU Sharp HIGH luma upscaling 1080 -> 4k 60. Chroma set to normal.
2) Rendering is about 35ms or so at 4k 60 with tone mapping highlight recovery measurements and 65% desat.
Of note I am using D3D11 decoding not doing any copy back.
P.S. All trade quality options are disabled.
Balthazar2k4
17th October 2018, 18:25
Out of curiosity what is the state of madVR with an AMD Vega solution for 4K HDR material? I am looking to replace my HTPC with a Hades Canyon NUC (8809G) and want to understand what issues I might run into. I saw a post way back about madVR being unable to autoswitch HDR mode in Windows with AMD cards. Has this changed?
I am presently using a GTX960/Pentium G4600 based machine now and want to get a similar experience... just smaller.
Edit: I see that AMD now has a private HDR API that madVR will utilize. That answers that, but is there anything else that might be an issue?
Alexkral
17th October 2018, 20:59
Hi Madshi,
I'm sorry to be late for your request of feedback about NNEDI3, like many others I don't update madVR very often (I'm still using 0.92.2 now), neither read this thread, but I think there was a good reason to keep it. Maybe nobody else noticed, but it is/was the only doubling algorithm capable of independent width or height doubling. I encode my BD3Ds to 1920 x 2160 OU for viewing on my FPR UHD TV. This way there is no need to upscale the height, the TV just take the available lines and reorder them in a line alternative scheme. When I play these videos in fullscreen with madVR using NNEDI3 for doubling, I can see in the OSD that after chroma upscaling, luma x (or the whole image x depending on settings for chroma doubling) is upscaled with NNEDI and image y is left untouched. But if I choose super-xbr or NGU for doubling, I can see that after chroma upscaling, both image x and image y are upscaled and then image y is downscaled with the algorithm chosed.
I understand that you had reasons to remove NNEDI3 so I'm not going to ask for it back, but maybe this feature could be added to NGU. Anyway I suspect that image y doubling to 4320 and then downscaling back to 2160 should not mean a significant quality loss, but given that it is not necessary in this situation, maybe I should just forget about doubling and use one of the other upscaling algorithms.
Also, I don't understand if the new option "tone map HDR using external 3DLUT" is just for processing HDR, or for both processing HDR and converting HDR to SDR.
422415
17th October 2018, 21:45
I can set RGB Full 12 bpc in 1809 and 416.34. I simply change the refresh rate first, setting it to RGB Full 8 bpc 340x2160p23, and then after I am in 23 Hz I can set 12 bpc, this lives through reboots and similar without issue. However, this is not with a custom 23 Hz mode, with a custom mode I simply cannot use >8 bit at all. :(
I just updated to Windows 1809 and 416.34 and it still will not switch to 12bpc. Incredibly frustrating.
el Filou
17th October 2018, 22:31
On my my 1050 Ti on 1080 display I have to check 'compromise on mapping accuracy' for 60p HDR content. With 24p it's fine.
Not a big deal for me as most HDR content besides demos still is 24p movies at the moment.
ryrynz
18th October 2018, 12:02
HDR looks terrible with that enabled.. Compromise on anything else..
Warner306
18th October 2018, 16:18
On my my 1050 Ti on 1080 display I have to check 'compromise on mapping accuracy' for 60p HDR content. With 24p it's fine.
Not a big deal for me as most HDR content besides demos still is 24p movies at the moment.
If you create a profile for 4K60 with scale chroma separately checked under trade quality for performance, you should be able to enable everything again, save highlight recovery.
Warner306
18th October 2018, 16:20
Out of curiosity what is the state of madVR with an AMD Vega solution for 4K HDR material? I am looking to replace my HTPC with a Hades Canyon NUC (8809G) and want to understand what issues I might run into. I saw a post way back about madVR being unable to autoswitch HDR mode in Windows with AMD cards. Has this changed?
I am presently using a GTX960/Pentium G4600 based machine now and want to get a similar experience... just smaller.
Edit: I see that AMD now has a private HDR API that madVR will utilize. That answers that, but is there anything else that might be an issue?
It will work fine. However, the NUC is expensive and has an overpowered CPU for a HTPC. A Zotac Zbox with a GTX 1060 would be a better choice.
Warner306
18th October 2018, 18:19
2) Rendering is about 35ms or so at 4k 60 with tone mapping highlight recovery measurements and 65% desat.
Of note I am using D3D11 decoding not doing any copy back.
P.S. All trade quality options are disabled.
What are your rendering times when chroma upscaling is set to something like Lanczos3 and dithering set to Ordered Dithering?
SamuriHL
19th October 2018, 00:02
Oh hell, that's right, I did set dithering to ordered a couple weeks ago and forgot about it. As for chroma I'd have to check and I don't know if I'll have time to test tonight. I should be able to tomorrow.
Warner306
19th October 2018, 16:04
Just curious. I thought the GTX 1060 was faster than that.
SamuriHL
19th October 2018, 19:11
1) Rendering is hanging out around 27ms or lower average with NGU Sharp HIGH luma upscaling 1080 -> 4k 60. Chroma set to normal.
2) Rendering is about 35ms or so at 4k 60 with tone mapping highlight recovery measurements and 65% desat.
Of note I am using D3D11 decoding not doing any copy back.
P.S. All trade quality options are disabled.
So this was with ordered dithering. However, changing it to error diffusion 2 didn't seem to make much difference. I'm still kicking around 30ms for 4k 60.
Changing to laczos3 as Warner306 suggested (still with error diffusion 2) lowers it down to ~20ms.
And changing THAT to ordered dithering lowers it to ~18ms.
Hope this helps!
Axelpowa
19th October 2018, 22:08
Hi,
I'm trying to set multiple profiles in madVR under the device settings for HDR taking hdrpeaknit of a movie in account.
Like this
If (hdrpeaknit <=1000) "275" (275 would be a profile)
Else if.....
Else if....
Else...
The problem I have is that my Projector jvc x7500 switches to HDR profile as if I were sending metadata to the projector instead of staying in my sdr2020 profile.
Any way to avoid this?
Regards!
Manni
19th October 2018, 22:28
Are you sure you've selected pixel shader in each of your HDR profile? There shouldn't be any HDR metadata sent with pixel shader, unless you've selected the "output video in HDR" option.
Otherwise you might want to try checking the "report BT2020" box in the calibration tab if you have an nVidia GPU. Or if it's checked, try uncheking it. But it shouldn't force HDR mode in the JVCs either way.
Axelpowa
19th October 2018, 23:03
Are you sure you've selected pixel shader in each of your HDR profile? There shouldn't be any HDR metadata sent with pixel shader, unless you've selected the "output video in HDR" option.
Otherwise you might want to try checking the "report BT2020" box in the calibration tab if you have an nVidia GPU. Or if it's checked, try uncheking it. But it shouldn't force HDR mode in the JVCs either way.
Hi Manni,
Yes, I've checked it. Was the first thing I thought, but it is correct. I created every profile duplicating the one I use for sdr2020 pixel shader. After that I just changed the peak nits target for every profile.
Regards!
Manni
19th October 2018, 23:18
Hi Manni,
Yes, I've checked it. Was the first thing I thought, but it is correct. I created every profile duplicating the one I use for sdr2020 pixel shader. After that I just changed the peak nits target for every profile.
Regards!
Did you check that the profile that should be enabled with your logic is indeed enabled? Otherwise it could be another profile that's selected for whatever reason.
If your sdr2020 pixel shader profile behaves correctly and you've simply copied it to create the others, then I have no idea, except checking every single option.
If you enable a copy where nothing is changed from your original profile, does it behave as the original or does it not work?
Apart from that I can't think of anything else. I have an X7000 and I use a Vertex to disable the HDR metadata anyway, so I don't have this problem.
Warner306
20th October 2018, 00:25
So this was with ordered dithering. However, changing it to error diffusion 2 didn't seem to make much difference. I'm still kicking around 30ms for 4k 60.
Changing to laczos3 as Warner306 suggested (still with error diffusion 2) lowers it down to ~20ms.
And changing THAT to ordered dithering lowers it to ~18ms.
Hope this helps!
So the GTX 1060 is just slightly too slow for tone mapping at 4K 60 fps. This is helpful because I am often talking to people building PCs at AVSForums, mostly for madVR. The GTX 1060 still seems like a good choice, but the GTX 1070 is required for 4K 60 fps with extra sauce.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.