madVR - high quality video renderer (GPU assisted)

[Manni]

OK thanks. Only one GPU here anyway.

[iSeries]

Complete 0-255 chain vs MadVR at 16-235, GPU at 0-255, and TV at low doesn't make a difference on my C8.

Tested in a pitch black room using the linked and other black clipping test pattern.

Also it would have really surprised me if it made a difference regarding near-blacks/black crush. :rolleyes:

Maybe LG changed something in 2018, but I can assure you LG TVs have shown the same thing going back ten years lol. Remember to test, brightness has to be at default 50. The black square one is really the best way to set brightness

[mclingo]

i'll have a look tonight on my ageing EF950 OLED

[SamuriHL]

For me I have to set madvr to 16-235, GPU full, and TV low to get the proper levels on my C8. So no, IMO, it has not changed in the 2018 models. Default brightness of 50. I can only claim this to be my experience.

[austonrush]

Hey Guys, I've got a repeated frames glitch when starting a video file. The audio plays in the background but, the video portion initially freezes. This started after the latest windows 10 and nvidia upgrade, never had it before. It can freeze for up to 10 seconds sometimes. Anyone else seeing this? It is not exclusive to any one video.

https://imgur.com/a/t8eGSZZ on average it repeats about 900 frames before the video kicks in.


I was able to isolate this to a LAV hardware decoder d3d11 issue. It only occurs when the display switches herz before playback ie. 60hz to 23hz etc. If I'm already at 23hz and start the video it works without any presentation glitches. If I switch to DXVA2 copyback everything works as it should. This has only been an issue since I upgraded windows 10 to the latest build.

[Warner306]

I'm not technical enough to understand the BT.2390 paper in full, and can't quite grasp how the rolloff algorithm works (for 200 cd/m2 max brightness on a comp monitor, the 70% I measured as being way too high, 80-100 are flat i.e clipped in the graph (probably depends on MaxL of content and mastering monitor etc). But, everything under 50% (95 nits) is more-less following the PQ curve at all times so there should be no major black crush from MadVR's tone map curve (note: I'm doing HDR->SDR)

Something is lost in translation when going from HDR -> SDR.

If the target nits is higher than the display's actual brightness, you are only getting a ratio of the original curve.

Example: 480 target nits shown at 200 actual nits

480 nits is the lowest value of BT.2390 where the soft knee (where compression begins) is above reference white (100 nits). Lower values will place the soft knee lower and lower and compress at least some of the first 100 nits. The lower the target nits, the more reference white is compressed.

Approximate display brightness for reference white for 480 target nits at 200 actual nits:

4.8 ratio of target nits/reference white — 480/100 = 4.8 — at 200 actual display nits — puts an untouched diffuse white at close to 42 nits — 200/4.8 = 42 nits

In current test builds, if the content is below 480 nits, clipping is selected for as long as possible. This helps improve the brightness of content that is above the soft knee up to the set target nits, and even above the target nits, by eliminating the compression curve and reducing it as much as possible up to the peak brightness of the source.

Approximate brightness of 470 nits actual scene peak at 200 display nits with clipping enabled:

2.4 ratio of target nits/display nits — 480/200 = 2.4 — at 200 actual display nits — puts 470 nits at close to 196 nits — 470/2.4 = 196 nits

Clipping is always predictable because it is the ratio of the target nits/display nits. BT.2390 is only predictable up to the soft knee. After the soft knee, the entire range is compressed and will change depending on the brightness of the scene.

You would actually lose less brightness by outputting in PQ (HDR Output) to an HDR display because the target nits and display nits should match.

The gamma curve mismatch means this scale is not exact, but it is a general guide to actual brightness output.

[VoodooNBGD]

Hi all,

Does someone know if chroma upscaling in madVR works in one or two steps, when presentation resolution is larger than luma plane resolution?

For example, I have a H264 video in 1280x720 pixels (4:2:0 color with progressive scan). So, when I play it on a 1080p display, does madVR:

1. First upscales chroma from 640x360 to luma plane resolution (1280x720) using selected chroma upscale algorithm
2. Combines 1280x720 luma with upscaled chroma
3. Upscales the resulting picture to 1080p using selected image upscale algo

OR

1. Directly upscales chroma from 640x360 to desired presentation resolution (1080p) using selected chroma upscale algo
2. Upscales luma from 1280x720 to 1080p using selected image upscale algo
3. Combines both images to presentation picture

Thanks!

[Siso]

Is reduce compression artifacts needed when upscaling 1080p encodes to 2560x1080p? I was thinking using it with NGU Sharp - medium at strength 1.

[Betroz]

report back what you get.

Which movie player are you using?

I am using MPC-HC, and yes of course I have set MadVr as video renderer :)

With these settings, both black level tests posted here show black crush :

- GPU set to Full RGB and 0-255 in Nvidia settings
- MadVr set to 0-255
- TV set to :

Black level HIGH
Gamma 2.2
Brightness 49
OLED light 50

Now the Windows desktop is brighter since I have the TV set to High in Black Level, and as I said the test pattern is very dark. I can't see all the boxes.
Edit : Small update here : I have increased my TV brightness to 53, and now I pass the THX Optimizer test image for brightness. Image here : https://ibb.co/dfZPLf
Edit 2 :The opening scene in Star Wars the last Jedi when you see the scrolling text over the dark sky with stars, with TV Black level set to Low, the black is perfect black. With Black Level set to High, black is not pitch black anymore. All this confirms my previous testing. So...

We can take this discussion in the other tread (https://forum.doom9.org/showthread.php?t=175769&page=6) I can post this there aswell.

[ryrynz]

Is reduce compression artifacts needed when upscaling 1080p encodes to 2560x1080p.

Needed? No. Is it beneficial for your content? Maybe. You'll have to compare for yourself. There are no wrong options here.

[Siso]

Needed? No. Is it beneficial for your content? Maybe. You'll have to compare for yourself. There are no wrong options here.

I read in Warner 306's guide, that the recommended strengths are from 2-8...

[mclingo]

I am using MPC-HC, and yes of course I have set MadVr as video renderer :)

....

I just tried it myself, I see no difference at all with your pattern or the standard black clipping mate.

I have to say i'm glad as they should be no difference and I prefer having correct colour space on my desktop.

I guess you just got lucky with your combination of kit and settings, however...

I'm guessing this is your first OLED even though you've had several LG tvs?

My first gen 4k OLED has a less smooth transition at near black for setting brightness levels in that you have to move the brightness slider two notches to increase or decrease the brightness, this makes it a bit notchy for setting black clipping. This doesnt affect how it shows these elements, just how you setup the TV.

This was fixed in the next model E6, so it could be I just cant get that notch that you can.

on my black clipping pattern I prefer flashing 18 and above rather than 16/17 as this can produce raised blacks for me, this could be the issue.

for me though this is an advanage as it means there is no difference so I can stick with using HIGH and have the correct desktop colour space.

[el Filou]

Does someone know if chroma upscaling in madVR works in one or two steps, when presentation resolution is larger than luma plane resolution?It first brings chroma to luma resolution. There's a (simplified) rendering path flowchart in this post: https://forum.doom9.org/showthread.php?p=1709814#post1709814

[iSeries]

I just tried it myself, I see no difference at all with your pattern or the standard black clipping mate.

I have to say i'm glad as they should be no difference and I prefer having correct colour space on my desktop.

I guess you just got lucky with your combination of kit and settings, however...

I'm guessing this is your first OLED even though you've had several LG tvs?

My first gen 4k OLED has a less smooth transition at near black for setting brightness levels in that you have to move the brightness slider two notches to increase or decrease the brightness, this makes it a bit notchy for setting black clipping. This doesnt affect how it shows these elements, just how you setup the TV.

This was fixed in the next model E6, so it could be I just cant get that notch that you can.

on my black clipping pattern I prefer flashing 18 and above rather than 16/17 as this can produce raised blacks for me, this could be the issue.

for me though this is an advanage as it means there is no difference so I can stick with using HIGH and have the correct desktop colour space.

If the lowest shade above black you see is bar 18 then you won't see what I'm talking about. From what I remember with the older OLEDs is there was no way to get 0.5% to show without raising the black level.

The first visible square in the pattern is equal to bar 17 (0.5%). This is crushed with brightness at default 50 and a full RGB chain. This square is visible with brightness at default 50 and limited>full>limited. As is per my experience with the first C7 I had which I exchanged for this one, and also a plasma a couple other LCDs.

[mytbyte]

Something is lost in translation when going from HDR -> SDR.

If the target nits is higher than the display's actual brightness, you are only getting a ratio of the original curve.

Example: 480 target nits shown at 200 actual nits

480 nits is the lowest value of BT.2390 where the soft knee (where compression begins) is above reference white (100 nits). Lower values will place the soft knee lower and lower and compress at least some of the first 100 nits. The lower the target nits, the more reference white is compressed...



Yes, you are right, I mixed up the comp monitor's results with my 500 nits SDR TV that indeed follows the original PQ curve up to 50% (but the roll-off is still very abrupt and is still clipped in 80-100% range, only when I select Master MaxL in HCFR to 10000 nits does the BT.2390 reference that HCFR underlays follow the MadVR roll-off more closely -still trying to get my head around this...this could well be a HCFR settings problem...

MadVR puts the diffuse white at about 80 cd/m2 for the said 200 nit monitor. Does this sound as being more in the ballpark?

[mclingo]

If the lowest shade above black you see is bar 18 ....s.

ok, i'm going to change my mind on this, I can see a difference, I wasnt giving my eyes enough time to adjust in between changing the settings.

on LOW I can see all but the top corner two blocks far left, on high I cant quite see the top 3 blocks, I can barely see the 3rd one down but its there.

Not sure this is enough of a difference for the exta hassle of having a crushed desktop though.

But you are correct nonetheless, this is very interesting.

I think i'd have to see a real world difference to bother changing my setup.

[ryrynz]

I read in Warner 306's guide, that the recommended strengths are from 2-8...Screenshot. Watch in motion. Decide for yourself, blindly setting options based on recommendations is not how I prefer to do things.

[x7007]

For me I have to set madvr to 16-235, GPU full, and TV low to get the proper levels on my C8. So no, IMO, it has not changed in the 2018 models. Default brightness of 50. I can only claim this to be my experience.

Why would you use 16-235 when you can 0-255 ? I am using FULL on the Nvidia + TV AUTO and MadVR 0-255 , there is a big different in quality when you use 16-235 .. why would you do that.. maybe it depends on the media player ? I don't know. but with Potplayer I just see 16-235 like when the TV can't support it , washed white even on the blackest black on the wide screen black lines that suppose to be blackest black on OLED

[Betroz]

I'm guessing this is your first OLED even though you've had several LG tvs?


This is my first OLED TV, and my second LG TV. I returned my first LG after I bought it some 7 years ago, and now I am considering doing it again, but for another reason (bad motion performance, ie. stutter).

This is getting a bit off topic I think.

[Betroz]

Why would you use 16-235 when you can 0-255 ? I am using FULL on the Nvidia + TV AUTO and MadVR 0-255 , there is a big different in quality when you use 16-235 .. why would you do that.. maybe it depends on the media player ? I don't know. but with Potplayer I just see 16-235 like when the TV can't support it , washed white even on the blackest black on the wide screen black lines that suppose to be blackest black on OLED

It depends on the setup I believe. With your TV at auto for black level, it could be possible that it defaults to High anyway.

[ryrynz]

Why would you use 16-235 when you can '0-255 ?

'Cos he has his TV on low black levels (16-235)

[madjock]

This thread "crushes my soul".

I have an older LG LCD TV, and if I select any calibration settings it looks crap, if I adjust settings to get good blacks, everything else looks crap.

Life is too short. :)

[ryrynz]

RIP the black level on most LG OLEDs ~2017 and older. Now back to our usual programming.

[SamuriHL]

Why would you use 16-235 when you can 0-255 ? I am using FULL on the Nvidia + TV AUTO and MadVR 0-255 , there is a big different in quality when you use 16-235 .. why would you do that.. maybe it depends on the media player ? I don't know. but with Potplayer I just see 16-235 like when the TV can't support it , washed white even on the blackest black on the wide screen black lines that suppose to be blackest black on OLED

'Cos he has his TV on low black levels (16-235)

Yup. And it works great for me.

[Warner306]

Yes, you are right, I mixed up the comp monitor's results with my 500 nits SDR TV that indeed follows the original PQ curve up to 50% (but the roll-off is still very abrupt and is still clipped in 80-100% range, only when I select Master MaxL in HCFR to 10000 nits does the BT.2390 reference that HCFR underlays follow the MadVR roll-off more closely -still trying to get my head around this...this could well be a HCFR settings problem...

MadVR puts the diffuse white at about 80 cd/m2 for the said 200 nit monitor. Does this sound as being more in the ballpark?

Are you using HCFR to calibrate HDR -> SDR? That wouldn't work if you are trying to track BT.2390 because the actual gamma curve is 2.20 or 2.40 pure power gamma.

80 nits sounds too bright for reference white if room was left for specular highlights, but it is difficult to tell for sure because it is unknown where compression begins when the target nits is set to less than 480 nits. And you are still only getting a ratio of the original curve's target nits.

[mytbyte]

Are you using HCFR to calibrate HDR -> SDR? That wouldn't work if you are trying to track BT.2390 because the actual gamma curve is 2.20 or 2.40 pure power gamma.



Can you explain? I'm not using bulit-in patterns but rather R. Masciola's HDR patterns in manual mode although I'd prefer it if MadVR HDR->SDR processing worked with MadTPG.

[Warner306]

PQ is converted to SDR gamma, so the original BT.2390 curve will be lost. SDR is also relative and not absolute like PQ. You could try calibrating in SDR, but pixel shader changes the gamma curve, so the charts might not look right.

The best you can do is check for black and white clipping. Try these patterns (https://drive.google.com/file/d/1PYY37NqZLPEo1ZOwFmbUZ3T8JqyuGH7-/view?usp=sharing). I would suggest pausing the 8-bit black clipping pattern because it is short. Setting the correct gamma curve in madVR is the most important part of this test.

Even then, once black clipping is set to the correct gamma curve, your eyes will be a better guide as to what looks best. You will lose something in contrast or brightness no matter what you choose.

[mytbyte]

@Warner: but HDR converted to SDR should result in PQ points when measured with a meter, from HDR patterns run through MadVR and the measured max display's nits entered into madVR, no? In that case it's not relative...I mean, I get almost perfect PQ tracking when I set MadVR curve to "clipping" (that being pure PQ, I suppose) and it looks in no way particularly wrong on screen...of course, converting HDR to SDR loses the precision of PQ (less bits allocated to low end)

Thanks for the link.

[Warner306]

Maybe. I'd like to see what the charts look like when set to clipping and BT.2390. The curves shouldn't match perfectly because they are different gamma curves. Setting madVR to 2.20 or 2.40 would change the gamma curve. I wouldn't think it would track the PQ curve the same in both instances.

[mytbyte]

Maybe. I'd like to see what the charts look like when set to clipping and BT.2390. The curves shouldn't match perfectly because they are different gamma curves. Setting madVR to 2.20 or 2.40 would change the gamma curve. I wouldn't think it would track the PQ curve the same in both instances.

If you have control over the TV's gamma and can measure it, I suppose you can choose what fits you tv's response.

I'll try to upload the charts these days, watch this space.

[422415]

Can anyone tell me what I'm doing wrong? I cannot get RGB Full 12bpc set in NVIDIA settings for 3840x2160 23hz. I have tried setting it to YCbCr422 then changing it after that but it always resets back to YCbCr422 limited. I am on Windows 1803 and have tried multiple NVIDIA drivers to no avail.

[mytbyte]

@Warner306:

Here are the graphs I promised for the monitor, can't do the TV at this time:

LG_IPS235_graph (https://drive.google.com/open?id=17TQ26xJKXvPSovO3fZC8e7kDvEHUXZVH)

I performed new measurements because white balance drifted a bit so peak brightness is actually 175 cd/m2 (and we complained about plasma brightness). I also used MadVR 0.92.17 and it seems math is a bit different than before, making my previous comments irrelevant. Color tweaks and highlight recovery are set to disabled/none, not to interfere with BT.2390 math.

Screenshot titles are self explanatory but I'll recap:

LG_IPS235_175nits_Gamma2.2.png - this is the measured gamma of the monitor when set to 2.2 preset (no 10-point adjustment available) and measured with HCFR's internal automatic SDR patterns nits to check if gamma is tracking well even at peak brightness

LG_IPS235_175nits_PQ.png - this is the PQ tracking (MadVR set to clipping), manual HDR pattern advance

LG_IPS235_175nits_BT.2390.png - this is the BT.2390 tracking when HCFR reference settings are set to default

LG_IPS235_100nits_BT.2390_MinL=0.13_MaxL=10000.png - this is the BT.2390 tracking when MadVR is set to minimum allowed peak brightness of 100 nits and Master MinL is set to monitor's measured black level, while Master MaxL is set to theoretical maximum of 10000 nits

provided HCFR math is correct, it seems Master MinL and MaxL values affect the reference BT.2390 curve and make MadVR's math, as measured, track closer/smoother. BT.2390 tracking drifts significantly at 50 & 60% stimulus even though the measured gamma the BT.2390 curve is transposed to is "perfect"..

perhaps the measured black level value should also be added to MadVR's math?

As for your patterns, I can see very faint flashing at the right side of the screen with "Black Level 10-bit" as well as slightly lighter right side compared to left side with "Black level 8-bit/10-bit combined".

[Manni]

Everything works with Software decoding or DXVA2/D3D11 Copy-Back (because copy-back looks like software decoding to a renderer). And between those last two, DXVA2 Copy-Back is usually preferable because its more efficient, unless you need D3D11 to access a headless GPU.

I've done some tests and was quite surprised with the results.

Playing 4K23 content (chroma NGU High and minor enhancements), I got:

DXVA2 Native: 12.5ms
DXVA2 CB: 21ms

D3D11 Native: 16ms
D3D11 CB: 22ms

While I was aware of the performance loss between D3D11 native and CB, I would have expected DXVA2 CB to do better than that. There isn't much of a performance gain between DXVA2 CB and D3D11 CB, at least here.

DXVA2 native produces the most significant gain, and the only one that would make a difference for me, as it means I could play 4K60 in the same quality. Unfortunately, not an option for me due to the lack of black bars detection.

Weirder, with 1080p23 content (NGU High chroma, NGU very high luma), all modes give around 22ms, there doesn't seem to be any performance gain going native.

So I'm not sure what the advantage is to use DXVA2 CB vs D3D11 CB if there is little to no performance gain.

Hopefully we'll get one of the native modes to support black bars detection at some point, without losing too much performance and getting to CB level.

I guess it's good to know that I can go back to DXVA2 native if at some point I need the performance as I can always shift my picture with the mechanical lens shift instead of doing it electronically with MadVR. Black bars detection is the only thing I would miss I think going native.

Thanks again for clarifying things for me and for prompting this re-evaluation. :)

[madshi]

Quick question to 1050 Ti users: Is the 1050 Ti fast enough to do 4Kp60 HDR tone mapping with all the bells and whistles (measurements + highlight recovery + "compromise" disabled)?

[Manni]

Quick question to 1050 Ti users: Is the 1050 Ti fast enough to do 4Kp60 HDR tone mapping with all the bells and whistles (measurements + highlight recovery + "compromise" disabled)?

The 1080ti isn't able to do 4K60 HDR with all the bells and whistles (see my post just above yours), unless you use DXVA2 native (in which case you lose black bars detection), so I doubt the 1050ti can. Config in my sig.

[madshi]

When talking about bells and whistles, I meant in terms of HDR tone mapping. I don't consider NGU Chroma upscaling to be crucial. So, using e.g. D3D11 native decoding, with default chroma upscaling (Bicubic), and no other fancy options activated, can the 1050 Ti do 4Kp60 HDR tone mapping with measurement + highlight recovery?

[Ver Greeneyes]

Isn't DXVA2 Native also limited in what further processing madVR can do? Is it "just" chroma upscaling and black bars detection?

[Manni]

When talking about bells and whistles, I meant in terms of HDR tone mapping. I don't consider NGU Chroma upscaling to be crucial. So, using e.g. D3D11 native decoding, with default chroma upscaling (Bicubic), and no other fancy options activated, can the 1050 Ti do 4Kp60 HDR tone mapping with measurement + highlight recovery?

I agree NGU chroma isn't necessary, but isn't black bar detection essential for many? You lose that with native.

Otherwise yes with bicubic and native D3D11, I would expect the 1050ti to handle 4K60, but that means home cinema use is excluded, unless you find a way to support black bar detection with D3D11 native.

By the way I've just run a comparison in power use, and D3D11 native is far more efficient than copy back. In only requires around 50% CPU and 65% GPU for 4K60p with NGU chroma medium at 4K60p, while copy back requires 90% GPU and 100% CPU. This means a lot of unnnecessary heat! [EDIT: these measurements are wrong, I had Teamviewer running in the background! See this post (https://forum.doom9.org/showpost.php?p=1855199&postcount=53359) for actual measurements)].

The difference is similar between DXVA2 native and copyback, but I seem to remember that there was some banding issues with DXVA2 native, so it looks like D3D11 native would be the way to go, provided there is black bar detection support.

[Warner306]

@Warner306:

Here are the graphs I promised for the monitor, can't do the TV at this time:

LG_IPS235_graph (https://drive.google.com/open?id=17TQ26xJKXvPSovO3fZC8e7kDvEHUXZVH)

I performed new measurements because white balance drifted a bit so peak brightness is actually 175 cd/m2 (and we complained about plasma brightness). I also used MadVR 0.92.17 and it seems math is a bit different than before, making my previous comments irrelevant. Color tweaks and highlight recovery are set to disabled/none, not to interfere with BT.2390 math.

Based on those graphs, I think the gamma response is perfect up to the limit of the display brightness (clipping at 175 nits).

I don't know how you will ever judge the performance of tone mapping, though, for brighter stimulus. The BT.2390 in HCFR wouldn't account for the gamut mapping in madVR. I don't know if there would be clipping or if the lack of anything but white would prevent out-of-gamut pixels. This might change the luminance of many pixels with a 10,000 nit stimulus down to 100 nits if any pixels were out-of-gamut. Have you tried tone mapping something like 500 nits down to 175 target nits in madVR?

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?

perhaps the measured black level value should also be added to MadVR's math?

Don't know if that would help or not. The display is supposed to account for this.

As for your patterns, I can see very faint flashing at the right side of the screen with "Black Level 10-bit" as well as slightly lighter right side compared to left side with "Black level 8-bit/10-bit combined".

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.

[Warner306]

Quick question to 1050 Ti users: Is the 1050 Ti fast enough to do 4Kp60 HDR tone mapping with all the bells and whistles (measurements + highlight recovery + "compromise" disabled)?

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.

[huhn]

@Manni

can you please check power state before you come to a conclusion rendertime are not that reliable.

[Asmodian]

Can anyone tell me what I'm doing wrong? I cannot get RGB Full 12bpc set in NVIDIA settings for 3840x2160 23hz. I have tried setting it to YCbCr422 then changing it after that but it always resets back to YCbCr422 limited. I am on Windows 1803 and have tried multiple NVIDIA drivers to no avail.

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

[Manni]

@Manni

can you please check power state before you come to a conclusion rendertime are not that reliable.

I’m not sure I understand your request, but if you mean in the nVidia control panel I always set the power mode to adaptive.

[huhn]

no im' talking about the mhz the GPU runs at.
for example when my GPU has an easy task like native resolution the rendertime can look pretty high because the GPU is clocking down. while with 1080p source at UHD my rendertimes can look comparable low even through this task is much higher harder.

copyback can't cost you 9 ms that would mean the copy is so slow you can't use it for 120 FPS content because the copyback is using 100 % of the GPU. according to your sig you are running a 1080 ti so just no :-) how do i even play anything on my 1060 if a 1080 ti nearly dies to copyback.

[Manni]

no im' talking about the mhz the GPU runs at.
for example when my GPU has an easy task like native resolution the rendertime can look pretty high because the GPU is clocking down. while with 1080p source at UHD my rendertimes can look comparable low even through this task is much higher harder.

copyback can't cost you 9 ms that would mean the copy is so slow you can't use it for 120 FPS content because the copyback is using 100 % of the GPU. according to your sig you are running a 1080 ti so just no :-) how do i even play anything on my 1060 if a 1080 ti nearly dies to copyback.

I don’t understand a word of what you are saying. 22ms isn’t “dying”, it’s about half of what it has to do at 23p, and that’s with a lot of processing (HDR tonemapping with everything enabled). Copyback costs 6ms in D3D11 and 9ms in DXVA2, at least in that mode, and it does push GPU and CPU to 100%, even at native res, but again that’s with very hungry pixel shader processsing. I’m only reporting what I’m seeing. And yes, I have a 1080ti, otherwise I wouldn’t put it in my sig.

[huhn]

you are sure your CPU is pushed to 100 %?

[Manni]

you are sure your CPU is pushed to 100 %?

According to the task manager performance tab, yes. At 4.18ghz (overclocked).

[huhn]

that's more than odd. there is nothing that should be able to push your CPU to full load when hardware decoding is used.
can you run GPU-Z go to "graphics Card" and press on the question mark to start a test. after this the PCIe information can change and that number is interesting.

the taskmanager GPU load is unreliable just an extreme example for you: https://abload.de/img/taskmanageriei29.png

[Asmodian]

When talking about bells and whistles, I meant in terms of HDR tone mapping. I don't consider NGU Chroma upscaling to be crucial. So, using e.g. D3D11 native decoding, with default chroma upscaling (Bicubic), and no other fancy options activated, can the 1050 Ti do 4Kp60 HDR tone mapping with measurement + highlight recovery?

Yes! :thanks:

I tested with DXVA2 cb and both with and without the trade quality for performance option "compromise on tone & gamut mapping accuracy". This is on a 1050 Ti, Windows 10 1803, Nvidia driver 416.34 (adaptive), and madVR v0.92.17 (reset to defaults, D3D11 fullscreen windowed 10 bit, tone map HDR using pixel shaders with SDR output), MPC-HC 1.8.3, LAV Video 0.73.1. Using the "Samsung Travel With my Pet HDR UHD.ts" demo, 10 bit HDR HEVC 3840x2160p60.

With compromise: 6.8 ms rendering, <0.1 ms present (no dropped frames)
With compromise and measure each frame's peak luminance: 8.8 ms (no dropped frames)
With no compromise: ~13 ms, with spikes up to ~17 ms (a few dropped frames)
With compromise and 3DLUT: ~9.5 ms, with spikes up to ~12 ms (no dropped frames)
With no compromise and 3DLUT: ~18 ms, with spikes up to ~23 ms (a lot of dropped frames)

Without compromising quality performance is very dependent on content. A 3DLUT also takes significantly more power. No compromise looks a lot better too, though as a way to get a 1050 Ti to do HDR 60 fps processing while using copy back the compromise is great. Most of my HDR is 24 fps anyway. ;)

Edit: I redid the tests with D3D11 native decoding. Performance is even better, no compromise runs perfectly as long as I don't use a 3DLUT at the same time.

With compromise: 5.2 ms rendering (no dropped frames)
With no compromise: ~10ms, with spikes up to ~12 ms (no dropped frames)! :cool:
With compromise and 3DLUT: ~7.5 ms, with spikes up to ~10 ms (no dropped frames)
With no compromise and 3DLUT: ~12.5 ms, with spikes up to ~16 ms (a few dropped frames).

Even more tests, D3D11 cb:
With compromise: 6.8 ms
With compromise and measure each frame's peak luminance: 8.8 ms (no dropped frames)
With no compromise: ~13 ms, with spikes up to 17 ms (a few dropped frames)

Edit2: OK, testing the actual request this time (I hope). :o
D3D11 Native but with DXVA chroma upscaling disabled in trade quality for performance options:
No compromise: ~10ms, with spikes up to ~12 ms (no dropped frames)! :cool:

[ryrynz]

I don’t understand a word of what you are saying. 22ms isn’t “dying”

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.