madVR - high quality video renderer (GPU assisted)

[pie1394]

Originally Posted by madshi

Hmmmm... I've tried all of this on my NVidia 9400 GPU which had problems with black rectangles when using XySubFilter in the past. But no problems here, whatsoever. How can I reproduce these issues? Maybe you can provide me with small samples to test with, in case it has something to do with the samples somehow?

It looks like my HW or OS issue. Somehow P10 no longer works even with 0.86.10 version. Reverting the driver back to 320.49 does not help, either. I guess it is the time to reinstall the OS ... @_@


0.87.1 works fine on my HTPC, with HD7970 + Catalyst 13.12 -- Win7x64SP1. Just noticed the GPU's deinterlacing time is increased around 100%...

[720x480i60]
0.86.10 --> 0.83ms
0.87.1 --> 1.64ms

[1440x1080i60]
0.86.10 --> 1.44ms
0.87.1 --> 4.21ms

Regarding the Image Doubling function on the above 720x480i60 contents to 1920x1080p60 display mode, even HD7970 is not quick enough to handle 60fps. It needs more than 17ms (Debanding_with_AngleDetect + NNEDI3 2x + Jinc3AR) processing time vs 6.2ms (Debanding_with_AngleDetect + Jinc3AR)

[Deim0s]

flashmozzg,

You can download GPU-Z and monitor your GPU RAM usage during playback.

I can do this by using open source ProcessHacker.
If it helps madshi, here are the results:
When starting playback in windowed mode
After switching to full screen mode and get a black screen

[PetitDragon]

Originally Posted by cyberbeing

Conclusion: NVIDIA R331 branch drivers and newer broke madVR display with OpenCL dither. madVR OpenCL NNEDI3 code may have never been functional on recent NVIDIA GPU architectures (Fermi & Kepler?). Remember my earily post where I mentions your version of the OpenCL code for the Avisynth plugin produce a "failed to allocate OpenCL resources error", while SET's original OpenCL code works fine on my GPU.

At the early beginning I was wondering too why new madVR doesn't work, while SEt's plugin just works fine.

[michkrol]

Originally Posted by Soukyuu

Stupid question: how do I create/use profiles? I don't see any configuration options for that in the tray icon settings.

Open settings, left click any settings group (processing/scaling ...), click create profile group. I'm sure you'll work it out from there
When created, the profiles get switched automagically with your auto-select rules or by customizable key shortcuts. Be sure to read the help for auto-select rules scripting.

[PixelH8]

Originally Posted by cyberbeing

NVIDIA GTX 770 + madVR 0.87g

OpenCL Dither
R304 branch = Functional
R310 branch = Functional
R313 branch = Functional
R319 branch = Functional
R325 branch = Functional
R331 branch = Broken
R334 branch = Broken

OpenCL NNEDI3
R304 branch = Broken
R310 branch = Broken
R313 branch = Broken
R319 branch = Broken
R325 branch = Broken
R331 branch = Broken
R334 branch = Broken

R304 branch release tested = 309.00 (10/28/2013)
R310 branch release tested = 310.90 (12/29/2012) & 312.69 (10/28/2013)
R313 branch release tested = 314.22 (03/14/2013)
R319 branch release tested = 321.10 (12/05/2013)
R325 branch release tested = 327.23 (09/12/2013)
R331 branch release tested = 331.40 BETA (09/27/2013) & 332.21 (12/19/2013)
R334 branch release tested = 334.67 (01/15/2014)

Conclusion: NVIDIA R331 branch drivers and newer broke madVR display with OpenCL dither. madVR OpenCL NNEDI3 code may have never been functional on recent NVIDIA GPU architectures (Fermi & Kepler?). Remember my earily post where I mentions your version of the OpenCL code for the Avisynth plugin produce a "failed to allocate OpenCL resources error", while SET's original OpenCL code works fine on my GPU.

^This. My own testing mirrors this exactly.

On my system with the 560 Ti, the last driver to have OpenCL error diffusion working is 327.23.
Every version after this is total FAIL. Something went very wrong indeed. Nothing in the release notes for 331.40 indicate any changes that would adversely affect OpenCL applications but who knows? Maybe whoever compiled the latest drivers forgot to flip the OpenCL switch.

On the plus side, Nvidia does make installing and uninstalling drivers as pain-free as possible, so there's that.

EDIT: I forgot to mention I was using the latest 0.87.1 build of madvr. Also, I'm not 100% sure if this is only a problem that affects Fermi cards and newer so I really have to get my GTS 250 system up and running to find out for sure. I also have a stockpile of drivers going back to 2009, so let the good times roll.

[noee]

Originally Posted by pie1394

Just noticed the GPU's deinterlacing time is increased around 100%...

I notice the same thing using a 1080i video:

.86: Queues all full, no drops, deint=7.3ms
.87.1: Render and present queues struggle ~3-4, 50+ drops after 2 min of playback, deint=18.13ms

HD6570

Edit: Should add, this is a VC1 video using DXVA2 decode

[DragonQ]

Originally Posted by noee

I notice the same thing using a 1080i video:

.86: Queues all full, no drops, deint=7.3ms
.87.1: Render and present queues struggle ~3-4, 50+ drops after 2 min of playback, deint=18.13ms

HD6570

Edit: Should add, this is a VC1 video using DXVA2 decode

Glad it's not just me and not just Intel GPUs!

[Soukyuu]

Originally Posted by michkrol

Open settings, left click any settings group (processing/scaling ...), click create profile group. I'm sure you'll work it out from there
When created, the profiles get switched automagically with your auto-select rules or by customizable key shortcuts. Be sure to read the help for auto-select rules scripting.

Thanks, I saw the "add new device" button, but not the "add profile" on the groups

I was holding off testing debanding until the final version, and man, does it make a difference. Though low seems to be the only non-destructive setting. What does the "don't analyze gradient angles" option affect? I didn't really see any difference

[huhn]

i just checked deint ms too they are high at start but after some time about the same like 86.9.

but while i was testing this is find a new bug introduced in 87.x.
when you change the deinterlacer mode with shift + control + alt + t i get - creating Direct3d Device failed (80070005) picture
one items it even switch to 8 bit color deep.
doesn't matter if film to video or video to film.

edit: works fine when change in the tray options strange but doesn't try to change resolution this way.

I was holding off testing debanding until the final version, and man, does it make a difference. Though low seems to be the only non-destructive setting. What does the "don't analyze gradient angles" option affect? I didn't really see any difference

it checks for parts that need debanding and didn't apply it to the hole image (very short version)

[Thunderbolt8]

OpenCL crashes (bluescreen) on a laptop with radeon 7650 with 13.12 drivers (leshcat drivers v3).

[madshi]

Originally Posted by HolyWu

Error Diffusion works on 327.23, but NNEDI chroma upscaling or doubling doesn't.

Originally Posted by Soukyuu

        dith | doubl | upsc
314.07:  yes |  yes  | yes*
314.22:  yes |  yes  | yes*
320.18:  yes |  yes  | yes*
320.49:  yes |  yes  | yes*
327.23:  yes |  yes  | yes*
331.58:   no | yes** | yes***
331.65:   no | yes** | yes***
331.82:   no | yes** | yes***
332.81:   no | yes** | yes***

  * yellow tint on 10bit h264 only
 ** no green channel (and no luma?) on 10bit h264 only
*** green tint on 10bit h264 only

Examples of yellow, green tints and missing green channel.

327.23 is the first driver officially released for win8.1, so I'm glad it works. Reverting to it until the issue is fixed.
Oh and... openCL dithering makes me drop frames, rendering queue is running out very fast. Same applies to all NNEDI3 features.
I guess my GPU is just too slow.

edit: openCL dithering also makes the ctrl+J osd an opaque black box.

@everyone: don't forget to mention your GPU when you report the results (or just put it in your sig)

Originally Posted by HolyWu

Tested GTX460 with drivers 327.23 and 331.40. Error Diffusion only works on 327.23, does not work on 331.40. NNEDI3 chroma upscaling and doubling don't work at all on both versions.

Originally Posted by cyberbeing

NVIDIA GTX 770 + madVR 0.87g

OpenCL Dither
R304 branch = Functional
R310 branch = Functional
R313 branch = Functional
R319 branch = Functional
R325 branch = Functional
R331 branch = Broken
R334 branch = Broken

OpenCL NNEDI3
R304 branch = Broken
R310 branch = Broken
R313 branch = Broken
R319 branch = Broken
R325 branch = Broken
R331 branch = Broken
R334 branch = Broken

R304 branch release tested = 309.00 (10/28/2013)
R310 branch release tested = 310.90 (12/29/2012) & 312.69 (10/28/2013)
R313 branch release tested = 314.22 (03/14/2013)
R319 branch release tested = 321.10 (12/05/2013)
R325 branch release tested = 327.23 (09/12/2013)
R331 branch release tested = 331.40 BETA (09/27/2013) & 332.21 (12/19/2013)
R334 branch release tested = 334.67 (01/15/2014)

Conclusion: NVIDIA R331 branch drivers and newer broke madVR display with OpenCL dither.

Originally Posted by PixelH8

^This. My own testing mirrors this exactly.

On my system with the 560 Ti, the last driver to have OpenCL error diffusion working is 327.23.
Every version after this is total FAIL. Something went very wrong indeed. Nothing in the release notes for 331.40 indicate any changes that would adversely affect OpenCL applications but who knows? Maybe whoever compiled the latest drivers forgot to flip the OpenCL switch.

On the plus side, Nvidia does make installing and uninstalling drivers as pain-free as possible, so there's that.

EDIT: I forgot to mention I was using the latest 0.87.1 build of madvr. Also, I'm not 100% sure if this is only a problem that affects Fermi cards and newer so I really have to get my GTS 250 system up and running to find out for sure. I also have a stockpile of drivers going back to 2009, so let the good times roll.

Thanks for doing all those testing, guys! It's interesting to see that some features work with some drivers and some GPUs. I "like" especially Soukyuu's results where NNEDI3 produces different color artifacts depending on source color space and driver version. That pretty much shows how unreliable NVidia OpenCL is. It doesn't even go from working to non-working, but seemingly the color channels are interpreted differently depending on driver version. That's a nightmare!

Originally Posted by Soukyuu

What does the "don't analyze gradient angles" option affect? I didn't really see any difference

Enabling it makes debanding stronger for image areas which are likely large gradiants, while keeping debanding strength the same for areas which probably contain image detail. Basically it should improve debanding strength where it's needed without losing a lot of additional detail in other image areas. It costs quite a bit of added GPU performance, though.

Originally Posted by pie1394

Regarding the Image Doubling function on the above 720x480i60 contents to 1920x1080p60 display mode, even HD7970 is not quick enough to handle 60fps. It needs more than 17ms (Debanding_with_AngleDetect + NNEDI3 2x + Jinc3AR) processing time vs 6.2ms (Debanding_with_AngleDetect + Jinc3AR)

Image Doubling doesn't have just one settings. How many neurons did you use? And did you tell madVR to double chroma resolution, too? Furthermore: If you do use image doubling, I'd recommend to use a cheaper follow-up algorithm for "image upscaling". E.g. use Bicubic50AR instead of Jinc3AR.

Originally Posted by DragonQ

Improved over 0.87. Hard to say whether it's really usable without the 10-bit chrome & image buffers. Certainly not better than 0.86.11. Average stats:

0.87.1 Software:
Deinterlace: 18.65 ms
Split: 18.85 ms
Rendering: 8.64 ms
Present: 0.42 ms
Dropped Frames: 63
Delayed Frames: 2

0.86.11 Software:
Deinterlace: 8.29 ms
Split: 9.15 ms
Rendering: 4.70 ms
Present: 0.17 ms
Dropped Frames: 14
Delayed Frames: 0

0.87.1 DXVA2 Native:
Deinterlace: 13.96 ms
Split: 16.53 ms
Rendering: 8.38 ms
Present: 0.41 ms
Dropped Frames: 4
Delayed Frames: 1

0.86.11 DXVA2 Native:
Deinterlace: 7.58 ms
Split: 8.08 ms
Rendering: 5.02 ms
Present: 0.16 ms
Dropped Frames: 8
Delayed Frames: 0

Using: HD4000, MPC-HC, LAV Filters, Smooth Motion, Bicubic75 Chroma upscaling, Catmull-Rom downscaling, playing 1080i/25 @ slightly under 1080p.

Originally Posted by pie1394

0.87.1 works fine on my HTPC, with HD7970 + Catalyst 13.12 -- Win7x64SP1. Just noticed the GPU's deinterlacing time is increased around 100%...

[720x480i60]
0.86.10 --> 0.83ms
0.87.1 --> 1.64ms

[1440x1080i60]
0.86.10 --> 1.44ms
0.87.1 --> 4.21ms

Originally Posted by noee

I notice the same thing using a 1080i video:

.86: Queues all full, no drops, deint=7.3ms
.87.1: Render and present queues struggle ~3-4, 50+ drops after 2 min of playback, deint=18.13ms

HD6570

Edit: Should add, this is a VC1 video using DXVA2 decode

Ok.

-------

So for all users who have:

(1) Stability problems (D3D9 error messages, freezing when switching video files in FSE mode etc).
(2) Performance issues with deinterlacing.

Please try the various test builds you can find here:

http://madshi.net/madVRtestbuilds.rar

Every test build reverts one change back to v0.86.11. This way hopefully we can identify which change is reponsible for which problem.

[cyberbeing]

Originally Posted by madshi

That pretty much shows how unreliable NVidia OpenCL is. It doesn't even go from working to non-working, but seemingly the color channels are interpreted differently depending on driver version. That's a nightmare!

This is NVIDIA's way of telling you to use CUDA, instead of depending on their automated OpenCL to CUDA driver translation functioning properly. As a bonus, you can actually debug and profile CUDA kernels on NVIDIA as well, while no such thing exists for OpenCL on NVIDIA.

[nevcairiel]

Originally Posted by madshi

Thanks for doing all those testing, guys! It's interesting to see that some features work with some drivers and some GPUs. I "like" especially Soukyuu's results where NNEDI3 produces different color artifacts depending on source color space and driver version. That pretty much shows how unreliable NVidia OpenCL is. It doesn't even go from working to non-working, but seemingly the color channels are interpreted differently depending on driver version. That's a nightmare!

Should've gone with CUDA, the API is much easier to use, too!
More importantly, I don't think NVIDIA (or quite possibly any other GPU vendor) cares much about such (tiny) compute use-cases.

[iSunrise]

0.87.1 is working great here (speed-wise it seems at least on par with 0.86.11, if not faster, haven´t tested with de-interlacing yet, though).

I found one bug though, which is reproducible every time:

1) enable smooth motion - enable always
2) play a video file
3) enter fullscreen-exclusive
4) leave fullscreen-exclusive and return to windowed mode
-> black screen
5) going back to fullscreen-exclusive the picture is back
6) leave fullscreen-exclusive again
-> black screen
...

GTX580, 331.82 drivers (quadro)

@madshi:
I don´t know if this is helpful for you, but on the 3dcenter-forum there is a member called Blaire, which seems to be part of the NV BETA Testing-Program and he seems to know a lot of various related (known) issues and he reports directly to them (driver related problems, primarily he reports game issues). He seems to be always up-to-date when it comes to new drivers, too. It seems that when he is reporting bugs directly, they have a very high chance to get fixed ASAP. That´s only an observation on my part though, I didn´t actually every have a conversation with him, since I never had serious problems, thankfully.

Also, if you tell him that a lot of the madVR users are going to consider switching to AMD in the future, because of the lackluster OpenCL drivers, NV may listen a bit more closely. Seems worth a try, at least. Not your problem if they cannot provide stable drivers for such things, anyway.

[cca]

CUDA though works exclusively and only on Nvidia, it's a proprietary interface. OpenCL isn't. Nvidia's attitude is forcing developers to support their own interface so they have to do double the work.

Sent from my Nexus 7 using Tapatalk

[noee]

Some more feedback....OpenCL...HD6570

I've been testing SD video (and interlaced) and film, upscaling to 1080, with the NNEDI Double Luma, 64neurons. I can't use secondary scaling options that use pixel shaders, but DXVA2 scaling works great in this case. I can still see some ringing around hair and people's heads, but it seems to be working very well, using about 25-30% less GPU than Jinc3/AR with SD film.

Edit: % perf numbers

[huhn]

So for all users who have:

(1) Stability problems (D3D9 error messages, freezing when switching video files in FSE mode etc).
(2) Performance issues with deinterlacing.

Please try the various test builds you can find here:

http://madshi.net/madVRtestbuilds.rar

Every test build reverts one change back to v0.86.11. This way hopefully we can identify which change is reponsible for which problem.

so all 6 didn't work all got the same error with switching video mode to film mode and all freeze/crash with fullscreen exclusive switching file.

BUT! after that 86.9 didn't work too at least the film video mode switching the error is different the player is completely crashing (bug report sending didn't work yet again) to fix this i have to reset all settings.

so i try all 6 again but this time i reset them all each time... and type the display modes in each time X-)

maybe just an problem with an registry entry?

[Soukyuu]

Originally Posted by madshi

Enabling it makes debanding stronger for image areas which are likely large gradiants, while keeping debanding strength the same for areas which probably contain image detail. Basically it should improve debanding strength where it's needed without losing a lot of additional detail in other image areas. It costs quite a bit of added GPU performance, though.

Hmm, so setting deband to say, "low", that option will increase it to "high" where needed?

As for nVidia's openCL, I guess I just have to be happy other openCL seems to function properly, i.e. flaccl still being lossless. But that kind of scares me to be honest. Maybe I'll go with AMD for my next GPU this iteration...

[madshi]

Originally Posted by cyberbeing

This is NVIDIA's way of telling you to use CUDA, instead of depending on their automated OpenCL to CUDA driver translation functioning properly. As a bonus, you can actually debug and profile CUDA kernels on NVIDIA as well, while no such thing exists for OpenCL on NVIDIA.

Originally Posted by nevcairiel

Should've gone with CUDA, the API is much easier to use, too!
More importantly, I don't think NVIDIA (or quite possibly any other GPU vendor) cares much about such compute use-cases.

That's all nice and fine. But think about the future, too. What if I add a dozen new features relying on computing? Am I really expected to create, debug and profile two versions of every kernel? It might not be twice the work, but it would definitely be a lot extra work. I'd really *REALLY* prefer to stick with one API. I'm considering to maybe at some point adding a full OpenCL rendering queue, dropping D3D9 rendering completely (just for GPUs which support it, of course). That would mean there would be several dozens of pixel shaders that need to be converted to OpenCL. Converting them all to OpenCL *and* CUDA would increase my workload quite a lot. So much that I might actually forget about the whole idea.

Originally Posted by iSunrise

0.87.1 is working great here (speed-wise it seems at least on par with 0.86.11, if not faster, haven´t tested with de-interlacing yet, though).

I found one bug though, which is reproducible every time:

1) enable smooth motion - enable always
2) play a video file
3) enter fullscreen-exclusive
4) leave fullscreen-exclusive and return to windowed mode
-> black screen
5) going back to fullscreen-exclusive the picture is back
6) leave fullscreen-exclusive again
-> black screen
...

GTX580, 331.82 drivers (quadro)

Everybody please, if you find a bug, always double check with v0.86.11 for now. I need to know which bugs are new bugs and which already existed in v0.86.11. I'm mostly only interested in fixing new bugs for now.

@iSunrise, if this issue did not occur in v0.86.11 (please double check), could you please also check the test builds I posted a couple posts above to see if any one of them fixes this problem or not? Thanks.

Originally Posted by noee

Some more feedback....OpenCL...HD6570

I've been testing SD video (and interlaced) and film, upscaling to 1080, with the NNEDI Double Luma, 64neurons. I can't use secondary scaling options that use pixel shaders, but DXVA2 scaling works great in this case. I can still see some ringing around hair and people's heads, but it seems to be working very well, using about 12-15% less GPU than Jinc3/AR.

Unfortunately if you activate DXVA2 scaling, NNEDI3 is not used at all. Sorry, should have said so. But it would be technically quite difficult to combine NNEDI3 and DXVA2 scaling. Try NNEDI3 for Luma only + Bilinear.

[noee]

haha! Yes, that explains a lot.....

Okay, I see, yeah. I can only run 32 neurons with Bilinear without drops, but it works, GPU is >80%.