madVR - high quality video renderer (GPU assisted)

[iSunrise]

You should really read what madshi writes. He only did Error Diffusion in DirectCompute (so far? :D)

And i'm on the latest beta as well.
You´re right, he only implemented error diffusion with this build. My fault. Got too excited there for a moment. :D

Need to go back to 327.23, this constant driver swapping is giving me a headache. Doesn´t really make comparisons easy.

[mrcorbo]

With DirectCompute, error diffusion dithering is working fine on my Radeon HD 6970 now. Playback is smooth with GPU usage around 30% while unchecking "use random dithering" which instantly caused stuttering with 99% GPU usage under OpenCL.

[iSunrise]

Here are some results with GPU-Z (went back to 327.23) with a GTX580. All results are taken in windowed fullscreen.

OpenCL vs. DirectCompute

432p 50fps - no smooth motion

http://abload.de/thumb/errordiffusion_openclfsfdj.png (http://abload.de/image.php?img=errordiffusion_openclfsfdj.png)http://abload.de/thumb/errordiffusion_directgxf77.png (http://abload.de/image.php?img=errordiffusion_directgxf77.png)

432p 50fps - smooth motion

http://abload.de/thumb/errordiffusion_openclamdmj.png (http://abload.de/image.php?img=errordiffusion_openclamdmj.png)http://abload.de/thumb/errordiffusion_direct2iimp.png (http://abload.de/image.php?img=errordiffusion_direct2iimp.png)

1080p 23.976fps - no smooth motion

http://abload.de/thumb/errordiffusion_openclhvdin.png (http://abload.de/image.php?img=errordiffusion_openclhvdin.png)http://abload.de/thumb/errordiffusion_directxxfg0.png (http://abload.de/image.php?img=errordiffusion_directxxfg0.png)

1080p 23.976fps - smooth motion

http://abload.de/thumb/errordiffusion_openclb0f9s.png (http://abload.de/image.php?img=errordiffusion_openclb0f9s.png)http://abload.de/thumb/errordiffusion_directtzewg.png (http://abload.de/image.php?img=errordiffusion_directtzewg.png)

1080p 60fps - no smooth motion

http://abload.de/thumb/errordiffusion_openclyzis0.png (http://abload.de/image.php?img=errordiffusion_openclyzis0.png)http://abload.de/thumb/errordiffusion_directgmdk4.png (http://abload.de/image.php?img=errordiffusion_directgmdk4.png)

Considering that this is only a test build, these are some impressive improvements. If NNEDI3 is planned to be ported, too, I probably could use a lot less restricted profiles and go with NNEDI3 64 neurons for luma doubling and NNEDI3 64 neurons for 4:2:2 -> 4:4:4 chroma upscaling on the majority of cases.

[Moony349]

Great job on the test build madshi.

My GTX 780 is playing 1080p content with 60fps smoothmotion / directcompute error diffusion and its only at 25% gpu load and 10ms rendering times with 334.67 drivers.

Turning off error diffusion brings it to 16% gpu load and 7ms rendering.

Looking forward to nnedi3!

[Mangix]

I keep being astonished how anyone could upload a text file without zipping it first. Such a waste of bandwidth...

I keep being astonished how anyone could upload a zip file instead of using a stronger compressor like 7-Zip. Deflate is really limiting with its 16KB window size.

(sorry, couldn't resist :D).

edit: After testing on my GTS 450, the DirectCompute version is clearly faster. It still drops frames(720p > 1080p) but at a much slower rate. Overclocking might fix this.

madVR however shows the same rendering times(actually slightly lower with OpenCL). This is definitely not correct.

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.

[madshi]

Happy to hear the positive feedback on the test build! :) Guess I'll convert NNEDI3 to DirectCompute next. Don't expect too much of a performance improvement there, though. Maybe a small improvement. At least it should make NNEDI3 work with the latest NVidia drivers.

[pirlouy]

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

Like others, visible improvements with this build:
30ms -> 20ms on a 1080p sample
45ms -> 25 ms on a SD sample

[sexus]

so directcompute now or random dithering, no more opencl error diffusion then? , wich is the way to go?

and i guess the neuron count will change once NNEDI3 is done in directcompute? and anybody with a titan please post your settings

[DragonQ]

FWIW, I'm playing with DirectCompute now, and it looks promising. But I will limit support to D3D11 capable GPUs, only, so Nvidia 2xx and AMD 4xxx GPUs will not be supported (only for DirectCompute features, of course).
Fair enough, it's an old series of GPUs. When I bought the GTS 250 4.5 years ago it was probably lower-mid-range then, so now I assume it's firmly in the "ancient" category. :D

Funnily enough I thought that GPU had died last night when I had no display on my desktop, but after reseating it everything's working again. Having to buy a new GPU would've been annoying financially but the upshot would've been better MadVR performance. ;)

Here's a first test build using DirectCompute instead of OpenCL for Error Diffusion. I've only tested this on my AMD HD7770 so far, so I don't know if it also works on NVidia or even Intel. What I can say is that first initialization seems to be a bit slower, but actual rendering performance seems to be noticeably better, mainly due to interop between D3D9 and DirectCompute being almost free. Give it a try and let me know whether it works for you and how performance compares to v0.87.4 with OpenCL Error Diffusion. Thx.

http://madshi.net/madVRdirectCompute1.rar

Oh yes, this requires D3D11 to be installed, and a D3D11.0 capable GPU.
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.

[Mangix]

hmm when I enable error diffusion I get a tremendous improvement in rendering times(~15ms) when I reduce the CPU, GPU, and Present queue sizes. Needs more testing.

[Kalanoch]

My results with the DirectCompute test build seem to be different from what most people are reporting.

(average/max rendering times in ms)

0.87.4:
09 / 10 1080p->1440p lanc3 upscaling smooth motion w/ random dithering
30 / 32 1080p->1440p lanc3 upscaling smooth motion w/ error diffusion
18 / 19 720p->1440p nnedi3 16neur doubling smooth motion w/ random dithering
40 / 42 720p->1440p nnedi3 16neur doubling smooth motion w/ error diffusion

0.87.4 directcompute test:
10 / 10 1080p->1440p lanc3 upscaling smooth motion w/ random dithering
35 / 60 1080p->1440p lanc3 upscaling smooth motion w/ error diffusion
18 / 18 720p->1440p nnedi3 16neur doubling smooth motion w/ random dithering
43 / 80 720p->1440p nnedi3 16neur doubling smooth motion w/ error diffusion

Using error diffusion on the test build resulted in a very large maximum rendering time of much higher than the average, during constant playback, and often led to numerous dropped frames. I'd see spikes of 150+ ms during the middle of playing a file, not just right after opening. GPU usage on the test build would vary during playback from ~80-90% while the 0.87.4 build had a steady GPU usage of 92% (on the 720p->1440p using nnedi3 doubling). Somehow the test build was using less GPU power, but max frame rendering time was much higher.

All tests performed with smooth motion and debanding enabled, using windowed overlay and separate device for presentation. CPU queue 24, GPU queue 12, 6 backbuffers. The only option checked in trade quality for performance is 'shader results in 16bit buffer instead of 32bit'. Test files were 23.976 fps, 10-bit h.264; the 720p file encoded in 4:4:4 with a bitrate of 2000 kBit/s and the 1080p file encoded in 4:2:0 with a bitrate of 10000 kBit/s.

Running Windows 7 and an nVidia GTX 670 with 327.23 drivers. And yes, I double checked to make sure I was using the correct madVR.ax files!

EDIT: As others have also discovered, this is definitely a memory issue. The directcompute build, while technically faster, ends up maxing the memory capacity of my video card, leading to the spikes mentioned. Reducing my GPU queue to 10 and backbuffers to 4 stabilizes it and results in a speed improvement of several ms over the standard 0.87.4 build. However, my video memory is close to maxed out at those settings. This seems to be something that mostly affects those of us with higher resolution monitors upscaling to 1440p, because of how much memory it takes. Hopefully the NNEDI3 using directcompute won't also require an additional 400mb of video memory..

[leeperry]

What I can say is that first initialization seems to be a bit slower, but actual rendering performance seems to be noticeably better.
Ouh very nice, thanks!

So that's as much NNEDI chroma/luma+ED goodness I could squeeze w/o dropping frames off a 720p24 movie@1080p with the old build in FSE: http://thumbnails110.imagebam.com/30580/656cb3305793271.jpg (http://www.imagebam.com/image/656cb3305793271)

and now with the new one: http://thumbnails112.imagebam.com/30580/228927305793272.jpg (http://www.imagebam.com/image/228927305793272)

Initialization is indeed slow now but this is gonna kill once you'll have NNEDI get through this pipe too :)

[XMonarchY]

Awesome new build! I get a slight improvement!

I guess this build is not dependent on OpenCL, so new nVidia drivers should work with it, right? I can test if need be.

About that disadvantage (DXVA NV12 surface) - who/what does it affect? Would it affect those are using DXVA to decode video with filters like LAV? Would it affect nVidia CUVID decoding also?
Sorry, I'm really new to this and I'm trying to understand everything, so my questions can be stupid...

[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 :sly:

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

640x360 23.976 -> 2560x1440 60hz
madVR 0.87.4 OpenCL Dither + Smooth Motion + GPU Queue 16 + Preset Queue 16 = ~1.9GB GPU RAM, Render Time +21ms vs Random Dither
madVR Test Direct Compute Dither + Smooth Motion + GPU Queue 16 + Preset Queue 16 = >2GB GPU RAM, Dropped Frames

madVR 0.87.4 OpenCL Dither + Smooth Motion + GPU Queue 8 + Preset Queue 8 = ~1.2GB GPU RAM, Render Time +21ms vs Random Dither
madVR Test Direct Compute Dither + Smooth Motion + GPU Queue 8 + Preset Queue 8 = ~1.6GB GPU RAM, Render Time +18ms vs Random Dither

Direct Compute Dither = ~17% faster, 3ms lower


1920x1080 60hz -> 2560x1440 60hz
madVR 0.87.4 OpenCL Dither + GPU Queue 16 + Preset Queue 16 = ~1GB GPU RAM, Render Time +11ms vs Random Dither
madVR Test Direct Compute Dither + GPU Queue 16 + Preset Queue 16 = ~1.4GB GPU RAM, Render Time +9ms vs Random Dither

Direct Compute Dither = ~22% faster, 3ms lower

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.

[*Touche*]

I think this means when watching 720p on 1080p with NNEDI3 chroma upscaling and luma only doubling:
Chroma is scaled to 720 using NNEDI3.
Luma is scaled to 1440 using NNEDI3.
Chroma is scaled to 1080 using image upscaling.
Luma is scaled to 1080 using image downscaling.

But it might be:
Chroma is scaled to 720 using NNEDI3.
Luma is scaled to 1440 using NNEDI3.
Chroma is scaled to 1440 using image upscaling.
Everything is downscaled to 1080 using image downscaling.

Anyone knows which one is it?

[cyberbeing]

Anyone knows which one is it?

The first one, I asked madshi this same question earlier.

[iSunrise]

@cyberbeing:
Just out of interest, is there a reason why you have such high queues with your pretty fast Kepler GPU? Because I never run into any problems whatsoever with the absolute minimum queue sizes and I only have a GTX580. I also run smooth motion and pretty high settings, never had any problem or dropped frames because of low queues. Was there a specific problem you ran into or did you just set them to have some breathing room (to ease your mind)?

Although I must say that I scale everything to a native resolution of 1080p/1200p, 1600p seems to be a bit more demanding of course.

If NV optimizes their drivers further and they finally fix their OpenCL stuff, I hope that we have some kind of switch (or a fallback) so we can decide if we want to use OpenCL or DirectCompute. At least for now, as it seems that there doesn´t seem to be an optimal solution for everyone.

[Shiandow]

Let's say for pixel X the red and blue components are spot on 8bit, but the green component is 0.5 pixel off 8bit. In this case when using RGB, the 0.5 green error will be spread only to the green channel. However, when spreading the error to the neighbor pixels in YCbCr, that should also affect the red and blue pixels. Or am I wrong? To be honest, I haven't really fully thought this through yet...

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.

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

original image (http://i.imgur.com/KxJWPwl.jpg)

result (http://i.imgur.com/lu0xcsF.jpg)

from left to right: RGB, Linear Light YCbCr, Linear Light RGB
from top to bottom: Nearest, dithering, error diffusion

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:

original image (http://i.imgur.com/fMeoyaC.jpg)

result (http://i.imgur.com/EB8YJb3.jpg)

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.

[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. :D

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.

[Mangix]

If NV optimizes their drivers further and they finally fix their OpenCL stuff, I hope that we have some kind of switch (or a fallback) so we can decide if we want to use OpenCL or DirectCompute. At least for now, as it seems that there doesn´t seem to be an optimal solution for everyone.

Who does DirectCompute not work for? So far I've seen it work on Intel, AMD, and Nvidia cards.

Old cards won't work but it's not like madVR is designed for old hardware.

[DragonQ]

Who does DirectCompute not work for? So far I've seen it work on Intel, AMD, and Nvidia cards.

Old cards won't work but it's not like madVR is designed for old hardware.
Nev said that DirectCompute is much slower than OpenCL on Intel, which could be a problem.

[cyberbeing]

@cyberbeing:
Just out of interest, is there a reason why you have such high queues with your pretty fast Kepler GPU? Because I never run into any problems whatsoever with the absolute minimum queue sizes and I only have a GTX580. I also run smooth motion and pretty high settings, never had any problem or dropped frames because of low queues.

There are still rare cases which cause render times with an 8bit 3DLUT on NVIDIA to spike quite high. Unlike AMD, NVIDIA doesn't have issues with setting very high queues. And since I usually run high refresh rates like 96Hz & 120Hz, it made logical sense for me to use the maximum Present Queue size of 16 with matching GPU Queue size for added reliability.

I only recently upgraded to the GTX 770 a couple months ago, and before that I was running a GT 440 DDR5 1GB when I initially decided on these settings. If I was using the same settings I was with the GT 440, I could probably lower the queue sizes. Though now that we have NNEDI3, I don't think I'd want to, except in instances like Direct Compute + Smooth Motion where it causes me run out of GPU ram.

If NV optimizes their drivers further and they finally fix their OpenCL stuff, I hope that we have some kind of switch (or a fallback) so we can decide if we want to use OpenCL or DirectCompute.

Despite breaking the OpenCL <-> D3D9 interop in their latest drivers, it would seem from the results people are posting that NVIDIA's implementation was actually a few orders of magnitude faster than AMD's. Not that this matters much though, since AMD seems to run the actual heavy GPU compute stuff in madVR around twice as fast as NVIDIA GPUs with similar theoretical performance.

[Kalanoch]

Who does DirectCompute not work for? So far I've seen it work on Intel, AMD, and Nvidia cards.

Old cards won't work but it's not like madVR is designed for old hardware.

DirectCompute is a bit faster but at least in its current implementation uses a LOT more video memory than OpenCL. It maxed out my video memory, leading to spikes in rendering time and frame drops until I lowered the queues. If NNEDI3 using DirectCompute also uses just as much extra memory it may make it difficult to upscale to 1440p without capping out and dropping frames. Hopefully there is some kind of optimization that madshi can do, though!

[iSunrise]

Who does DirectCompute not work for? So far I've seen it work on Intel, AMD, and Nvidia cards.

Old cards won't work but it's not like madVR is designed for old hardware.
Sure it works, at least in theory. OpenCL should also work too, at least in theory. In the real world though, you have to try and find a good common ground that just works, and that´s why madshi decided to try DirectCompute now. If DirectCompute has a lot higher VRAM usage though, it would limit some people a lot if they wouldn´t have the choice anymore. But I was just thinking loud, if madshi doesn´t feel the need for it (he already has the code for both, anyway) he won´t offer it. But it´s not the question of what I want (my card is powerful enough), I think about other people in this case, too. If he only needs to maintain one code path it´s definitily easier for him, though.

But let´s wait for madshi when he has more time. It´s only a first test build, maybe he can improve utilization somehow.

There are still rare cases which cause render times with an 8bit 3DLUT on NVIDIA to spike quite high. Unlike AMD, NVIDIA doesn't have issues with setting very high queues. And since I usually run high refresh rates like 96Hz & 120Hz, it made logical sense for me to use the maximum Present Queue size of 16 with matching GPU Queue size for added reliability.

I only recently upgraded to the GTX 770 a couple months ago, and before that I was running a GT 440 DDR5 1GB when I initially decided on these settings. If I was using the same settings I was with the GT 440, I could probably lower the queue sizes. Though now that we have NNEDI3, I don't think I'd want to, except in instances like Direct Compute + Smooth Motion where it causes me run out of GPU ram.
Thanks for the explanation. Makes sense, since you´re running quite a hefty setup with 3DLUT, high refresh rates and all the advanced madVR features. And if you have RAM to spare, why not.

[trip_let]

Nev said that DirectCompute is much slower than OpenCL on Intel, which could be a problem.

Oh yeah, Intel.

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

Maybe different if fullscreen mode. I don't really have more time to test today. Maybe way slower if pre-Ivy Bridge Intel? Or if more RAM is being used? Those are just guesses and I'm not going to find out now.

[mindbomb]

DirectCompute has one disadvantage compared to OpenCL: It cannot handle DXVA NV12 surfaces.

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

[noee]

Quick and dirty report:

With DC, I can run ErrDiff with no drops, but only if I turn SM FRC off, whereas before, OpenCL ErrDiff simply dropped frames no matter what. 1080p on 8-bit panel.

[druneau]

AMD 290x

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

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

[cyberbeing]

DirectCompute has one disadvantage compared to OpenCL: It cannot handle DXVA NV12 surfaces.Doesn't dx11.1 on windows 8 address this in some way?

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.

[andybkma]

Here's a first test build using DirectCompute instead of OpenCL for Error Diffusion. I've only tested this on my AMD HD7770 so far, so I don't know if it also works on NVidia or even Intel. What I can say is that first initialization seems to be a bit slower, but actual rendering performance seems to be noticeably better, mainly due to interop between D3D9 and DirectCompute being almost free. Give it a try and let me know whether it works for you and how performance compares to v0.87.4 with OpenCL Error Diffusion. Thx.

http://madshi.net/madVRdirectCompute1.rar

Oh yes, this requires D3D11 to be installed, and a D3D11.0 capable GPU.

Windows 7 64-bit, Nvidia Optimus 650M (overclocked close to 660M), Driver 331.82 (Notebook Driver)

New madVRdirectCompute1.rar looks to be unusable on this setup. Unchecked the "Use random dithering instead of OpenCL error diffusion" and I get a picture now instead of black screen before (known problems with OpenCL & Nvidia). 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

Just reporting in my test result as requested...

[Asmodian]

Here's a first test build using DirectCompute instead of OpenCL for Error Diffusion.
Give it a try and let me know whether it works for you and how performance compares to v0.87.4 with OpenCL Error Diffusion. Thx.

OpenCL (87.4) 36.4 ms 82% GPU, 2.6GB video memory used, ~330W
DirectCompute (test build) 35.1 ms 78% GPU, 3.5GB video memory used, ~325W
GTX Titan 1071 MHz, 720p24 -> 1440p60, queues 32/24/8.

madVR can use more video memory than any video game I have played. :D

[THX-UltraII]

It might be a bug with memory usage, triggered only sometimes or rather if some conditions are met. Also most of us (probably) haven't jumped the 4K displays bandwagon yet ;)
When you get to testing maybe try lowering the queues and see if the crashes persist, since you might be running out of system RAM or GPU VRAM.

edited posting

[omarank]

I keep being astonished how anyone could upload a text file without zipping it first.

Well the file size was small enough that I didn't bother zipping it. I didn't realize that it would astonish you.. :o

Anyway, I believe the debug log will help you identify the issue.

[James Freeman]

Excuse my ignorance but what Error Diffusion actually does?

If I understood correctly, dithering adds random (or not) noise using the two adjacent colors to smooth the gradient in a lower bit picture.
This is perfect for fixing the error/banding resulting from stretching 16-235 to 0-255.

Testing with AVS709HD Greyscale-Ramp.
When I set range to 16-235 I see no gradients, then I switch between Dithering On/Off to test the visible random noise.
I can hardly see the noise when MadVR set to 8-bit (dithering on/off in 16-235), although in 6-bit I see a lot of noise.

I see no difference between Random & ED Dithering in terms of noise or picture quality.
So what ED actually does?
How is it an improvement over random dithering?

Thanks

[bacondither]

Excuse my ignorance but what Error Diffusion actually does?

Here is some reading for those who indulge yourselves...
http://caca.zoy.org/wiki/libcaca/study/introduction

Is ordered dithering implementable in a pixel shader?
If so, it would be nice with a dither consisting of something like 50% supercell (http://caca.zoy.org/browser/web/trunk/www/study/out/lena2-6-2.png?format=raw) ordered matrix and 50% TPDF dither.

[Ver Greeneyes]

I can hardly see the noise when MadVR set to 8-bit (dithering on/off in 16-235), although in 6-bit I see a lot of noise.

I see no difference between Random & ED Dithering in terms of noise or picture quality.IIRC error diffusion is only enabled when you set it to 8-bit mode (can't tell if you know this from your post).

[James Freeman]

Here is some reading for those who indulge yourselves...
http://caca.zoy.org/wiki/libcaca/study/introduction

Two sentenses I wanted to quote from this site:
"The most famous error diffusion method is the Floyd-Steinberg algorithm."
"The result of this algorithm is rather impressive even compared to the best ordered dither results we could achieve."

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

IIRC error diffusion is only enabled when you set it to 8-bit mode (can't tell if you know this from your post).

No, I didn't know this.
I still see no difference between Random/ED at 8-bit.

Can anyone see the difference?
If so, please tell me in what content.

[nevcairiel]

Can anyone see the difference?
If so, please tell me in what content.

The difference is probably not all that obvious in moving content.

ED produces a lower noise floor in the image
Especially when you watch something like Anime which has a lot of flat color surfaces, the image may look a bit more "calm".

If you want to see the real difference, then take a screenshot of both and increase brightness and contrast on the image in your favorite image editor, you'll be able to see the dithering pattern.

[James Freeman]

Double post but its a different issue.

Why madVR does not clear the GPU memory after Stopping playback?
Ctrl+C the video (closing), clears some memory but not all.
The only way to free the GPU memory completely is by closing MPC-HC.

When I stop the movie and run it again (without closing MPC), I can max the GPU memory (2GB) after few times of stopping and playing.

EDIT:
Thanks nevcairiel.

With the AVS709HD Black-Clipping pattern (B&W = no colors).
Random Dithering looks like random colorful RGB noise (I added color Saturation to see it more clearly).
Error Diffusion looks like organized pattern with only the color that the image consists of (B&W in this case).
Had to zoom x4 the Black-Clipping pattern too see the dithered pixels.

The difference IS there, but its so slight that in normal movie watching Random Dithering is completely fine (Its what we had before 0.87).
Besides, the difference is only visible in "FLAT" colored content like Test Patterns & Anime (which I don't have).

Most of the Movies (non animated) have dithering (proper blu-ray transfer from the studios) and grain/noise in them (from the Digital Camera or Film) so the "Error Diffusion vs Random Dithering" difference is non visible at all.
I can't even see the difference in a real movie content when switching Dithering On/Off... I see the effect only in the Greyscale-Ramp pattern I have from AVS709HD.


@Shiandow
It appears the MadVR already using ED & YCbCr because I do not see any colors in my B&W test patterns with ED.

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

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

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]

Can't really tell you performance numbers when the OSD doesn't draw. :)
True! :o

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.

It's funny to see you care that much about DXVA now compared to the beginning of madVR. :p
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.

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.

EDIT: As others have also discovered, this is definitely a memory issue.
Try test build 2.

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.

Doesn't dx11.1 on windows 8 address this in some way?
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.

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 :sly:
AMD 290x

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

Random Dithering ~7ms
OpenCL ED ~24ms
DirectCompute ED ~11ms
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!
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.

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?

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.

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

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

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.

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?

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.

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.

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.

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.

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

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

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]

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 (http://i.imgur.com/Z7lvKZD.jpg), dithering (http://i.imgur.com/eH3OmWU.jpg).

[sneaker_ger]

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]

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:

http://abload.de/img/dcbuild2_error7ikcn.png

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

[cca]

Thanks, that was fast.

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

http://abload.de/img/dcbuild2_error7ikcn.png

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

Getting the exact same problem.