madVR - high quality video renderer (GPU assisted)

[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 (https://dl.dropboxusercontent.com/u/19330332/nnedi3_upscale_yellow.jpg), green tints (https://dl.dropboxusercontent.com/u/19330332/nnedi3_upscale_green.jpg) and missing green channel (https://dl.dropboxusercontent.com/u/19330332/nnedi3_doubling_br.jpg).

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)

[djfred93]

MadVR don't load with the latest version, it is stuck at opening the file and it crash on the setting window. The debug work fine but the debug don't have the enable/disable OpenCL processing of DXVA NV12 option. The deinterlacing have framedrop but it's better than the other 0.87 version of MadVR. The deinterlacing worked fine (no framedrops) with the latest deband test and stable version. Thanks anyway for the latest version.

My system : Intel Core i7@920, Ati Radeon HD 5770, Windows 8.1, MPC-HC 1.7.1

Work well with the latest version. Except for deinterlacing, where I have framedrops with jinc3 AR/jinc3 AR but I think it's my graphics card is not powerful enough.

[DarkSpace]

I don't think so. I've written a custom pixel shader script for the shifting which is performance optimized for just this purpose. If I offered other algorithms, that would mean a lot extra work, and to be honest, I don't think it's important enough. When shifting, the algorithm is not too important. I don't think e.g. Jinc3AR would look any better even with test patterns for simple 0.5 pixel shifting.
No worries, I myself even mentioned that it's probably unimportant. I'm just very curious in general.

[Budtz]

I was using ffdshow de-banding before 0.87

I have enabled reduce banding artifacts. Is this the same as ffdshows debanding and should i disable that?

what de-banding settings are best for blurays?

thx

[michkrol]

"//" comments should be supported. Not tested it, though. I'm strictly opposed to using "/*" or "{" comments for documentation in C++, because doing so means you can't comment out large portions of source code. "//" comments don't come with this problem, so I added support only for "//".
Works great. One line comments should be enough in scripts, just to know what any given rule matches, without much thinking. Thanks again for the release.

[James Freeman]

It seems like it:
Force Film -> Works
Force Video -> Broken
Deinterlacing Off -> Works

0.86.11 in all of the cases above -> Works

Deinterlacing working perfectly in every mode over here (87.1 official).

332.21 Nvidia Drivers.

[djfred93]

I was using ffdshow de-banding before 0.87

I have enabled reduce banding artifacts. Is this the same as ffdshows debanding and should i disable that?

what de-banding settings are best for blurays?

thx

It's even better than ffdshow's deband so you should disable it.

I think the default setting are the best.

[aufkrawall]

Somehow my DPC latency doesn't get below 500 microseconds (at all, with literally no process or driver running).
Most likely there is some connection to the madVR issues I am experiencing, expecially since they also occur with 0.86, which wasn't the case before.
Sorry for bothering.

[Deim0s]

madshi,
And this did not occur with v0.86.11? It's a new problem with v0.87.x?
Yes, only v0.87.x.
Is it possible that you're running out of GPU RAM?
I do not quite understand the question. My GPU: ASUS GTX770 2GB, during the experiment, from applications that run only MPC-HC.
May I ask you, what do you recommend setting queues for this card? I am using "smooth motion".
Try lowering the GPU queues and/or the number of pre-rendered frames. Does that help?
I did the minimum queues:
CPU queue - 4
GPU queue - 4
Win. mode -> backbuffers - 1
LAV with DXVA CUVID when switching to full screen - black screen.
madVR - log (http://rghost.ru/51917970)
LAV without DXVA when switching to full screen - black screen.
madVR - log (http://rghost.ru/51918099)
LAV without DXVA - normal playback
madVR - log (http://rghost.ru/51918151)
If something else is needed, I will do.

[flashmozzg]

madshi,
I do not quite understand the question. My GPU: ASUS GTX770 2GB, during the experiment, from applications that run only MPC-HC.
May I ask you, what do you recommend setting queues for this card? I am using "smooth motion".

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

[Soukyuu]

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

[cyberbeing]

NVIDIA GTX 770 + madVR 0.87g | 0.87.1

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

Broken = black screen, frozen frame, and/or hung GPU

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 earlier post where I mentioned that 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.

[DragonQ]

Improved over v0.87.0, or improved over v0.86.11? How is it compared to v0.86.11?
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.

[pie1394]

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 (http://i.imgur.com/dBi2QIM.jpg)
After switching to full screen mode and get a black screen (http://i.imgur.com/HUUht7y.png)

[PetitDragon]

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

[michkrol]

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]

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

[noee]

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]

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]

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 :rolleyes:

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 (http://abload.de/img/deinterrorqtlol.png)
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]

Error Diffusion works on 327.23, but NNEDI chroma upscaling or doubling doesn't.
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 (https://dl.dropboxusercontent.com/u/19330332/nnedi3_upscale_yellow.jpg), green tints (https://dl.dropboxusercontent.com/u/19330332/nnedi3_upscale_green.jpg) and missing green channel (https://dl.dropboxusercontent.com/u/19330332/nnedi3_doubling_br.jpg).

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)
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.
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.
^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. :D
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!

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.

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.

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

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]

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! :D
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 (http://www.forum-3dcenter.org/vbulletin/member.php?u=12085), 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]

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]

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. ;)
Should've gone with CUDA, the API is much easier to use, too! :D
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.

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.

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

[madshi]

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?
So what is the final conclusion? I'm not sure right now. Is this a new problem with v0.87.x or is it not?

Hmm, so setting deband to say, "low", that option will increase it to "high" where needed?
Not to "high" maybe, but quite a bit higher than "low". But don't expect perfection.

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...
If you want OpenCL support, AMD is the better option at the moment. Many of the problems I've having are with the D3D9 <-> OpenCL interop, though. Which most applications don't need. So probably for normal use causes you're safe enough with NVidia. OpenCL performance is probably not as good as AMD, though, compared to how your NVidia GPU compares to AMD in game performance.

[Ziron]

Couldn't NNEDI3 be written as an OpenGL shader? That would probably cause less compatibility issues. It would also have the side effect of making it useable by emulators.

[sneaker_ger]

I'm also having trouble with the FSE image freezing (but sound playing on normally) when skipping to a new file/restarting the file.

http://www.file-upload.net/download-8552116/madVR---log---image-freeze-FSE-new-file.7z.html

1. start file in windowed mode
2. go into FSE and play file for a few seconds (everything's normal up until here)
3. restart video via ctrl+e (->current image freezes)

Win 7 x64, MPC-HC 1.7.1.383, madvr 0.87.11

===

A question regarding the settings dialogue outside of playing a file: is it normal that it takes a few seconds to open compared to instantly when playing a file? Is it waiting for an answer of open madVR instances and assumes there is none after waiting a bit?

[iSunrise]

@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.
Switching while smooth motion is on works fine in 0.86.11 and in all of your test builds, too. I found the problem though and it´s not smooth motion related at all.

It seems that simply enabling OpenCL related things like image doubling in it´s current form on NV can lead to the NV drivers behaving abnormally, even after shutting down every related player process or madVR entirely and that doesn´t seem to go away if you don´t restart the system. So any OpenCL testing currently could lead to false positives with other madVR functionality. Just as a heads-up.

After a system restart, 0.87.1 works just fine in that regard. Sorry for the wasted time, but I didn´t expect this weird NV driver behaviour at all. They are usually not that error prone and very reliable.

[noee]

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

No diff with any of the 6 builds with the deint speed, all hover between 18-22ms for this 1080i VC1 (DXVA2 decode) file I'm using.

[huhn]

i only report problem with 87.x so yeah i can get it working with 86.11 (i just switch to this sup version)

i just finished testing all 6 again all crash with 70080005 error.

yet again after this i toke the madVR08611.zip from videohelp override alle datas from 87.1 and it didn't work to the player crashed again every thing was at default except the display mode i added : 1080p23, 1080p24, 1080p50, 1080p59, 1080p60

then i started the restore default settings.bat added 1080p23, 1080p24, 1080p50, 1080p59, 1080p60 and it works fine now so the error with film-video has something to do with the madvr settings.

i tested all 6 .ax with 87.1 with uninstall install and reset.

but the freeze problem doesn't happen with 86.11 and settings from version 87.1

[madshi]

I'm also having trouble with the FSE image freezing (but sound playing on normally) when skipping to a new file/restarting the file.

http://www.file-upload.net/download-8552116/madVR---log---image-freeze-FSE-new-file.7z.html

1. start file in windowed mode
2. go into FSE and play file for a few seconds (everything's normal up until here)
3. restart video via ctrl+e (->current image freezes)

Win 7 x64, MPC-HC 1.7.1.383, madvr 0.87.11
Please try the test builds I posted a few posts above.

A question regarding the settings dialogue outside of playing a file: is it normal that it takes a few seconds to open compared to instantly when playing a file? Is it waiting for an answer of open madVR instances and assumes there is none after waiting a bit?
It opens instantly on my PC.

It seems that simply enabling OpenCL related things like image doubling in it´s current form on NV can lead to the NV drivers behaving abnormally, even after shutting down every related player process or madVR entirely and that doesn´t seem to go away if you don´t restart the system. So any OpenCL testing currently or in the future on NV could lead to false positives with other madVR functionality. Just as a heads-up.

After a system restart, 0.87.1 works just fine in that regard. Sorry for the wasted time, but I didn´t expect this weird NV driver behaviour at all. They are usually not that error prone and very reliable.
Ouch... :(

No diff with any of the 6 builds with the deint speed, all hover between 18-22ms for this 1080i VC1 (DXVA2 decode) file I'm using.
That's weird! I wish I could reproduce that here... :(

[madshi]

i only report problem with 87.x so yeah i can get it working with 86.11 (i just switch to this sup version)

i just finished testing all 6 again all crash with 70080005 error.

yet again after this i toke the madVR08611.zip from videohelp override alle datas from 87.1 and it didn't work to the player crashed again every thing was at default except the display mode i added : 1080p23, 1080p24, 1080p50, 1080p59, 1080p60

then i started the restore default settings.bat added 1080p23, 1080p24, 1080p50, 1080p59, 1080p60 and it works fine now so the error with film-video has something to do with the madvr settings.

i tested all 6 .ax with 87.1 with uninstall install and reset.

but the freeze problem doesn't happen with 86.11 and settings from version 87.1
I'm having trouble understanding what you mean. You're saing "and it works fine now". That seems to say that one of the test builds (or all of them or what?) work alright after restoring the default settings. But then you say "bug the freeze problem doesn't happen with 86.11". So I'm all confused. Is it working fine now or is it not? I don't really understand what you're saying...

[truexfan81]

madshi the 0.87.1 works much better thank you, i can even do 1080i with it if i disable the deband filter.

any chance of getting the deband settings added to the profiles? with that i could make a 1080i profile to have it turn it off automatically.

thanks

[huhn]

ok 2 problems:


video-film mode switch with frame rate change error:

87.1 and 6 test build= crash - creating Direct3d Device failed (80070005)

87.1 at default except display modes overwritten with 86.11 = player crash need a log i can pm it to you

ofc 86.11 working fine

freeze with exclusive fullscreen and file change:

87.1 and 6 test build= freeze

87.1 at default except display modes overwritten with 86.11 = works fine

ofc 86.11 working fine no reset needed.

[madshi]

any chance of getting the deband settings added to the profiles?
This functionality is already there!

ok 2 problems:

video-film mode switch with frame rate change error:

87.1 and 6 test build= crash - creating Direct3d Device failed (80070005)

87.1 at default except display modes overwritten with 86.11 = player crash need a log i can pm it to you

ofc 86.11 working fine

freeze with exclusive fullscreen and file change:

87.1 and 6 test build= freeze

87.1 at default except display modes overwritten with 86.11 = works fine

ofc 86.11 working fine no reset needed.
Ok, I understand. Now I just I wish I would understand what's causing these problems...

[cyberbeing]

A question regarding the settings dialogue outside of playing a file: is it normal that it takes a few seconds to open compared to instantly when playing a file?

Same issue here, it takes 5 seconds or so after clicking "Edit Settings" before the settings window opens when madVR is offline. Can reproduce this in GraphStudioNext as well as a MPC-HC's external filters pane.

Win7 SP1 x64

[kerimcem]

I do not like NNEDI3 :( blurry :( lancos3 jin3 bubic75 good...

[madshi]

Same issue here, it takes 5 seconds or so after clicking "Edit Settings" before the settings window opens when madVR is offline. Can reproduce this in GraphStudioNext as well as a MPC-HC's external filters pane.
Why does every *** bug not occur on my PC? I'm getting a little bit frustrated right now...

I do not like NNEDI3 :( blurry :( lancos3 jin3 bubic75 good...
Are you sure you're really testing NNEDI3? It shouldn't be blurry, at least not if you already start with sharp content and then upscale it.

[Leader]

Hi madshi. In Windows XP, versions 0.87.0, 0.87.1, when you open any video - black screen. In version 0.86.11 - okay, all right. What is the reason?

[DragonQ]

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.

Phew, that took a while. None of those comes close to 0.86.11 times unfortunately (scroll to see all):

Default Software:
Deinterlace: 18.99 ms
Split: 19.22 ms
Rendering: 8.19 ms
Present: 0.46 ms
Dropped Frames: 20
Delayed Frames: 0

Default DXVA2 Native:
Deinterlace: 14.63 ms
Split: 17.75 ms
Rendering: 8.16 ms
Present: 0.57 ms
Dropped Frames: 26
Delayed Frames: 2

No Crop Software:
Deinterlace: 19.82 ms
Split: 19.88 ms
Rendering: 9.81 ms
Present: 0.46 ms
Dropped Frames: 33
Delayed Frames: 1

No Crop DXVA2 Native:
Deinterlace: 11.21 ms
Split: 14.25 ms
Rendering: 6.97 ms
Present: 0.26 ms
Dropped Frames: 8
Delayed Frames: 1

No Shared Textures Software:
Deinterlace: 17.32 ms
Split: 18.44 ms
Rendering: 7.74 ms
Present: 0.44 ms
Dropped Frames: 7
Delayed Frames: 1

No Shared Textures DXVA2 Native:
Deinterlace: 11.69 ms
Split: 14.84 ms
Rendering: 6.77 ms
Present: 0.32 ms
Dropped Frames: 7
Delayed Frames: 1

DeintThread Setting Textures Software:
Deinterlace: 18.87 ms
Split: 18.92 ms
Rendering: 8.35 ms
Present: 0.42 ms
Dropped Frames: 18
Delayed Frames: 1

DeintThread Setting DXVA2 Native:
Deinterlace: 11.27 ms
Split: 14.76 ms
Rendering: 6.65 ms
Present: 0.28 ms
Dropped Frames: 8
Delayed Frames: 0

No Backbuffer+1 Software:
Deinterlace: 17.06 ms
Split: 17.18 ms
Rendering: 8.37 ms
Present: 0.56 ms
Dropped Frames: 16
Delayed Frames: 1

No Backbuffer+1 DXVA2 Native:
Deinterlace: 11.93 ms
Split: 14.89 ms
Rendering: 7.31 ms
Present: 0.28 ms
Dropped Frames: 11
Delayed Frames: 1

ConfigCopyback Software:
Deinterlace: 18.48 ms
Split: 18.91 ms
Rendering: 7.28 ms
Present: 0.37 ms
Dropped Frames: 21
Delayed Frames: 1

ConfigCopyback DXVA2 Native:
Deinterlace: 10.49 ms
Split: 14.27 ms
Rendering: 6.46 ms
Present: 0.25 ms
Dropped Frames: 8
Delayed Frames: 1


Repeated for reference:

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

EDIT: I found the issue. These slow rendering times only occur when Smooth Motion is enabled. Otherwise, 0.87.1 is fine in both decoding modes (although still a bit worse than 0.86.11), as shown here:

0.86.11 Software:
Deinterlace: 7.78 ms
Split: 8.97 ms
Rendering: 2.84 ms
Present: 0.15 ms
Dropped Frames: 8
Delayed Frames: 0

0.87.1 Software:
Deinterlace: 9.02 ms
Split: 11.64 ms
Rendering: 2.49 ms
Present: 0.14 ms
Dropped Frames: 12
Delayed Frames: 1

[cca]

If it's any consolation, I don't seem to have any of these bugs either with my Radeon 5850. Debugging is such a nasty job...

Sent from my Nexus 7 using Tapatalk