View Full Version : madVR - high quality video renderer (GPU assisted)
Soukyuu
5th February 2014, 01:08
I might be wrong, but didn't he answer that here?
The reason for that is that although DirectCompute in theory supports DX10 GPUs, too, it does so only with a very limited feature set. I'd have to use totally different code to make it all work on DX10 GPUs, and honestly, I think NVidia 2xx and AMD 4xxx users probably don't have the raw speed to make use of the new features, anyway, so I don't feel like spending a lot of additional development resources just to support DX10 GPUs. So I've limited support to native DX11 GPUs.
cyberbeing
5th February 2014, 01:16
Thanks, I missed that.
Kalanoch
5th February 2014, 01:28
Results from DirectCompute test build 3 vs test build 1:
720p->1440p with nnedi3 doubling 16 neurons, debanding and smooth motion on, no options checked in trade quality for performance. CPU queue size 24, GPU queue size 10, 4 backbuffers. Using Windows 7 and nVidia GTX 670.
OpenCL (0.87.4 release):
40.5 ms avg rendering time
1300 MB video memory used
94% GPU load
DC test build 1:
36 ms avg rendering time
1790 MB video memory used
83% GPU load
DC test build 3:
34 ms avg rendering time
1350 MB video memory used
77% GPU load
Works exactly as advertised, a drastic reduction in memory usage combined with a small increase in performance over the first test build. This brings memory usage back in line with OpenCL, but it is actually quite a bit faster now.
As a side note, this is with a file using h264, 10-bit 4:4:4, so Y410 surface. I'm curious, does this affect rendering times over the more common 4:2:0 (P010/NV12)? Like, are there any extra steps, or steps that are skipped?
cyberbeing
5th February 2014, 01:36
There seems to be a minor settings bug with NNEDI3 "chroma upscaling" which causes the last used to not be remembered when you disable it.
kasper93
5th February 2014, 01:36
Why do you even bother to ask about DX10? ED and NNEDI3 are very demanding even on new high-end GPUs. What do you expect with "ancient" GPUs? Like madshi said there would be not enough power. HD4xxx doesn't even gets drivers update from AMD for a year or something. Seriously, madVR will still work but without few features. It's time to move on or accept how things are.
Soon more and more software will drop XP support and I'm sure people will be whining about it, but really it is only trouble for developers to support deprecated APIs and other crap.
DragonQ
5th February 2014, 02:07
Uhm, according to madshi's post back here (http://forum.doom9.org/showthread.php?p=1665894#post1665894), it won't work on either nVidia 2xx nor ati 4xxx
I'm a bit sad about it, my 260GTX is still fully sufficient for my needs otherwise... but oh well.
Intel HD4000, not AMD.
mikecks
5th February 2014, 02:09
Just to clarify, to take advantage of the DirectCompute, I would uncheck 'use random dithering instead of OpenCL error diffusion' within the trade quality for performance options. But only when using the test build that madshi linked, is this correct? thanks.
DragonQ
5th February 2014, 02:14
Just to clarify, to take advantage of the DirectCompute, I would uncheck 'use random dithering instead of OpenCL error diffusion' within the trade quality for performance options. But only when using the test build that madshi linked, is this correct? thanks.
Yes..
cyberbeing
5th February 2014, 02:19
Why do you even bother to ask about DX10?
In my case, it was only pure curiosity about how harmful the limitations of the reduced Compute Shader 4.x API are, in a very general sense, compared to Compute Shader 5.0. I've personally never owned a GPU from the DX10 generation, so I'm unaffected by this either way as far as madVR is concerned. But it makes me wonder for other DirectCompute applications supporting only Compute Shader 4.x, if that harms performance significantly on DX11 GPUs.
ED and NNEDI3 are very demanding even on new high-end GPUs. What do you expect with "ancient" GPUs? Like madshi said there would be not enough power.
Yes they are, but it's not like DirectCompute or OpenCL can only be used for very demanding features. madshi had mentioned considering converting all shader operations in madVR to OpenCL eventually, most of which are very inexpensive in comparison. It makes me wonder now if DirectCompute would instead take this role, with the exception of DXVA, and what that means for future release GPU compatibility of old features in madVR.
drew_afx
5th February 2014, 02:51
dx9 implementation is polished as it can be afaik
old gpus can still run on "old" dx9 optimized madvr
new features not compatible with dx9 needs to be added to its own separate build...just like new gpu drivers are only supported on recent generation cards
ryrynz
5th February 2014, 03:01
It makes me wonder now if DirectCompute would instead take this role, with the exception of DXVA, and what that means for future release GPU compatibility of old features in madVR.
Guess they could just use old builds if it comes to that. Maybe madshi might even maintain older builds with whatever minor changes are made if everything goes OpenCL/DirectCompute.
I would expect though that anyone wanting the quality madVR delivers to have reasonably up to date hardware, it's a classic case of "Do you want to use the latest software? then use the latest hardware."
truexfan81
5th February 2014, 03:21
direct compute build 3 works with my gtx650, even with 24p content error diffusion doubles the gpu usage
Nachbar
5th February 2014, 06:08
I try to set the settings so when I play content my GPU won't go into high performance mode and error diffusion is just enough to do just that. To me, at least, it seems error diffusion is one of the last settings you would do as the other settings have a more noticeable impact.
Still pretty neat though and if directcompute decreases the performance hit on NNEDI3 i will be happy.
James Freeman
5th February 2014, 07:39
Just to clarify how good Error Diffusion is compared to Random Dithering.
These are actual screen shots from MPC-HC+MadVR.
http://www.mediafire.com/convkey/17dc/a42gcrd46hj3ycpfg.jpg
ryrynz
5th February 2014, 08:09
Nice illustration there. For those of you that can't see much of a difference between no dithering and error diffusion, look closer at error diffusion or turn up your brightness and you'll notice the wavy triangle pattern throughout.
It's a pretty big deal, Radeon upgrade for my HTPC in progress.
Wondering, considering the performance improvement from the DirectCompute build, what's the chances of a higher quality version of this being available? I can understand it not being of high priority..
bacondither
5th February 2014, 09:11
@madshi
The error diffusion algorithm creates a static pattern with no temporal dithering and can create strange "worm" patterns. Your code seems to hade static thresholds and could be improved as suggested at Cris's Image Analysis Blog (http://www.cb.uu.se/~cris/blog/index.php/archives/355)
Since this algorithm was published... The most simple and effective one is to add a little bit of randomness to the process, though this is unsuitable for some purposes. In the code above, change the threshold code to read:
% new = 255*(old >= 128);
new = 255*(old >= 128+(rand-0.5)*100);
Regular Floyd Steinberg (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg.png)
Floyd Steinberg with random (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg_noise.png)
I think it would be a cheap way to improve the quality of the error diffusion :)
andybkma
5th February 2014, 09:44
Here is my result with new DirectCompute Error Diffusion Trade Quality for Performance unchecked (v3 tested):
With SD material : (cuvid SD) In FSE mode I definitely see a better video quality but unfortunately my GPU load jumps up to a whopping 75% from 34% without the new DirectCompute dithering. Zoom Player shows slightly higher cpu consumption. Gosh that GPU load jump is just too much even with my overclocked 650M to almost 660M standards. But yes, the image for the SD material is definitely noticeably sharper and clearer and this is even after using avisynth script sharpener LSFMod. No dropped frames
With HD material (cuvid 720p): Again in FSE mode I definitely see better video quality but again my GPU load jumps up to 67% from 27% without the new DirectCompute dithering. Zoom Player shows about the same increase as SD slightly higher cpu consumption. No dropped frames. Note: With both SD & HD material I am also having occasional ZP crashing errors when switching out of FSE to window mode with the new DirectCompute dithering. Hopefully next time it happens I can catch the error number and report it.
But I really can't use this new dithering because it is just killing my gpu. The video quality improvement is great but I already know I will be having to leave this option checked (and use the less intensive random dithering instead). If this new dithering could become less GPU intensive that would be great
DarkSpace
5th February 2014, 09:54
Regular Floyd Steinberg (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg.png)
Floyd Steinberg with random (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg_noise.png)
I think it would be a cheap way to improve the quality of the error diffusion :)
However you look at it, I very much prefer the regular Floyd-Steinberg image over the random one...
Also, it's been said before, but usually movies change every frame (except Anime or cartoons), so you shouldn't be able to see the pattern anyway.
PetitDragon
5th February 2014, 10:04
@madshi
The error diffusion algorithm creates a static pattern with no temporal dithering and can create strange "worm" patterns.....
I confirm that too. :cool:
For you guys want to compare the two dithering methods and see how well they help debanding in real world video, the following clip is a good example (320MB):
https://www.mediafire.com/?yo6brmh02mrjxrs
ryrynz
5th February 2014, 10:21
so you shouldn't be able to see the pattern anyway.
I don't have a powerful enough graphics card to test anime with the error diffusion, can anyone actually see the pattern during viewing?
James Freeman
5th February 2014, 10:21
Did anyone tried so see (zoom in) with actual video content and prove the ED pattern is static?
I don't think the ED pattern is static, its just the screenshots.
EDIT:
Just tested it, it is static.
Vyral
5th February 2014, 10:37
With DirectCompute (v3):
Bilinear (Image + chroma), no deband, error diffusion: 24% GPU load, no dropped frames
Jinc 3 + AR (Image + chroma), medium deband, random dithering: 55% GPU load, no dropped frames
Jinc 3 + AR (Image + chroma), medium deband, error diffusion: 73% GPU load, no dropped frames
Nice :D
Same graphic card and approximately same result. As long as I'm not using Smooth motion, I get no dropped/delayed frames with error diffusion (OpenCL or DirectCompute).
I mainly watch 720p-24/30fps Anime on my 1080p-60Hz monitor. I vaguely remember a discussion from last year about Smooth motion having no benefit with Anime. Therefore, I'm considering to disable smooth motion and to use error diffusion and/or NNEDI with DirectCompute.
I don't have a powerful enough graphics card to test anime with the error diffusion, can anyone actually see the pattern during viewing?
Compared to random dithering, I see no visible pattern.
bacondither
5th February 2014, 11:04
Did anyone tried so see (zoom in) with actual video content and prove the ED pattern is static?
I don't think the ED pattern is static, its just the screenshots.
The error diffusion is static with static input. Images taken with around 1 seconds between(playing a video file of a static pattern).
No contrast enhancements or brightening was applied only 700% zoom.
Image1 (http://s14.postimg.org/4gl94a3y9/ED2_0s.png)
Image2 (http://s8.postimg.org/qa9ntd591/ED2_1s.png)
nevcairiel
5th February 2014, 11:06
Yeah classic Error Diffusion only depends on the input. Give it the same frame and it gives you the same output. Which has both its up and downsides.
James Freeman
5th February 2014, 11:12
Yes, Just tested it.
ED is static and I much prefer it that way (no extra noise).
I just love it...
DeBanding makes video silky smooth for non natively dithered content (super compressed video without dithering, aka. everything you get from the internet).
Blu rays look fantastic with Error Diffusion (They are natively dithered from High-bit to 8-bit by the studios, so no need for DeBanding).
Smooth Motion makes 24p watchable on 60Hz.
Great user selectable Upscalers and Downscalers.
bacondither
5th February 2014, 11:24
This is a contrast enhanced and zoomed image of the error diffusion algorithm:
http://s28.postimg.org/xicvdo4u5/ED_0s.png
You want to avoid the ugly worm pattern in 18, 20 ,24.
Every bar should look like number 21 via introducing some randomness in the thresholds as suggested by Cris Luengo (http://www.cb.uu.se/~cris/blog/index.php/archives/355).
And random dithering (http://s23.postimg.org/kg2kjoyob/RD_0s.png) if someone want to compare.
DragonQ
5th February 2014, 11:45
Playing a 720x384p/25 file at 1080p/25 on Intel HD4000. Smooth Motion is off, scaling is Bicubic75AR and Lanczos3AR.
Random dithering:
- Deinterlace: 1.90 ms
- Split: 1.27 ms
- Rendering: 3.05 ms
- Present: 0.08 ms
Error diffusion:
- Deinterlace: 10.09 ms
- Split: 2.78 ms
- Rendering: 31.35 ms
- Present: 0.10 ms
James Freeman
5th February 2014, 11:50
You want to avoid the ugly worm pattern in 18, 20 ,24.
Every bar should look like number 21 via introducing some randomness.
No you don't.
With super enhanced contrast you can actually see the pattern because the distance between grays (you enhanced the distance),
but it is invisible without enhancements because the distance between shades is ONE STEP (the closes to it in 8-bit), not tens of steps.
This is what contrast enhancement does you know...
If you can see the difference between 127 vs 128 PIXEL THIN lines of grey, you are inhuman.
Take the Color Picker tool in you soft and check what colors the 18 zigzag lines are made of (ED dithered), I'll tell you, its made of 2 & 3 (out of 255).
If you can see that with you naked eye... please contact the UN straight away because you may be trained as a pilot.
I much prefer static picture to a noisy one.
Kalanoch
5th February 2014, 11:57
Even with that black and white 'Miss Korea' video I cannot find any difference at all between random dithering and error diffusion, either during playback or comparing still frames. If it wasn't for the rendering times I wouldn't even know which was which. Is this because of my monitor (HP zr30w), or am I just blind, or what?
Soukyuu
5th February 2014, 12:07
I couldn't see the static pattern when I tested ED (openCL version), didn't even see any difference between ED and RD (LG W2442PA), but seeing those comparisons, the worm pattern is quite ugly.
Intel HD4000, not AMD.Bah, what's with the confusing naming... Ignore me then :P
James Freeman
5th February 2014, 12:11
Kalanoch,
No you are not blind, everything's fine.
I too don't see the difference in actual movie watching, only in paused & enhanced pictures.
What you may see is a "calmer" less noisy picture (assuming your panel is 8-bit and MadVR set to 8-bit).
iSunrise
5th February 2014, 12:13
If you can see the difference between 127 vs 128 PIXEL THIN lines of grey, you are inhuman.
Take the Color Picker tool in you soft and check what colors the 18 zigzag lines are made of (ED dithered), I'll tell you, its made of 2 & 3 (out of 255).
If you can see that with you naked eye... please contact the UN straight away because you may be trained as a pilot.
I much prefer static picture to a noisy one.
This has nothing to do with what you can see or what you think is best. Itīs about what is representing a more even dithered result. And if you donīt want to see the worm patterns, then I would seriously question anything that is coming from you in the future.
I welcome that some people are actually visiting this thread and present us some great alternative methods.
I would very much prefer madshiīs thoughts on this and if the current ED is even possible to improve without much of a performance hit.
The only thing that I see as problematic in the presented alternative, is the single pixels that magically appear in the black area of the "fixed" ED image. These white pixels would probably be harmful when you want your backlight to dim as far as it can.
James Freeman
5th February 2014, 12:14
but seeing those comparisons, the worm pattern is quite ugly.
Please carefully read this post: Contrast Enhancement (http://forum.doom9.org/showpost.php?p=1666265&postcount=22536).
This has nothing to do with what you can see or what you think is best. Itīs about what is representing a better result.
Do you understand what you've just said?
nevcairiel
5th February 2014, 12:17
While its only clearly visible with enhanced contrast, there is nothing wrong with wanting to tweak the algorithm to avoid it. Any enhancements you can make to the contrast-enhanced version are also enhancements to the real watching experience, even if not clearly obvious.
leeperry
5th February 2014, 12:20
Blu rays look fantastic with Error Diffusion
Fully agreed, I've gone back to the point where I watch my settings more than the movie itself....that hadn't happened in a long time :D
*Touche*
5th February 2014, 12:23
Do you guys use debanding for your ripped Blu Rays or is it usefull only for low quality/SD content.
madshi
5th February 2014, 12:24
FWIW, when I implemented Error Diffusion in OpenCL, I played with adding some randomness into the picture, even differently from one frame to the next. But I found that if the pattern changes from one frame to the next, the noise level "feels" higher, although it's objectively the same. So I dumbed the algorithm back down to simple and stupid non-random Error Diffusion.
I might be willing to look into re-introducing a little bit of randomness, but I'll probably do that in such a way that it's the same for every frame, so that with static content the pattern stays the same. This might get rid of the worm artifacts without increasing the subjective noise level. However, it's not going to be free, performance wise. None of the computing platforms (OpenCL, DirectCompute) has a random function built in, so I'd have to create a random texture and read from it, which costs memory bandwidth. That said, Error Diffusion is supposed to be the high-quality alternative, so I guess a small increase in rendering times to get rid of the worm artifacts might be worth it, even if most people are not going to be able to see the difference without boosting the contrast.
iSunrise
5th February 2014, 12:27
While its only clearly visible with enhanced contrast, there is nothing wrong with wanting to tweak the algorithm to avoid it. Any enhancements you can make to the contrast-enhanced version are also enhancements to the real watching experience, even if not clearly obvious.
Exactly.
Do you understand what you've just said?
Yes, I do. Because I donīt think of myself to be the be all end all of things. Iīm only human and humans canīt see everything because of our limited perception of things. Our eyes are also never perfect, neither could you ever judge solely by what you see.
And I say it again, if you cannot see the worm patterns, then why do we even bother talking about this.
FWIW, when I implemented Error Diffusion in OpenCL, I played with adding some randomness into the picture, even differently from one frame to the next. But I found that if the pattern changes from one frame to the next, the noise level "feels" higher, although it's objectively the same. So I dumbed the algorithm back down to simple and stupid non-random Error Diffusion.
I might be willing to look into re-introducing a little bit of randomness, but I'll probably do that in such a way that it's the same for every frame, so that with static content the pattern stays the same. This might get rid of the worm artifacts without increasing the subjective noise level. However, it's not going to be free, performance wise. None of the computing platforms (OpenCL, DirectCompute) has a random function built in, so I'd have to create a random texture and read from it, which costs memory bandwidth. That said, Error Diffusion is supposed to be the high-quality alternative, so I guess a small increase in rendering times to get rid of the worm artifacts might be worth it, even if most people are not going to be able to see the difference without boosting the contrast.
Sounds great!
James Freeman
5th February 2014, 12:29
Do you guys use debanding for your ripped Blu Rays or is it usefull only for low quality/SD content.
Yes, for internet content (strenghth of debanding depends on size).
No, for full blu-rays (aka. Remux), or straight from disc.
Because the content is naturally dithered.
James Freeman
5th February 2014, 12:35
FWIW, when I implemented Error Diffusion in OpenCL, I played with adding some randomness into the picture, even differently from one frame to the next. But I found that if the pattern changes from one frame to the next, the noise level "feels" higher, although it's objectively the same. So I dumbed the algorithm back down to simple and stupid non-random Error Diffusion.
I might be willing to look into re-introducing a little bit of randomness, but I'll probably do that in such a way that it's the same for every frame, so that with static content the pattern stays the same. This might get rid of the worm artifacts without increasing the subjective noise level. However, it's not going to be free, performance wise. None of the computing platforms (OpenCL, DirectCompute) has a random function built in, so I'd have to create a random texture and read from it, which costs memory bandwidth. That said, Error Diffusion is supposed to be the high-quality alternative, so I guess a small increase in rendering times to get rid of the worm artifacts might be worth it, even if most people are not going to be able to see the difference without boosting the contrast.
IMO, its not worth it.
Nobody super enhances the contrast in actual movie watching.
Nobody can actually see the worm pattern with their naked eye.
Let me remind you that the worm pattern is visible ONLY in flat, static, zoomed, and super contrast enhanced test patterns.
Nevilne
5th February 2014, 12:38
Render times for 720p30>1080p30+SM on 75 hz, HD6870:
no dither: 11.4ms
random dither: 11.7ms
ED direct compute: 19ms
can't test opencl (need to stay on old drivers unrelated to madvr)
Do you understand what you've just said?
Yes, I do. Because I donīt think of myself to be the be all end all of things. Iīm only human and humans canīt see everything because of our limited perception of things. Our eyes are also never perfect, neither could you ever judge solely by what you see.
Don't worry sunrise, he doesn't know what he's talking about.
James Freeman
5th February 2014, 12:49
Don't worry sunrise, he doesn't know what he's talking about.
I take no offense by this third person comment.
Still, the question remains.
Can you actually see the difference with your own eyes?
Why fix something that is outside of your human perception and takes more resources?
Nobody else can see it (worm pattern), nor do they see huge difference between Random and ED.
Why do still insist on adding random noise to ED?
turbojet
5th February 2014, 12:53
Very high contrast and (near) static scenes are not uncommon and if a pattern or 'worm' starts to show people will look for a fix. Give it some time, it took nearly a year for me to spot a pattern in lumasharpen's default pattern and i immediately switched.
zhoufang (http://www.cb.uu.se/~cris/blog/matlabimages/dither_zhoufang.png) from cris' blog looks much better than ed+random fix. It's apparently just as fast too.
iSunrise
5th February 2014, 12:58
zhoufang (http://www.cb.uu.se/~cris/blog/matlabimages/dither_zhoufang.png) from cris' blog looks much better than ed+random fix. It's apparently just as fast too.
Yeah, I also saw that comment. Looks very promising, indeed (if the cost is also lower, why not).
DarkSpace
5th February 2014, 13:03
this is a contrast enhanced and zoomed image of the error diffusion algorithm:
[http://s28.postimg.org/xicvdo4u5/ed_0s.png]
you want to avoid the ugly worm pattern in 18, 20 ,24.
Every bar should look like number 21 via introducing some randomness in the thresholds as suggested by cris luengo (http://www.cb.uu.se/~cris/blog/index.php/archives/355).
And random dithering (http://s23.postimg.org/kg2kjoyob/rd_0s.png) if someone want to compare.
:eek: I see. If it can be done in a way that doesn't increase the noise level, I'm in favor. However, I still fear that there will be too much randomness in the end, and in that case, I'd rather take the current method as a smaller evil.
Also, I'm not so sure about the first two images you linked, I still find the pure Floyd-Steinberg one of those to be better... perhaps that was a less-than-optimal choice of examples? ;)
EDIT: Just saw the 2 comments above this, and it seems I'm just weird and your examples were all right...
JarrettH
5th February 2014, 13:05
Can we use a real world example instead of digits on a black background zoomed in 3200%? :scared:
James Freeman
5th February 2014, 13:10
Can we use a real world example instead of digits on a black background zoomed in 3200%? :scared:
BINGO !!!!
Tell me if you see any worm pattern.
Error Diffusion ON:
http://www.mediafire.com/convkey/86d1/54awu99luiwy3rifg.jpg
ryrynz
5th February 2014, 13:12
You won't get one that you can notice anything on, 'cos that's what it takes for it to stand out.
It's not that it's visible just that static patterns generally aren't desired.
Madshi's working on it, so it should be end of topic now. Did you really need to post that James? :P
iSunrise
5th February 2014, 13:13
Can you actually see the difference with your own eyes?
Why fix something that is outside of your human perception and takes more resources?
Again, very little of madshiīs algorithms (like chroma upscaling differences between Jinc and NNEDI3) can be seen with your human eyes when talking about watching actual movies. However, when zoomed in or enhanced, you will actually see that there are differences. And these differences donīt just magically disappear. They will be there even if you donīt see them. I donīt know why you keep arguing like that.
Why offer lossless audio, when 320kbit/s MP3 or 256kbit/s AAC is clearly better, because you cannot hear any differences. Thatīs the way you currently present your arguments.
You fix something, because it can be improved upon. And we donīt even know the performance hit, yet.
Why canīt you just wait a bit for madshi before making assumptions about things you cannot even know.
mindz
5th February 2014, 13:15
@James Freeman. Isnt alot of the settings in madVR (i.e. difference between Bicubic AR, Lanczos AR and Jinc AR chroma upsampling) about the best quality, and not about what we can see? There have always been images zoomed in 1000x in this thread to show a difference between new algorithms. Otherwise the whole idea of madVR wouldnt be valid and everyone would still be using Bilinear. I think that all the little tweaks (that do cost GPU resources) amount to a better picture in the end, maybe even visible with the naked eye.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.