madVR - high quality video renderer (GPU assisted)

[madshi]

Sorry.

http://madshi.net/madVRdirectCompute3.rar

[James Freeman]

Here is the perfect example:
http://www.mediafire.com/convkey/2251/ol84x98d9rtwbbgfg.jpg

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

Shiandow, thanks for the picture and explanation.

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]

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]

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]

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]

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: http://thumbnails110.imagebam.com/30589/9e1158305880023.jpg (http://www.imagebam.com/image/9e1158305880023)

and with the new build, queues fill up instantly: http://thumbnails111.imagebam.com/30589/a55412305880024.jpg (http://www.imagebam.com/image/a55412305880024)

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

[DragonQ]

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!

[cyberbeing]

That's a smaller performance increase as most other NVidia users seem to report. That's a bit strange.

Which results are you looking at? The following where the only NVIDIA users reporting render times differences with OpenCL vs DirectCompute build 1:

Asmodian's Titan = 1.3ms improvement
Ver's GTX 580 = 1ms & 2ms improvement
Kalanoch's GTX 670 = 3ms & 5ms improvement
Myself GTX 770 = 3ms improvement

Average: 2.55ms improvement for NVIDIA users with DirectCompute build 1.

[iSunrise]

Wow!

OpenCL vs. DirectCompute1 vs. DirectCompute3

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)http://abload.de/thumb/errordiffusion_directx0xm1.png (http://abload.de/image.php?img=errordiffusion_directx0xm1.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)http://abload.de/thumb/errordiffusion_directg1b6h.png (http://abload.de/image.php?img=errordiffusion_directg1b6h.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)http://abload.de/thumb/errordiffusion_directxxzv9.png (http://abload.de/image.php?img=errordiffusion_directxxzv9.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)http://abload.de/thumb/errordiffusion_direct3glsb.png (http://abload.de/image.php?img=errordiffusion_direct3glsb.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)http://abload.de/thumb/errordiffusion_directvwz9z.png (http://abload.de/image.php?img=errordiffusion_directvwz9z.png)

Compared to DirectCompute1, there´s (depends on your settings, smooth motion and source->target resolution) lower VRAM usage, lower GPU load and lower memory controller load across the board.

Especially compared to OpenCL, this is a HUGE improvement now.

OpenCL vs. DirectCompute3
On the 50fps clip I posted above, it´s lower than half of the memory used (427MB vs. 191MB), about 12% lower GPU load (35% vs. 23%) and only half the memory controller load (15% vs. 8%).

Great work madshi!

[*Touche*]

Which results are you looking at? The following where the only NVIDIA users reporting render times differences with OpenCL vs DirectCompute build 1:

Asmodian's Titan = 1.3ms improvement
Ver's GTX 580 = 1ms & 2ms improvement
Kalanoch's GTX 670 = 3ms & 5ms improvement
Myself GTX 770 = 3ms improvement

Average: 2.55ms improvement for NVIDIA users with DirectCompute build 1.

I think it would be better to look at the percentages. One man's 50% is 3 ms, other one's is 30 ms.

[pie1394]

Sorry.

http://madshi.net/madVRdirectCompute3.rar

Did a quick test of DC version build of Error Diffusion on the HD7970.

- 1920x1080p24 H.264 Hi10 contents to 1080p24 output mode.
- NNEDI3 32 for Chroma 2x upscaling
- Debanding with angle detection

No dithering with 0.87.4: 15.2 ~ 15.3 ms
No dithering with DC3 : 15.1 ~ 15.2 ms
Random dithering with DC3: 15.2 ~ 15.3ms
ED with 0.87.4 OpenCL: 26ms (39ms**)
ED with DC1: 17.2ms
ED with DC3: 17.0ms


** This is the timing number when the GPU-z runs at the background, the playback is also unstable. So I recommend those people who have measured strange timing numbers should be careful about this.

[Ver Greeneyes]

Ver's GTX 580 = 1ms & 2ms improvement
I think it would be better to look at the percentages.
Indeed - using random dithering as a baseline, DirectCompute from the first test build seemed 57-59% faster than OpenCL:
(7.80 - 5.26) / (6.88 - 5.26) - 1 = 56.8%
(13.80 - 8.54) / (11.84 - 8.54) - 1 = 59.4%I haven't compared the new build, but it should be the same or better :) (completely disabling dithering would also give a better baseline, but I think this is good enough)

[madshi]

Some great results, I'm pretty happy with DirectCompute atm! Will go work on NNEDI3 now...

[*Touche*]

Some great results, I'm pretty happy with DirectCompute atm! Will go work on NNEDI3 now...

If you manage similar improvements, my A10-5800K will be able to pull some impressive settings. NNEDI is the only thing it isn't able to do atm. Great work and thank you so much for madVR!

[cyberbeing]

Did a quick test, and there is a small performance improvement with DirectCompute Build 3, and GPU ram usage is back down to madVR 0.87.4 levels.

GTX 770 2GB
VS. Random Dither

1920x1080p60 -> 2560x1440@60hz FSE
OpenCL Dither = +10.7ms ~1GB
DirectCompute Build 1 = +8.7ms ~1.4GB
DirectCompute Build 3 = +8.0ms ~1GB

1280x720p24 -> 1920x1080@60hz FSE w/ Smooth Motion
OpenCL Dither = +11.8ms ~1GB
DirectCompute Build 1 = +8.7ms ~1.3GB
DirectCompute Build 3 = +8.0ms ~1GB

640x360p24 -> 2560x1440@60hz FSE w/ Smooth Motion
OpenCL Dither = +20.8ms ~1.8GB
DirectCompute Build 1 = +18.5ms (w/ queues reduced from 16 to 8)
DirectCompute Build 3 = +16.2ms ~1.8GB

1920x1080p24 -> 1920x1080@120hz FSE
OpenCL Dither = +6.1ms
DirectCompute Build 1 = +4.4ms
DirectCompute Build 3 = +4.0ms

1280x720p24 -> 1920x1080@120hz FSE
OpenCL Dither = +5.8ms
DirectCompute Build 1 = +4.2ms
DirectCompute Build 3 = +3.7ms

1280x720p24 -> 1280x720@120hz FSE
OpenCL Dither = +2.5ms
DirectCompute Build 1 = +1.7ms
DirectCompute Build 3 = +1.5ms

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



Trying the test build 3, all the problems was gone, playback without any dropped frames, perfectly.
In addition, the rendering time was slightly lower compared to the test build 1.That's awesome!
Thank you for the work on new build!

[kasper93]

Some great results, I'm pretty happy with DirectCompute atm! Will go work on NNEDI3 now...

Yeah, it depends on architecture, but on my gpu it's ~10x faster ;p I knew that my HD5870 can do better and it's bottlenecking somewhere... This gpu is not quite new, but it's still powerful. I'm very exited to see how NNEDI3 will work. Good luck :)

[trip_let]

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.

Quoting self, still a bit busy; took 1 min to test. Same scenario on HD 4000.

Dithering: 3 ms
Error diffusion OpenCL: 30 ms
Error diffusion DirectCompute v1: 33 ms
Error diffusion DirectCompute v3: 26 ms

edit: off the top of my head, on 1080p24 playback on 1080p (60 fps smooth motion), on Optimus using GT 650M, dynamic memory usage was 1050MB with DirectCompute v1 error diffusion, now down to 850MB on v3. Nice improvement all around.

[DragonQ]

I was hoping that I could use MadVR on my Arrandale IGP with the new profiles but apparently not. The problem is that MadVR cannot use DXVA deinterlacing or scaling on this GPU ("DXVA processing failed"), so I have no way of deinterlacing except using YADIF in LAV Video Decoder. However, I can't get MadVR to recognise this formerly-interlaced material. If (srcInterlaced = true) doesn't work, presumably because the video isn't interlaced any more once MadVR gets hold of it. If (deintFps > 31) doesn't work because MadVR reports the fps as 25 rather than 50.

Is there any way to get this to work?

[Thunderbolt8]

not sure what to compare DirectCompute rendering times to since OpenCL didnt work for me. v3 rendering times are about the same as v1 which means still too slow in case of 1080p60 with dropping frames.

[James Freeman]

1080p60 with DirectComputeV3 works perfectly here. V1 worked just as good but used more memory.
With DirectComputeV3 I can actually leave Error Diffusion On permanently with any type of video and setting.
Even 4Kp60 woks flawlessly.


Bug Report:

Downscaling with DXVA freezes image when changing windows size or going fullscreen.

[Soukyuu]

madshi, what's the reason you restricted DirectCompute to newer GPUs? Do 2xx and 4xx nVidia chips lack hardware capabilities or was it for performance reasons?
*continues to silently envy everyone with a newer GPU*

[omarank]

*continues to silently envy everyone with a newer GPU*

Me too... :(

[Asmodian]

I think it would be better to look at the percentages. One man's 50% is 3 ms, other one's is 30 ms.

Percentages mean nothing in this context, I was running NNEDI3 32 chroma upscaling, NNEDI3 64 luma doubling, and smooth motion.

The fact that I was at 36ms per frame and only got 3.6% improvement doesn't mean I had less improvement than cyberbeing's (http://forum.doom9.org/showthread.php?p=1666058#post1666058) 26.3% on 11.8 ms. The ms cost is what matters, add up the time for all the options you want and hope it is under the time per frame.

I did get less improvement but not one seventh of the improvement, one half.

[Qotscha]

I think the performance of error diffusion is quite poor on my computer (Radeon HD 6850 with Catalyst 13.12). Here is a little comparison:

720p50 to 1080p50:

Jinc 4 + AR (Image + chroma), medium deband, random dithering: 91% GPU load, no dropped frames
Bilinear (Image + chroma), no deband, error diffusion: ~90% GPU load, a lot of dropped frames (result is about the same with any scaling algorithm)


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

[sexus]

ok so from what ive understood the only difference between directcompute error diffusion and opencl error diffusion is the support for nv12 dxva surfaces , but shouldnt this be irrelevant to the cuvid users ?

its funny how i come around every so often and have the perfect timing on new exciting developments,lols

[madshi]

If you manage similar improvements, my A10-5800K will be able to pull some impressive settings. NNEDI is the only thing it isn't able to do atm.
Don't expect too much from NNEDI/DirectCompute. I'm not even sure yet if it will be faster at all. I hope so, but I don't know...

Did a quick test, and there is a small performance improvement with DirectCompute Build 3, and GPU ram usage is back down to madVR 0.87.4 levels.

GTX 770 2GB
VS. Random Dither

1920x1080p60 -> 2560x1440@60hz FSE
OpenCL Dither = +10.7ms ~1GB
DirectCompute Build 1 = +8.7ms ~1.4GB
DirectCompute Build 3 = +8.0ms ~1GB

1280x720p24 -> 1920x1080@60hz FSE w/ Smooth Motion
OpenCL Dither = +11.8ms ~1GB
DirectCompute Build 1 = +8.7ms ~1.3GB
DirectCompute Build 3 = +8.0ms ~1GB

640x360p24 -> 2560x1440@60hz FSE w/ Smooth Motion
OpenCL Dither = +20.8ms ~1.8GB
DirectCompute Build 1 = +18.5ms (w/ queues reduced from 16 to 8)
DirectCompute Build 3 = +16.2ms ~1.8GB

1920x1080p24 -> 1920x1080@120hz FSE
OpenCL Dither = +6.1ms
DirectCompute Build 1 = +4.4ms
DirectCompute Build 3 = +4.0ms

1280x720p24 -> 1920x1080@120hz FSE
OpenCL Dither = +5.8ms
DirectCompute Build 1 = +4.2ms
DirectCompute Build 3 = +3.7ms

1280x720p24 -> 1280x720@120hz FSE
OpenCL Dither = +2.5ms
DirectCompute Build 1 = +1.7ms
DirectCompute Build 3 = +1.5ms
The cost should depend on the output resolution, nothing else. Looking at your results that seems to be mostly true. Error Diffusion for 2560x1440 costs about 8ms with your GPU. 1080p costs about 4ms. 720p 1.5ms. The only result not fitting in here is the Smooth Motion FRC result. But that can be easily explained: SM FRC increases the output framerate, but calculates the overall rendering cost per *source* frame. So with 24fps @ 60Hz, SM FRC outputs something like 48fps, and has to apply Error Diffusion to every of those output frames - while the scaling etc algorithms are only applied on the source frames. So that means e.g. Jinc3AR is only done 24 times per second. But Error Diffusion is done smoething like 48 times per second. So the cost of Error Diffusion appears to be twice as high with SM FRC turned on. If you had a true 48fps video with SM FRC turned off, the Error Diffusion cost would seem only half as much (per source frame), although in reality it's really the same. Makes sense?

Trying the test build 3, all the problems was gone, playback without any dropped frames, perfectly.
In addition, the rendering time was slightly lower compared to the test build 1.
Great!

Yeah, it depends on architecture, but on my gpu it's ~10x faster ;p
Yeah, that was the main thing bothering me: The OpenCL interop cost was so high - and it was not scaling with GPU power! So a cheap budget GPU had the same interop cost as the fastest GPU available. This problem is gone now, so finally Error Diffusion should scale nicely with the GPU power.

HD 4000.

Dithering: 3 ms
Error diffusion OpenCL: 30 ms
Error diffusion DirectCompute v1: 33 ms
Error diffusion DirectCompute v3: 26 ms
Cool. So Error Diffusion with DirectCompute seems to be faster now with all 3 GPU manufacturers. No reason to use OpenCL for Error Diffusion, anymore. Yey!

I was hoping that I could use MadVR on my Arrandale IGP with the new profiles but apparently not. The problem is that MadVR cannot use DXVA deinterlacing or scaling on this GPU ("DXVA processing failed"), so I have no way of deinterlacing except using YADIF in LAV Video Decoder. However, I can't get MadVR to recognise this formerly-interlaced material. If (srcInterlaced = true) doesn't work, presumably because the video isn't interlaced any more once MadVR gets hold of it. If (deintFps > 31) doesn't work because MadVR reports the fps as 25 rather than 50.

Is there any way to get this to work?
Why do you need it to be recognised as being formerly interlaced? After YADIF it should truely be progressive. Although normally video mode deinterlacing produces double frame rate. But I guess that depends on your LAV settings?

not sure what to compare DirectCompute rendering times to since OpenCL didnt work for me. v3 rendering times are about the same as v1 which means still too slow in case of 1080p60 with dropping frames.
Is that with your 760M or with your HD4600? I think it's probably the HD4600? The 760M should be able to 1080p60 with Error Diffusion, I think. Of course it depends on your other settings. Error Diffusion *does* cost additional performance, so if you want to use it you may have to dial down some of the other settings.

1080p60 with DirectComputeV3 works perfectly here. V1 worked just as good but used more memory.

With DirectComputeV3 I can actually leave Error Diffusion On permanently with any type of video and setting.

Even 4Kp60 woks flawlessly.
4Kp60? Great!

madshi, what's the reason you restricted DirectCompute to newer GPUs? Do 2xx and 4xx nVidia chips lack hardware capabilities or was it for performance reasons?
*continues to silently envy everyone with a newer GPU*
NVidia 4xx should work. NVidia 2xx does not and AMD 4xxx does not. 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.

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

Looks good! Not being able to use Jinc4AR is not a big loss, IMHO.

ok so from what ive understood the only difference between directcompute error diffusion and opencl error diffusion is the support for nv12 dxva surfaces
No. The lack of nv12 DXVA surface support has nothing to do with Error Diffusion. There is no downside to using DirectCompute for Error Diffusion. The only "problem" is that I can't use DirectCompute for one other feature where I'd like to use it. But I can use it just fine for Error Diffusion, and probably also for NNEDI3.

[Mangix]

madshi, what's the reason you restricted DirectCompute to newer GPUs? Do 2xx and 4xx nVidia chips lack hardware capabilities or was it for performance reasons?
*continues to silently envy everyone with a newer GPU*

Needs to be a DX11 capable GPU, so yes. Hardware reasons.

edit: was not fast enough.

[DragonQ]

Why do you need it to be recognised as being formerly interlaced? After YADIF it should truely be progressive. Although normally video mode deinterlacing produces double frame rate. But I guess that depends on your LAV settings?
Because the Arrandale IGP is a pile of crap and can only handle anything above Bilinear for <30 fps videos. I wanted to create profiles so I could set this up, but can't see a way of MadVR recognising that the videos are 50 fps when YADIF is used, even though they clearly are.

It doesn't necessarily need to notice that the video used to be interlaced, just that it's now 50 fps rather than 25 fps.

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

which settings do i have to change exactly? and to what test values do i change them you think?

[huhn]

i know madshi is not really interested in new bugs but it's a pretty huge one

huge resize "error"

when i use a 1440x1080i60 (ar 16/9) source and resize it to 1724x950 image quality gets really bad (like point or even worse...) if upscale is bilinear and downscaling is "mitchell-netravali" - "spline" (all pixelshader resizer) blinear up and down is fine even bilinear up and nearest neighbor down is way better or even the same like bilinear down?

screen: bilinear/bilinear fine (http://abload.de/img/resizeerrorbilbilptb76.png) bilinear/catmull-rom pure quality (http://abload.de/img/resizeerrorbilcatytlhh.png)

[NicolasRobidoux]

Here is an example of why I thought Jinc4 (and, actually, I believe I prefer Jinc 5) would work better than Jin3 for pixel art: http://forum.doom9.org/showthread.php?p=1595556#post1595556

[madshi]

Because the Arrandale IGP is a pile of crap and can only handle anything above Bilinear for <30 fps videos. I wanted to create profiles so I could set this up, but can't see a way of MadVR recognising that the videos are 50 fps when YADIF is used, even though they clearly are.

It doesn't necessarily need to notice that the video used to be interlaced, just that it's now 50 fps rather than 25 fps.
I think you need to talk to nevcairiel. According to what you're saying it doesn't seem to report 50fps to madVR. I think it should do that if it doubles the framerate with YADIF.

i know madshi is not really interested in new bugs but it's a pretty huge one

huge resize "error"

when i use a 1440x1080i60 (ar 16/9) source and resize it to 1724x950 image quality gets really bad (like point or even worse...) if upscale is bilinear and downscaling is "mitchell-netravali" - "spline" (all pixelshader resizer) blinear up and down is fine even bilinear up and nearest neighbor down is way better or even the same like bilinear down?

screen: bilinear/bilinear fine (http://abload.de/img/resizeerrorbilbilptb76.png) bilinear/catmull-rom pure quality (http://abload.de/img/resizeerrorbilcatytlhh.png)
Can I have a small sample of this, please?

Here is an example of why I thought Jinc4 (and, actually, I believe I prefer Jinc 5) would work better than Jin3 for pixel art: http://forum.doom9.org/showthread.php?p=1595556#post1595556
Yes. Jinc3AR or Jinc4AR (not much difference, I think) are both quite fine for pixel art - quite a bit better than Lanczos. But NNEDI3 really is in another league for heavily aliased pixel art. I was surprised myself how big the difference was.

[michkrol]

which settings do i have to change exactly? and to what test values do i change them you think?

Rendering -> general settings -> CPU/GPU queue size. Not sure what you have them at right now, so I can't tell you exact values, you can even lower them to minimum. Also it's just a wild guess that you might be running out of memory, based on your mention of 4K screen.
Checking playback with another player (or player's version) should probably come first.

[Thunderbolt8]

Is that with your 760M or with your HD4600? I think it's probably the HD4600? The 760M should be able to 1080p60 with Error Diffusion, I think. Of course it depends on your other settings. Error Diffusion *does* cost additional performance, so if you want to use it you may have to dial down some of the other settings.the 760M, its always the non integrated card unless I say so. unfortunately with 60p its a little too slow for the 760M as it seems :(

which other settings are there I could dial down in order to have the slightly better PQ with error difusion all in all? Im not using anything like deinterlacing, smooth motion or deband for that test file, so I could only dial down settings in the trade quality for performance tab and there I wouldnt know which would be the better tradeoff PQ-wise.

[DragonQ]

Just got around to trying DirectCompute v3 on my desktop (GTS 250). Ticking/unticking "use random dithering instead of OpenCL error diffusion" does nothing to visuals, rendering times, or GPU usage. :scared:

[nevcairiel]

Just got around to trying DirectCompute v3 on my desktop (GTS 250). Ticking/unticking "use random dithering instead of OpenCL error diffusion" does nothing to visuals, rendering times, or GPU usage. :scared:

DirectCompute requires a DX11 compatible GPU, which the 200 series is not.

[DragonQ]

Oh yeah I was meant to try on my HD4000. I'm retarded ignore me.

[The 8472]

Even 4Kp60 woks flawlessly. Do you have a 4k screen? Otherwise the source resolution does not matter as far as dithering goes, output resolution does. Source resolution/framerate matters for the scalers and nnedi.

1440p60 output (i.e. 1440p screen + smooth motion on) eats about 40% GPU load for me, NNEDI another 45% at 720p24->1440p24 so it's pretty close. Downscaling from 4k would actually be cheaper since it wouldn't use nnedi but simply one of the downscaling algorithms.

Just got around to trying DirectCompute v3 on my desktop (GTS 250). Ticking/unticking "use random dithering instead of OpenCL error diffusion" does nothing to visuals, rendering times, or GPU usage. :scared:

It would probably be good if madVR complained loudly if you're using settings that don't actually work. Silent failures might lead to users misinterpreting things.

[XMonarchY]

So error diffusion dithering is now done through DirectCompute in these test builds, but NNEDI3 is still using using OpenCL, right?

[DragonQ]

So error diffusion dithering is now done through DirectCompute in these test builds, but NNEDI3 is still using using OpenCL, right?
Correct.

[Mangix]

It would probably be good if madVR complained loudly if you're using settings that don't actually work. Silent failures might lead to users misinterpreting things.
This is currently the case with windowed overlay mode. Complaining happens when the OSD is enabled. Not hard to implement.

[Thunderbolt8]

might have missed something, but on my other laptop with a Radeon HD 76X0M I get a black picture when choosing OpenCL/DirectCompute with testversion 3 (CCC 13.12). whys that?

[cyberbeing]

The cost should depend on the output resolution, nothing else.
Yes, I already mentioned last week that performance cost scaled with output resolution only, and doubled on my GPU with Smooth Motion. I decided to show such results with numbers this time, so you'd get a bit better perspective how performance was scaling on my GPU. It's still the second slowest function in madVR behind NNEDI3 on this GPU, and cannot be enabled full-time without reduced quality settings in many cases.

I'm remaining hopeful that DirectCompute NNEDI3 vs OpenCL NNEDI3 will reduce absolute render times enough to leave room for DirectCompute Dither.

[Soukyuu]

Oh yeah I was meant to try on my HD4000. I'm retarded ignore me.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.

It would probably be good if madVR complained loudly if you're using settings that don't actually work. Silent failures might lead to users misinterpreting things.I'm all for visible error messages, but not popups you have to close. Maybe displaying a message on the OSD along the lines of "DirectCompute not supported - falling back to random dither"

[Audionut]

I'm all for visible error messages, but not popups you have to close. Maybe displaying a message on the OSD along the lines of "DirectCompute not supported - falling back to random dither"

Agreed. For anything that otherwise silently fails.

Just having more information in the debug OSD sounds fine also.

[cyberbeing]

DirectCompute requires a DX11 compatible GPU, which the 200 series is not.

Do the limitations of DirectCompute Compute Shader 4.0/4.1 for DX10 & 10.1 make it relatively useless compared to Compute Shader 5.0 for DX11?