madVR - high quality video renderer (GPU assisted)

[noee]

Just an FYI regarding the older low-end pre-GCN AMD cards (HD6570) performance. I have my primary display set at 6bit and my secondary as 8bit. Playback on the 8bit monitor with error diffusion enabled drops frames and the render queue can't keep up with all material. If I set it to 7bit, back to perfect playback with error diffusion enabled. If I turn off error diffusion and set to 8bit, same perfect playback. Not sure I can see a difference in the image with playback. Is one option more "optimal" than the other?

[DragonQ]

Performance in general is improved certainly. I can now watch that 1080i/25 video in a full screen window when using DXVA2 Native as long as I don't open any other windows on top, but not when using software decoding, so maybe CPU usage is the problem? Seems strange since this CPU is pretty beefy (mobile Ivy Bridge Core i5). If I even open GPU-Z or Task Manager it stops working and I see GPU usage at 99-100%, so I guess it's sailing close to the wind.

When the render queue dips the frame order still goes all wrong (requires pausing and resuming to fix), but this bug has existed for as long as I can remember on all of my machines.

[huhn]

render times are good now same or better than 86.9.

all version still freeze when fullscreen exclusive is used and active when a new/next file is loaded.

tested with all 3 g versions and 87.1.

this is a very typical usages and easy to reproduce but no one else reported this issue. a problem at my end?

[aufkrawall]

I'm getting framedrops with smooth motion + debanding during fade ins/outs if I disable rerendering frames for this.
Is this expected behavior? GPU is a GTX 670 at 1.2Ghz and queues seem to be fine. With smooth motion off I'm getting "just" presentation glitches in such situations.
Dunno if wanted/needed, but I guess it doesn't hurt to link to a debug log:
https://www.mediafire.com/?igbz9sayzry2rw7

[mark0077]

Originally Posted by antonyfrn

@madshi just some info for you posted by an NVidia Rep ManuelG maybe something improvements driver side or a headache I think they are off the new Quadros 334.67

I just tried these 334.67 quadro drivers on my GTX295, looks like it hasn't been fixed in these at least, still OpenCL issues.

[Deim0s]

madshi,

Does the problem still occur with the 87g test build, if you disable all OpenCL related options and if you disable debanding? (Make sure the "use random dithering..." option in the "trade quality..." section is checked/enabled.)

Yes, as before, there is a problem.
While playing content UHD (4k) began to appear such messages OSD: 1, 2.
Sometimes played with artifacts in windowed mode and black screen in full screen.
One time playback of many attempts was normal.

Maybe to you can help debug information: madVR - log

[madshi]

Originally Posted by burfadel

I tried the MadVR optimised one, and it didn't even load! (MPC-HC used a different renderer). I then went back and realised the previous version I had was 0.87E or 0.87F, so I copied over the files from 0.87G, then used the MadVR optimised version and it works fine .

Yeah, the new build requires the new mvrSettings.dll, too, otherwise it won't load.

Originally Posted by antonyfrn

I just installed 87G and tried with MadVR Optimised and both give me the below message if I go from full screen to windowed mode. (I used the restore defaults bat to clear out any settings)

resetting Direct3D device failed (80070005)
creating Direct3D device failed (80070005)

Hmmm... Can anybody else reproduce this?

Antony, is this problem new with v0.87.x, or did this also occur with v0.86.11? Can you play with all the various settings a bit to check if any setting changes anything? How about default settings, does it occur with those, too? Ideally, I'd need to be able to reproduce it somehow...

Originally Posted by DarkSpace

Yes, should be y dimension (x needs the shift, after all. Thanks for answering!
Now for the (I think) last curious question: Even though it's probably insignificant, do you have any plans to let the user choose the shifting algorithm?

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.

Originally Posted by mark0077

Cheers for the new version. All working fine except for OpenCL as reported. My driver version is 332.21 WHQL with GTX295 incase anyone else has older driver versions with the same card and it works. Do you have a contact in Nvidia or do you need any of us to post on their forums regarding the OpenCL issues?

Soukyuu just reported downgrading actually does help. So it seems to be proven: OpenCL/NVidia/madVR works with older drivers, but not with new drivers, for some reason...

Originally Posted by Soukyuu

331.81 -> 310.90:
- openCL dither works
- NNEDI doubling works (slideshow)
- luma NNEDI upscaling gives a green tint to the whole image for 10bit h264, 8bit is fine.

I am going to update versions until I hit the blackscreen again. This is with 87.1 btw.

Thanks for testing! Will be interesting to know which NVidia driver version introduced the problem.

Originally Posted by noee

Just an FYI regarding the older low-end pre-GCN AMD cards (HD6570) performance. I have my primary display set at 6bit and my secondary as 8bit. Playback on the 8bit monitor with error diffusion enabled drops frames and the render queue can't keep up with all material. If I set it to 7bit, back to perfect playback with error diffusion enabled. If I turn off error diffusion and set to 8bit, same perfect playback. Not sure I can see a difference in the image with playback. Is one option more "optimal" than the other?

I probably should have said that error diffusion is only used if your display is set to 8bit. Otherwise I'm silently falling back to random dithering. I don't think I can do error diffusion to lower than 8bit because I don't know whether the displays rounds or truncates to 6/7 bits and at which values exactly.

Originally Posted by DragonQ

Performance in general is improved certainly.

Improved over v0.87.0, or improved over v0.86.11? How is it compared to v0.86.11?

Originally Posted by huhn

all version still freeze when fullscreen exclusive is used and active when a new/next file is loaded.

tested with all 3 g versions and 87.1.

this is a very typical usages and easy to reproduce but no one else reported this issue. a problem at my end?

And this didn't occur with v0.86.11? Will try to reproduce it here...

Originally Posted by aufkrawall

I'm getting framedrops with smooth motion + debanding during fade ins/outs if I disable rerendering frames for this.
Is this expected behavior? GPU is a GTX 670 at 1.2Ghz and queues seem to be fine. With smooth motion off I'm getting "just" presentation glitches in such situations.
Dunno if wanted/needed, but I guess it doesn't hurt to link to a debug log:
https://www.mediafire.com/?igbz9sayzry2rw7

Definitely not expected behaviour. With *disabled* rerendering?? That's weird. How about if you enable it? Same problem? Or does that work fine?

Originally Posted by mark0077

I just tried these 334.67 quadro drivers on my GTX295, looks like it hasn't been fixed in these at least, still OpenCL issues.

You need to go older, not newer, it seems.

Originally Posted by Deim0s

Yes, as before, there is a problem.
While playing content UHD (4k) began to appear such messages OSD: 1, 2.
Sometimes played with artifacts in windowed mode and black screen in full screen.
One time playback of many attempts was normal.

Maybe to you can help debug information: madVR - log

And this did not occur with v0.86.11? It's a new problem with v0.87.x?

Is it possible that you're running out of GPU RAM? Try lowering the GPU queues and/or the number of pre-rendered frames. Does that help?

[michkrol]

Thanks for the new release, just tested v0.87.1. Everything works as expected.

If you're still interested, "use OpenCL to process DXVA NV12 surfaces" works here correctly (Intel HD 4000). I'm not noticing any performance penalty from this.

I really like the profiling's flexibility. I'm only missing an ability to use comments inside the script. Something like:

/* comment */

with different opening and closing tags should be quite fast to process (and easy to implement?).
I might have overdone it, but with 5 or more rules (SD/HD/FullHD + fps checks) it takes a while to sort out what is what (or what it was supposed to be). Perhaps something to consider in the future

[kasper93]

Originally Posted by madshi

Does it still occur with 87g? Which GPU, which OS?

I found out what happens. I was installing new drivers and forgot to disable video "enchantments".

It's quite strange actually because it doesn't work if I select "dynamic contrast" and any of the "De-Blocking", "Edge-enchantment", "De-noise", "Mosquito noise reduction". At least one, no matter which... "dynamic contrast" alone works fine, same as others without "dynamic contrast".

So in fact it's not a problem for me, because I always disable those options, but still maybe there is a way to fix it on madVR side.

[6233638]

Originally Posted by madshi

* fixed: auto profile switching didn't fully work

For what it's worth, I am really happy with how the profile switching works in the new version of madVR - I just haven't said anything as I didn't want to interrupt the Nvidia OpenCL discussion.

Originally Posted by madshi

Current theory is that older NVidia drivers might make OpenCL work with madVR, and that newer drivers might have broken something. Drivers 306.97 are reported to be working with GTX 560 Ti. And drivers 310.90 are reported to be working with GTX 460. This needs to be double checked.

310.90 are over a year out of date, and the oldest WHQL drivers that Nvidia has available to download on the GeForce site.
The oldest Windows 8.1 certified drivers are 327.23 from September.

I tried installing 310.90 anyway, and it was successful - I was able to use the new error diffusion dithering.
However, enabling any of the nnedi scaling options still resulted in a black screen.


I understand that HTPC users don't have much reason to keep their drivers up to date, but the opposite is true for gamers - you need to stay on the latest drivers if you're playing the latest releases. It's often recommended to use the beta drivers rather than waiting for new WHQL drivers to be released. I typically avoid those however, as they often cause problems for madVR.

[za222]

Originally Posted by madshi

Weird. Does this still happen with 87g? If so, does it happen with *all* videos or just with some? Is it related to Smooth Motion FRC or not?

The issue is still present in 0.87.1. I've tried interlaced 50i/60i/29.97telecine SD/HD MPEG2/h264 material and it always fails.
When I toggle deinterlacing (Ctrl-Shift-D) while playing, the image shows / disappears.

Also (maybe this information could help?): After the initial green screen, when I resize the window I get a completely white screen.

Smooth motion seems to be completely unrelated.

[madshi]

Originally Posted by michkrol

If you're still interested, "use OpenCL to process DXVA NV12 surfaces" works here correctly (Intel HD 4000). I'm not noticing any performance penalty from this.

That's good to hear. I think OpenCL <-> Direct3D9 interop costs less performance with Intel compared to AMD. But then Intel's OpenCL performance itself is rather bad. But the DXVA NV12 stuff is very light weight, so no problem for Intel.

Originally Posted by michkrol

I really like the profiling's flexibility. I'm only missing an ability to use comments inside the script.

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

Originally Posted by kasper93

I found out what happens. I was installing new drivers and forgot to disable video "enchantments".

It's quite strange actually because it doesn't work if I select "dynamic contrast" and any of the "De-Blocking", "Edge-enchantment", "De-noise", "Mosquito noise reduction". At least one, no matter which... "dynamic contrast" alone works fine, same as others without "dynamic contrast".

So in fact it's not a problem for me, because I always disable those options, but still maybe there is a way to fix it on madVR side.

That's interesting. Can you double check whether this is a new problem with v0.87.x? Or does it also occur with v0.86.11?

Originally Posted by 6233638

For what it's worth, I am really happy with how the profile switching works in the new version of madVR

Originally Posted by 6233638

310.90 are over a year out of date, and the oldest WHQL drivers that Nvidia has available to download on the GeForce site.
The oldest Windows 8.1 certified drivers are 327.23 from September.

I tried installing 310.90 anyway, and it was successful - I was able to use the new error diffusion dithering.
However, enabling any of the nnedi scaling options still resulted in a black screen.

I understand that HTPC users don't have much reason to keep their drivers up to date, but the opposite is true for gamers - you need to stay on the latest drivers if you're playing the latest releases. It's often recommended to use the beta drivers rather than waiting for new WHQL drivers to be released. I typically avoid those however, as they often cause problems for madVR.

I don't think it's a good long term solution to require old drivers. Maybe I can make things work with new drivers, too. But I don't know yet. This might be NVidia's job to fix. Or mine. At least installing old drivers could be a temporary solution for users who desperately want to try/use the new OpenCL features...

Originally Posted by za222

The issue is still present in 0.87.1. I've tried interlaced 50i/60i/29.97telecine SD/HD MPEG2/h264 material and it always fails.
When I toggle deinterlacing (Ctrl-Shift-D) while playing, the image shows / disappears.

Also (maybe this information could help?): After the initial green screen, when I resize the window I get a completely white screen.

Smooth motion seems to be completely unrelated.

So the issue is caused by DXVA deinterlacing, correct? It doesn't occur if you force film mode on? And it also doesn't occur if you force deinterlacing off? Does this issue also occur with v0.86.11? Or is it a new problem with v0.87?

[nevcairiel]

Originally Posted by madshi

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.

Off-Topic, but in C++ I use "#if 0" to disable large code blocks to avoid such problems..

[cyberbeing]

GTX 770

__

312.69 driver (Quadro maintenance release for R310 branch, 10/28/2013)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)

__


310.90 driver (Geforce R310 branch, 12/29/2012)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)

[antonyfrn]

@madshi the issue was introduced for me in 0.87.G I tried with the optimised file and the latest build v0.87.1. Each time I've reset the setting to default using the bat file to reset madvr settings I will play about with it again some more and try get you a log

[Ava Pug]

last working nvidia driver that works for me is 327.23

[za222]

Originally Posted by madshi

So the issue is caused by DXVA deinterlacing, correct? It doesn't occur if you force film mode on? And it also doesn't occur if you force deinterlacing off? Does this issue also occur with v0.86.11? Or is it a new problem with v0.87?

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

0.86.11 in all of the cases above -> Works

[Budtz]

i can confirm switching to another file in FSE-mode crashes or freezes. this happens everytime i try and never i windowed mode

[madshi]

Originally Posted by nevcairiel

Off-Topic, but in C++ I use "#if 0" to disable large code blocks to avoid such problems..

Hehe, yes, that should work, too. Personally, I always use // for comments. As a result I can use { or /* to comment out large source code sections without any problems.

Originally Posted by cyberbeing

GTX 770

__

312.69 driver (Quadro maintenance release for R310 branch, 10/28/2013)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)

__


310.90 driver (Geforce R310 branch, 12/29/2012)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)

Interesting. NNEDI works here, too, with my 9400, but this might be just luck. Maybe there's a bug there in my code, I don't know. Could be, since error diffusion works.

Originally Posted by antonyfrn

@madshi the issue was introduced for me in 0.87.G I tried with the optimised file and the latest build v0.87.1. Each time I've reset the setting to default using the bat file to reset madvr settings I will play about with it again some more and try get you a log

Please always quote me, otherwise I lose track of past communication.

I could interpret your post as saying that the problem did not occur in v0.86.11, but I don't want to interpret, I want to know for sure, without any doubt. So please say it clearly: Did this issue occur in v0.86.11 or not? Please double check if you're not sure. Thanks.

Originally Posted by Ava Pug

last working nvidia driver that works for me is 327.23

You mean with OpenCL? Does NNEDI work for you with that driver? Or just error diffusion?

Originally Posted by za222

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

0.86.11 in all of the cases above -> Works

Hmmmm... Ok. Let me see what has changed in the source code which could explain this. Might have to release some test builds to get to the bottom of this problem...

Originally Posted by Budtz

i can confirm switching to another file in FSE-mode crashes or freezes. this happens everytime i try and never i windowed mode

Ok, I'll look into it.

[kasper93]

Originally Posted by madshi

That's interesting. Can you double check whether this is a new problem with v0.87.x? Or does it also occur with v0.86.11?

It is not a regression actually. I've tested few madVR version back and the same results. So either I never noticed this (not likely) or AMD break something in drivers. Anyway sorry for interrupting regression hunt