madVR - high quality video renderer (GPU assisted)

[cca]

Tried the new DirectCompute version. Improved performance on one hand, but unstable spikes in rendering times on the other. Perhaps it can be optimized in future builds, for now it's not consistent enough to use with my setup.

[Neet009]

I test the DirectCompute build, it seems this build has great performance improvement in my system.

Hardware:AMD HD 7750 1GB DDR5 (driver:13.12)
OS:win7 64
Settings:chroma upscaling - Bicubic75+AR
image downscaling - Catmull-Rom+AR+LL
debanding on(set to low)
FSE mode
cpu queue 20/gpu queue 12/present queue 12
unckecked all option of "trade quality for performance" except the error diffusion.

movie resolution 1920*1080 23.976fps (smooth motion on)
target resolution 1440*810
random dithering:GPU loading 33%, rendering time 14ms
OpenCL error diffusion: 78%, 33.5ms
DirectCompute error diffusion: 44%, 19ms

movie resolution 1920*1080 60i (smooth motion off, deinterlacing video mode on)
target resolution 1440*810
random dithering:75%, deinterlace time 0.95ms, rendering time 11.5ms
OpenCL error diffusion: 95%, 5.5ms, 22.5ms
DirectCompute error diffusion: 87%, 0.95ms, 14ms

The performance improvement is amazing!
But I still run into a problem, when testing DirectCompute error diffusion build, one of my test files dropped frames in some scenes. I test it more than 10 times, and it dropped frames in the same scene. It doesn't happen with the random dithering and the OpenCL error diffusion build. I don't know if it is a bug or not, all queues is full and gpu loading is lower than 50%. When drop frame occuring, the queues down to zero suddenly, and I noticed that gpu memory usage increase about 20MB after the frames dropped.
Trying to change the setting value of the queue, it doesn't make any help.

here is the sample:
https://www.mediafire.com/?dwaon36dg2fpbbh
drop frames in 00:00:50

[Thunderbolt8]

DirectCompute works, but is not really fast here (gtx 760m)

24p: from 25% load, 8ms to 52% load, 19ms
60p: from 50% load, 8ms to 80% load, 22ms --> dropping frames.

[kasper93]

DirectCompute version is almost free on my HD5870! Really good work I think that performance comparisons are meaningless because of such significant difference. But I made one. I did lock my GPU clocks to ensure that they won't change during test. (which happen quite often with light workload)

720p23
---- | SM off | ED off => 2.89ms
---- | SM on | ED off => 4.03ms
DC | SM off | ED on => 4.91ms
DC | SM on | ED on => 7.70ms
OCL | SM off | ED on => 36.40ms
OCL | SM on | ED on => 71.70ms

upscaled to full hd:
DC | SM on | ED on => 17.65ms
OCL | SM on | ED on => 187.80ms

It was on 60Hz display. Good job! I also noticed that OCL is marginally faster with latest AMD beta drivers, but it's almost the same as before...

[6ari8]

Originally Posted by 6ari8

Thanks for the update!

I'm having a problem after updating from 86.1 to 86.3. I play my videos on an LCD and didn't have this problem ever with madVR, it only just appeared right after the update. Same settings as before. I think it has to do with the scaling algorithm (Image Upscaling: Lanczos 8 taps, Anti-Ringing, Linear Light). It goes away when I drop it to lower than 8 taps or disable the Anit-ringing filter. I'm not sure why though since these are the same settings I used before with no problems.


(Image too big for thread)
http://img197.imageshack.us/img197/7114/madvr.png

Originally Posted by 6ari8

I updated the Nvidia driver, removed all codecs, madvr, and mpc-hc then reinstalled but nothing has changed.

I found that the only combination that produces this output is the following:
1. Lanczos 8 taps.
2. Activate anti-ringing filter.
3. Use full screen (either windowed or exclusive mode)
4. Use on external monitor.




Can you give some examples? Because I don't see anything bad caused by it.

Thank you very much for the updates.

I just wanted to report that this problem persists until 86.11 but since the 87.0 update and after, this problem disappeared completely!

I'm getting the green screen with nnedi3 chroma upscaling, dark screen with doubling but I know that's because of the drivers.

[madshi]

Originally Posted by nevcairiel

Can't really tell you performance numbers when the OSD doesn't draw.

True!

Originally Posted by Mangix

edit2: One other difference is that the DirectCompute version definitely has higher max rendering times. 144ms vs. ~120ms. The dropped frames are sudden and inconsistent with DirectCompute.

Could have to do with higher GPU memory usage. Try test build 2.

Originally Posted by pirlouy

It's funny to see you care that much about DXVA now compared to the beginning of madVR.

Well, I mainly care about DXVA deinterlacing because that's currently the only video mode deinterlacing algorithm supported by madVR. I don't really like DXVA much, though.

Originally Posted by DragonQ

When you say D3D11 has to be installed, does that basically mean Windows Vista or higher with all Service Packs and Platform Updates installed? AFAIK there's no separate DirectX installer past 9.0c.

I think one of the Vista SPs or the Platform Update comes with D3D11.

Originally Posted by Kalanoch

EDIT: As others have also discovered, this is definitely a memory issue.

Try test build 2.

Originally Posted by XMonarchY

About that disadvantage (DXVA NV12 surface) - who/what does it affect?

No one/nothing. DirectCompute can't do everything I would like it to do, but there are other ways to do what I need, so it's no problem.

Originally Posted by mindbomb

Doesn't dx11.1 on windows 8 address this in some way?

Originally Posted by cyberbeing

Seems like it may when ExtendedResourceSharing is supported, but this does not appear to be one of those things which were backported to Win7 in that Platform Update.

AFAIK, D3D9 <-> D3D11 resource sharing does not support NV12 DXVA surfaces. Current DXVA decoders are using D3D9 and not D3D11.

Originally Posted by tFWo

Used the same file and the same settings as before on 270X.

OpenCL version:
23ms (SM off, ED off)
36ms (SM off, ED on)
24ms (SM on, ED off)
51ms (SM on, ED on)

DirectCompute version:
23ms (SM off, ED off)
25ms (SM off, ED on)
24ms (SM on, ED off)
27ms (SM on, ED on)

Nice

Originally Posted by druneau

AMD 290x

720p to 1285p (non fullscreen on a 1440p screen)

Random Dithering ~7ms
OpenCL ED ~24ms
DirectCompute ED ~11ms

Originally Posted by Neet009

I test the DirectCompute build, it seems this build has great performance improvement in my system.

Hardware:AMD HD 7750 1GB DDR5 (driver:13.12)
OS:win7 64
Settings:chroma upscaling - Bicubic75+AR
image downscaling - Catmull-Rom+AR+LL
debanding on(set to low)
FSE mode
cpu queue 20/gpu queue 12/present queue 12
unckecked all option of "trade quality for performance" except the error diffusion.

movie resolution 1920*1080 23.976fps (smooth motion on)
target resolution 1440*810
random dithering:GPU loading 33%, rendering time 14ms
OpenCL error diffusion: 78%, 33.5ms
DirectCompute error diffusion: 44%, 19ms

movie resolution 1920*1080 60i (smooth motion off, deinterlacing video mode on)
target resolution 1440*810
random dithering:75%, deinterlace time 0.95ms, rendering time 11.5ms
OpenCL error diffusion: 95%, 5.5ms, 22.5ms
DirectCompute error diffusion: 87%, 0.95ms, 14ms

The performance improvement is amazing!

Originally Posted by kasper93

DirectCompute version is almost free on my HD5870! Really good work I think that performance comparisons are meaningless because of such significant difference. But I made one. I did lock my GPU clocks to ensure that they won't change during test. (which happen quite often with light workload)

720p23
---- | SM off | ED off => 2.89ms
---- | SM on | ED off => 4.03ms
DC | SM off | ED on => 4.91ms
DC | SM on | ED on => 7.70ms
OCL | SM off | ED on => 36.40ms
OCL | SM on | ED on => 71.70ms

upscaled to full hd:
DC | SM on | ED on => 17.65ms
OCL | SM on | ED on => 187.80ms

Some great numbers from AMD users! Seems that without the expensive OpenCL interop cost, you guys can now enjoy the good compute performance of your GCN GPUs. But try test build 2, it might be even faster, although only slightly.

Originally Posted by Neet009

But I still run into a problem, when testing DirectCompute error diffusion build, one of my test files dropped frames in some scenes. I test it more than 10 times, and it dropped frames in the same scene. It doesn't happen with the random dithering and the OpenCL error diffusion build. I don't know if it is a bug or not, all queues is full and gpu loading is lower than 50%. When drop frame occuring, the queues down to zero suddenly, and I noticed that gpu memory usage increase about 20MB after the frames dropped.
Trying to change the setting value of the queue, it doesn't make any help.

This might have to do with high RAM usage. Does the problem still occur in test build 2?

Originally Posted by cyberbeing

The Direct Compute build eats quite a bit more GPU ram, to the point that 2GB on my GTX 770 gets strained with my normal queue settings & smooth motion.

Try test build 2.

Originally Posted by cyberbeing

Overall still quite slow on GK104 it seems. In both cases, saving only 3ms isn't significant enough to make a difference in usable settings.

That's a smaller performance increase as most other NVidia users seem to report. That's a bit strange. Maybe test build 2 works a bit better for you? Well, if all else fails, it's still slightly faster, and works with all drivers. So it's still better than OpenCL, I guess...

Originally Posted by trip_let

Well, I never really followed through and figured out why my GT 650M / HD 4000 (using GT 650M) setup hates OpenCL even with the older drivers, but error diffusion with DirectCompute sure works for me, so that's definitely nice. No rendering times performance comparison for me because no OpenCL results from me. Or rather, it got infinitely faster.

I didn't try synthetic test material, but the difference between dithering and error diffusion was invisible to me on the computer monitor I use, the Dell P2414H. It's probably some combination of the size (23.8" 1080p AH-IPS) and the fact it's 6 bits anyway and needs AFRC for 8 bits.

Yeah, under these circumstances error diffusion probably has no use for you.

Originally Posted by trip_let

I opened 720p file, no scaling except chroma Bicubic 60 AR, windowed mode. Using HD 4000 (1150 MHz clock speed cap version).

Dithering: 3 ms
Error diffusion OpenCL: 30 ms
Error diffusion DirectCompute: 33 ms

Is test build 2 still slower than OpenCL?

Originally Posted by andybkma

Played a vid in window mode fine albeit with a tad higher CPU consumption but after about 20 seconds in FSE mode, my 650M graphics card crashed, reverted to VGA resolution, and an error message popup saying that graphics memory low blah blah blah

Try test build 2.

Originally Posted by James Freeman

What ED method MadVR uses (Floyd-Steinberg or other)?
What are the artifacts of random dithering compared to ED?

It's somewhat similar to Floyd-Steinberg with serpentine scanning, but I'm using different weights and 16x16 pixel blocks.

Originally Posted by 6ari8

I just wanted to report that this problem persists until 86.11 but since the 87.0 update and after, this problem disappeared completely!

Cool! I'm not sure why the problem is gone, but I'm happy to hear that.

Originally Posted by Shiandow

Well, your not wrong but from what I understood you were planning to do something like this:

-find error in YCbCr.
-convert pixel value to YCbCr.
-add error to this value
-convert back to RGB
-round to 8bits

This does not work, since converting from RGB to YCbCr is linear, which means that this will give the same answer as:

-find error in RGB.
-convert pixel value to YCbCr.
-convert back to RGB
-add error to this value
-round to 8bits

Which just wastes time by converting everything but doesn't improve your output.

But there is a way to achieve what you want, unfortunately it could be quite a bit slower. You basically need to do the following:

-find error in YCbCr.
-find all possible ways to round the pixel value to 24bit RGB.
-convert these to YCbCr
-find the one which is closest to x, where x is the pixel value converted to YCbCr plus the error.
-use this one as the final 24bit RGB value.

This does give a different answer, because transforming to YCbCr changes the relative distance between colours.

Yes, you're right.

Originally Posted by Shiandow

To see how much this actually matters I've decided to just compare the algorithms. First lets test it on a simple gradient

[...]

To make it more obvious I used a small resolution and lowered the amount of possible values per channel to just three, i.e. 0 1/2 and 1.

The most obvious difference between YCbCr and RGB is that YCbCr almost exclusively uses gray pixels whereas in RGB it uses coloured pixels as well. I did need to give the top left pixel a different colour because otherwise this doesn't happen since it does the exact same thing on every channel.

Note that using normal dithering it doesn't make a difference whether you do it in RGB or YCbCr, this follows more or less from the fact that the transformation is linear and can in fact be proven mathematically, but I digress. What does make a difference is whether you use linear light or not. I'm not sure if you are doing so already but if not you should consider doing normal dithering in linear light as well.

Another example on a more natural image:

[...]

In this case the difference are a bit less obvious but doing the error diffusion in YCbCr does seem to use colours which are closer to each other.

Again note that in this case performing dithering in linear light improves the amount of contrast quite a bit, but there is still no difference between YCbCr and RGB.

Thanks much for taking the time to research this - this is really interesting!!

FWIW, I've tested doing the error distribution in RGB linear light. There was a 10-20% drop in performance, and to be honest, in 8bit I did not see any improvement in image quality. The pattern was ever so slightly different, but even when zooming in 800% I could not say which one was better. So I think I might drop the linear light idea and stick to simple gamma corrected error diffusion. There's simply no point spending more processing time if there's no visible image quality benefit at 8bit. It seems to me that the higher the bitdepth is, the lower the benefit of using linear light is, for error diffusion...

-------

Here's test build 2 with lowered GPU RAM usage, hopefully faster initialization, and maybe slightly lower rendering times:

http://madshi.net/madVRdirectCompute2.rar

Still only Error Diffusion.

[Shiandow]

Originally Posted by James Freeman

Excuse my ignorance but what Error Diffusion actually does?

Error diffusion works by trying to redistribute the rounding error to surrounding pixels. Dithering tries to hide the rounding error by rounding randomly in such a way that on average the rounding error is 0. This means that dithering adds noise to the original image, which can be annoying in some cases.

Quick, exaggerated, example: error diffusion, dithering.

[sneaker_ger]

Originally Posted by madshi

Here's test build 2 with lowered GPU RAM usage, hopefully faster initialization, and maybe slightly lower rendering times:

http://madshi.net/madVRdirectCompute2.rar

Still only Error Diffusion.

"Creating shader file failed" error message and black screen. HD 5850, Win 7 x64

[iSunrise]

Originally Posted by madshi

Here's test build 2 with lowered GPU RAM usage, hopefully faster initialization, and maybe slightly lower rendering times:

http://madshi.net/madVRdirectCompute2.rar

Still only Error Diffusion.

Thanks, that was fast.

Unfortunately, I get an error directly after loading a clip:



This doesn´t happen with the first build (double-checked).

[cca]

Originally Posted by iSunrise

Thanks, that was fast.

Unfortunately, I get an error directly after loading a clip:



This doesn´t happen with the first build (double-checked).

Getting the exact same problem.

[madshi]

Sorry.

http://madshi.net/madVRdirectCompute3.rar

[James Freeman]

Here is the perfect example:


Download and zoom with a viewer (disable smoothing or Billinear filtering) or Paint.

Shiandow, thanks for the picture and explanation.

Originally Posted by madshi

Here's test build 3 with lowered GPU RAM usage, hopefully faster initialization, and maybe slightly lower rendering times:

All of them Correct. Thank You !!

[Shiandow]

Originally Posted by madshi

FWIW, I've tested doing the error distribution in RGB linear light. There was a 10-20% drop in performance, and to be honest, in 8bit I did not see any improvement in image quality. The pattern was ever so slightly different, but even when zooming in 800% I could not say which one was better. So I think I might drop the linear light idea and stick to simple gamma corrected error diffusion. There's simply no point spending more processing time if there's no visible image quality benefit at 8bit. It seems to me that the higher the bitdepth is, the lower the benefit of using linear light is, for error diffusion...

I'm not exactly sure what the difference is between linear light and gamma correction, but it might indeed not be worth the trouble. Some kind of gamma correction should be used, but a small difference will almost completely vanish, especially when you use 8 bits. I also suspect that the difference between LL RGB and LL YCbCr will be so small that it's only detectable on very extreme cases, possibly only when dithering gray levels on a monitor with extremely vivid colours.

By the way do you also use some kind of gamma correction for normal dithering?

[burfadel]

I tried madVRdirectCompute2 and it came up with an error box titled 'Error Diffusion', and inside the box it said 'creating shader file failed'. It resulted in a black play window (using mpc-hc).

madVRdirectCompute1 worked fine! At least there was no errors and the display was fine, haven't checked to see whether it actually 'works'.

This is on Windows 8.1 x64, MPC-HC 1.7.3.4, and on a Radeon R9-280x running the Catalyst 14.1 beta drivers.

[nevcairiel]

Originally Posted by burfadel

I tried madVRdirectCompute2 and it came up with an error box titled 'Error Diffusion', and inside the box it said 'creating shader file failed'. It resulted in a black play window (using mpc-hc).

There is already a third version which fixes this.

Don't take this the wrong way, but tt would be beneficial to everyone if you read at least the last 5 posts before posting about already fixed errors.

[madshi]

Originally Posted by Shiandow

I'm not exactly sure what the difference is between linear light and gamma correction, but it might indeed not be worth the trouble. Some kind of gamma correction should be used, but a small difference will almost completely vanish, especially when you use 8 bits. I also suspect that the difference between LL RGB and LL YCbCr will be so small that it's only detectable on very extreme cases, possibly only when dithering gray levels on a monitor with extremely vivid colours.

By the way do you also use some kind of gamma correction for normal dithering?

I'm sorry, "gamma corrected error diffusion" was an incorrect term. I meant simple error diffusion in gamma light. Meaning error diffusion in R'G'B', not in linear light RGB. As much as I'd love to improve image quality further by using linear light instead of gamma light, I just cannot see a difference, when using 8bit. And no, I don't do any gamma correction for normal dithering.

Can you see a difference betweem gamma and linear light if you use 8bit dithering with your test images instead of 2bit dithering?

[burfadel]

Originally Posted by nevcairiel

There is already a third version which fixes this.

Don't take this the wrong way, but tt would be beneficial to everyone if you read at least the last 5 posts before posting about already fixed errors.

I missed the fact there was a new version... I downloaded it, went and made a cup of coffee, came back, tried it, and reported it without realising it had been 15 minutes since I downloaded it and that the error was a common one!

[noee]

madshi, fwiw, some quick #s with Compute2, 1080p24 material, 60Hz playback

I can now run with SM on, before I could not.

With RandDither
Render: ~12ms
GPU: 28%
Mem: 529MB

With ErrDiff
Render: ~38ms
GPU: 88%
Mem: 520MB

No frame drops with either option. Compute1 would not do this.

Also, FSE mode with frames in advance = 10. Render/present queues do not max, but they avg ~7 out of 10....

[leeperry]

yesterday's DC build with extreme NNEDI chroma+luma upscaling & ED on 720p24@1080p that would take a few secs to fill the queues:

and with the new build, queues fill up instantly:

at this rate, I'll be able to go 128 neurons by the end of the week

[DragonQ]

Originally Posted by nevcairiel

There is already a third version which fixes this.

Don't take this the wrong way, but tt would be beneficial to everyone if you read at least the last 5 posts before posting about already fixed errors.

This thread moves fast sometimes. Very possible that the third version was posted whilst he was writing his post!