madVR - high quality video renderer (GPU assisted)

[cca]

Tried 0.87 on my netbook just to see the behaviour there. It has a completely crappy Intel GMA3600 with horrid drivers, has no support for OpenCL whatsoever. For madVR to be usable in that setup I have everything to the absolute minimum, Bilinear filtering for everything, and ALL trade quality for perfomance options checked.

That setup worked fine with 0.86, but with 0.87 I see frame drops. Cuprit is again the render queue, something on 0.87 is definitely misbehaving.

[Vyral]

For AMD users : I've checked the release notes and the OpenCL feature was added on the 13.9 driver (see : http://support.amd.com/en-us/kb-arti...easeNotes.aspx).

I've tried to test the new OpenCL features on madVR but, even though I have a powerfull GPU, it seems I can't use any. Therefore, I will stick with Jinc 3 AR and Catmull-Rom AR/LL.
On the other hand, debanding works great with little impact on performance.

[romulous]

Originally Posted by madshi

HKEY_CURRENT_USER\Software\madVR\BorderColor DWORD 1

Hi madshi,

I think that should actually be:
HKEY_CURRENT_USER\Software\madshi\madVR\BorderColor

[ryrynz]

Weighing in with HD4000, no issues. Installed 0.87 then 0.87c on top. NNEDI doubling on Luma even with 16 neurons looks to be too demanding, can't even enable OpenCL error diffusion without dropped frames.
I wonder how well the HD5200 is going to fare.. anyone got one?

I enabled 'use a separate device for presentation' and get a few black frame flickers and dropped frames on entry into fullscreen (exclusive or windowed) and a single black frame flicker on drop down to a windowed screen.
Enabling 'use a separate device for presentation' drops rendering and present times down a bit so might switch over to that if the frame drops/flickers can be sorted. Correct registry location is HKEY_CURRENT_USER\Software\madshi\madVR\
I created a 32bit Dword called BorderColor and set it to a hexadecimal value of 1, am currently using 10.18.10.3383 drivers, maybe this fix is no longer required for the latest drivers? as using the BorderColor registry entry doesn't seem to change anything for me.

New drivers can be found here (Note Intel made a mistake with the date info, as it was WHQL:ed January 8 2014 not 2013, and is 15.33.12.x)

[nevcairiel]

Upgraded from 0.86.11 to 0.87c, CPU usage increased drastically when playing videos with native DXVA2 (but also with any other decoder modes, but its not so glaringly obvious there)
On 0.86 its <1%, CPU remains at lowest clock, with 0.87c its at 5-6%, CPU clock raised.

No settings changed in the upgrade, and confirmed none of the new features are active.
No SmoothMotion, no deint, just playback of progressive content on my NVIDIA card.

[truexfan81]

madshi there is something seriously wrong with this release, even with the 87c/d build, i cannot play 60p video at all even with all scalers set to bilinear the backbuffer and render queues are empty. Revert back to the deband14 build and all plays perfectly and all queues are full.

[sdancer75]

Originally Posted by madshi

You should use QueryInterface() on the madVR instance to get access to those custom interfaces.

Thanks,

I thought that all those interfaces are reserved only for the VMR9. Anyway you mean that I can use IID_IVMRFilterConfig9, IID_IVMRWindowlessControl9, IID_IVMRMixerBitmap9, IID_IVMRMixerControl9 and IID_IVMRMonitorConfig9 as normal with madVR?

The error i get is "error C2275: 'IMadVROsdServices' : illegal use of this type as an expression"

with the code below :

//madVR
    m_pMadVR = AddFilter("madVR",CLSID_madVR);
    if (m_pMadVR ==  NULL){
	    ReportError(_T("Failed to initialize the filter (madVR)."),hr);
	    AMLOGINFO(_T("Failed to initialize the filter (madVR) errorcode=%s."),GetErrorCode(hr) );
		return FALSE;
	}

     hr = m_pMadVR->QueryInterface(IMadVROsdServices,(void**)&m_pMadVRServices);
    if (FAILED(hr))
    {
	   ReportError(_T("Failed to initialize the filter."),hr);
	   AMLOGINFO(_T("Failed to initialize the filter. errorcode=%s."),GetErrorCode(hr) );
	   return FALSE;
    }

[cyberbeing]

Originally Posted by nevcairiel

Upgraded from 0.86.11 to 0.87c, CPU usage increased drastically

I can reproduce this as well with identical madVR settings along with LAV Video software decoding.

0.86.11 no flushing:


0.87b & 0.87c no flushing:


0.87.0 & 0.87a no flushing:


0.86.11 has a 1.49% CPU Load, with the CPU @3.2Ghz/4.4Ghz speed step state.

0.87b & 0.87c has a 8.27% CPU load, with the CPU @4.2Ghz/4.4Ghz speed step state. Same higher CPU load is seen in Windowed Mode, Overlay Mode, and FSE.

0.87.0 & 0.87a has a 3.27% CPU Load, with the CPU @3.6Ghz/4.4Ghz speed step state. Same higher CPU load is seen in Windowed Mode, Overlay Mode, and FSE.

[truexfan81]

Originally Posted by cyberbeing

I can reproduce this as well with identical madVR settings along with LAV Video software decoding.

0.86.11 no flushing:
http://i1.someimage.com/FgHCpXB.png

0.87b & 0.87c no flushing:
http://i1.someimage.com/c6m3NNc.png

0.87.0 & 0.87a no flushing:
http://i1.someimage.com/0Z3cjOM.png

0.86.11 has a 1.49% CPU Load, with the CPU @3.2Ghz/4.4Ghz speed step state.

0.87b & 0.87c has a 8.27% CPU load, with the CPU @4.2Ghz/4.4Ghz speed step state. Same higher CPU load is seen in Windowed Mode, Overlay Mode, and FSE.

0.87.0 & 0.87a has a 3.27% CPU Load, with the CPU @3.6Ghz/4.4Ghz speed step state. Same higher CPU load is seen in Windowed Mode, Overlay Mode, and FSE.

i also had this issue, i have reverted back to the deband14 build

[Finnish Flash]

Hi, madshi! I've been using your renderer for quite a while now and absolutely love it! Thanks for all the effort you've put into it.

Is there any chance of using the 4770k's internal HD 4600 GPU for OpenCL stuff while using my GTX 670 for all the other aspects of post processing?

My OS is Windows 8.1 and I'm running a headless configuration. At least LAV's QuickSync decoder seems to be working this way.

[Qotscha]

Originally Posted by Qotscha

Same here with Radeon HD 6850. Massive framedrops with videos and settings that worked well with 0.86.11 and latest deband test builds. Render queue is the first one that does not fill.

I did some further testing. Actually, 0.87 and 0.87a are fine (except with interlaced content) and 0.87b is the first one to cause framedrops.

[cca]

I disagree, the netbook test I did and posted before was done with 0.87, not with any of the hotfix versions and still caused frame drops.

Sent from my Nexus 7 using Tapatalk

[madshi]

Originally Posted by detmek

Is OpenCL supported on Nvidia 9500GT?
Everything works just fine with official 0.87 build and 0.87b but I get dropped frames and empty render queue and backbuffer queue with 0.87d. Just tested for fun and reverted back to official 0.87.
edit:
I tested NNEDI for Chroma and increases rendering times. Is that mean that OpenCL works? Back to Bicubic.

If you get a proper image and increased rendering times then that probably means it's working for you. Seems right now that NVidia OpenCL works for 9xxx generation of GPUs, but not for newer GPUs.

Originally Posted by michkrol

Sorry, you're right (again). Seems like it's not a good idea to use "(renderQueue<30)" or similar for some settings, since the profiles get switched almost constantly once even one change is triggered.

You're right. I thought adding the "renderQueue" field would be a clever idea, but it changes too often for it to make sense. So I've completely removed it now.

Originally Posted by cyberbeing

Here are the new test build logs for the OCL dither issue on my GTX 770:

madVR 0.87d OCL Dither debug logs

Thanks. Seems that D3D9 <-> OpenCL interop doesn't work properly. I've added a few more logging lines to get more information. Could I please get another log with Error Diffusion with the next build?

Originally Posted by DarkSpace

I set up a "Don't Use OpenCL" Profile for when I'm hardware deinterlacing and a "Use OpenCL" Profile for when I'm not. Now I noticed that the "Don't Use OpenCL" Profile always gets selected (the name is displayed in bold).

Known problem in official v0.87.0, fixed in test build 87b.

Originally Posted by kasper93

How madVR performance is compared to SEt's implementation?
Here are my results from AVSMeter on HD5870. I was expecting to get better performance on madVR, at least to get stable playback. I get ~18fps without MT, but with higher thread count I get unstable fps as you can see in log.

https://gist.github.com/kasper93/de93cad4d410a9bcb575
https://gist.github.com/kasper93/ef7b3a0b2165d56b5b0a

Sorry, if you find my post not useful,c but I always though that HD5870 is still powerful enough, and generally OCL performane is not that bad.

With madVR I get ~7fps with NNEDI and ~10fps with dither. I guess OCL is not for me

On my PC with my HD7770 my modified kernel runs slightly faster than SEt's original kernel. But then, that is without D3D9 <-> OpenCL interop taken into account. The interop unfortunately costs quite a bit of performance. But it might be a bit too early to do a final performance judgement now, considering that there are still several problems reported that need to be fixed.

Originally Posted by Salad

.87 gives me a black screen when playing 25fps video with smooth motion enabled.

AMD Radeon HD 6670, Windows 8.1 x64.

That's weird. Works fine here. Is that maybe with DXVA deinterlacing?

Originally Posted by QBhd

Well, all worked flawless for me! And I must say I am impressed! Image is spectacular.

Thank you. Finally someone for whom everything works (as it does for me).

Originally Posted by truexfan81

i'd love to use the profiles to use different scalers for 24p, 25, 30p and then a different set for 50,60p but scripting has always been very confusing to me, same with this

At some point I may add a graphical tool to configure the profile rules, but not anytime soon. And the underlying logic won't change.

Originally Posted by Vyral

I've tried to test the new OpenCL features on madVR but, even though I have a powerfull GPU, it seems I can't use any. Therefore, I will stick with Jinc 3 AR and Catmull-Rom AR/LL.

Don't do a final judgement yet. Wait until all bugs are fixed, then try again.

Originally Posted by kasper93

When we edit script while playing - profiles are switched fine, but highlighted profile is still the same till we open settings window again. Could you update settings window on fly? This would help debugging scripts

This behaviour has annoyed me already, too. But at the moment I'm more concerned with real bugs and less with "cosmetical" issues like this.

Originally Posted by romulous

I think that should actually be:
HKEY_CURRENT_USER\Software\madshi\madVR\BorderColor

Yes, thanks.

Originally Posted by ryrynz

I created a 32bit Dword called BorderColor and set it to a hexadecimal value of 1, am currently using 10.18.10.3383 drivers, maybe this fix is no longer required for the latest drivers? as using the BorderColor registry entry doesn't seem to change anything for me.

New drivers can be found here (Note Intel made a mistake with the date info, as it was WHQL:ed January 8 2014 not 2013, and is 15.33.12.x)

Thx for the report, I'll try the new drivers later. I did have the bug reported to Intel, so maybe they did already fix it in the meanwhile.

Originally Posted by sdancer75

I thought that all those interfaces are reserved only for the VMR9. Anyway you mean that I can use IID_IVMRFilterConfig9, IID_IVMRWindowlessControl9, IID_IVMRMixerBitmap9, IID_IVMRMixerControl9 and IID_IVMRMonitorConfig9 as normal with madVR?

Don't know right now which of those is supported by madVR. I think at least one of those is, but not all of them.

Originally Posted by sdancer75

The error i get is "error C2275: 'IMadVROsdServices' : illegal use of this type as an expression"

Try "__uuidof(IMadVROsdServices)", or try manually defining a GUID with the proper numbers. Don't know right now how to do this the easiest way.

Originally Posted by nevcairiel

Upgraded from 0.86.11 to 0.87c, CPU usage increased drastically when playing videos with native DXVA2 (but also with any other decoder modes, but its not so glaringly obvious there)
On 0.86 its <1%, CPU remains at lowest clock, with 0.87c its at 5-6%, CPU clock raised.

Originally Posted by cyberbeing

I can reproduce this as well with identical madVR settings along with LAV Video software decoding.

0.86.11 has a 1.49% CPU Load, with the CPU @3.2Ghz/4.4Ghz speed step state.

0.87b & 0.87c has a 8.27% CPU load, with the CPU @4.2Ghz/4.4Ghz speed step state. Same higher CPU load is seen in Windowed Mode, Overlay Mode, and FSE.

0.87.0 & 0.87a has a 3.27% CPU Load, with the CPU @3.6Ghz/4.4Ghz speed step state. Same higher CPU load is seen in Windowed Mode, Overlay Mode, and FSE.

I think this is caused by the profiling stuff. Especially the "renderQueue" field value was changed multiple times per second and every time madVR had to re-read all settings etc. I hope the new test build (see below) fixed this problem?

Originally Posted by truexfan81

i also had this issue, i have reverted back to the deband14 build

Please do not quote posts with big large images in it!! At least not without removing the images first. Otherwise you blow up the thread unnecessarily.

Originally Posted by Finnish Flash

Is there any chance of using the 4770k's internal HD 4600 GPU for OpenCL stuff while using my GTX 670 for all the other aspects of post processing?

The 4600 will probably too slow for this to make sense, compared to the 670. Also, such a logic would require moving a lot of pixels around from one GPU to system RAM and then to the next GPU. This is not likely to be supported any time soon (if ever).

Originally Posted by fairchild

Latest official version for me is just showing a black screen when using it's deinterlacing

Known problem. Already fixed in a test build.

Originally Posted by kazuya2k8

turning on anything related to NNEDI3 gives me blank or freezed frame output.

Originally Posted by Thunderbolt8

black picture with openCL

Originally Posted by namaiki

OpenCL error diffusion is not enabled for the below screenshots, but when it is enabled it seems to produce a black image.

Known problem with NVidia GPUs atm.

Originally Posted by cca

Having performance issues as well, can barely playback interlaced DVDs without frame drops anymore, even with low resizing settings, no NNEDI, not anti-banding, dropped resizing to Lanczos3 and it still has heavy fluctuations in the render queue.

Originally Posted by Qotscha

Same here with Radeon HD 6850. Massive framedrops with videos and settings that worked well with 0.86.11 and latest deband test builds. Render queue is the first one that does not fill.

Originally Posted by DragonQ

So presumably noee, cca, Qotscha, and myself are all having performance issues on different brands of GPUs for the same reason.

Originally Posted by Thunderbolt8

installed .87d, didnt change anything, tested an AVC 60p sample, got framedrops which hasnt happened before. and black picture with openCL

Originally Posted by TheShadowRunner

On my system, 0.87.0 has completely killed video playback (black screen at all times and player crashes on exit).

Originally Posted by truexfan81

same here, my dualcore 2.9 cpu and gtx650 just can't handle it, using any of the ocl stuff my cpu just sits there pegged at 100% even with 24p xvid :O

Originally Posted by Qotscha

I did some further testing. Actually, 0.87 and 0.87a are fine (except with interlaced content) and 0.87b is the first one to cause framedrops.

Please try with the new test build (see below).

Originally Posted by Devrim

0.87 gives and mpc-hc crash error when starting a video (latest nightly)

Originally Posted by alquimio_125

I have a similar problem to him. And in my case when I launch a video I get a error box ''Has Stopped working'' and I have to close. I had to revert to a previous version.

Have you tried the test build(s)? Or just the official version? Try the latest test build (see below). Or wait for the next official build.

-------

Here's a new test build:

http://madshi.net/madVR87e.rar

I hope that CPU and GPU performance is mostly back to v.86.11 levels (maybe GPU performance could be slightly lower due to modified dithering logic). Can anybody confirm?

There's a new option in the rendering settings now, allowing you to enable/disable OpenCL processing of DXVA NV12 surfaces for AMD and Intel GPUs. It's disabled by default now. Please check whether this option helps or harms with your GPU (AMD/Intel only) and report. Thanks.

OpenCL will still not work with newer NVidia GPUs. Need a new debug log for this with error diffusion enabled.

[DarkSpace]

Originally Posted by michkrol

Change it to (srcInterlaced) && (!filmMode) and try again.

Thank you, that did it.

Originally Posted by michkrol

Also we do get a built-in validator for the scripts - the small red triangle (bad script) or a small green tick (script ok) near the online help link.

Thank you. So far, I thought that red triangle simply was there to alert people to the documentation. Only after I tried your version it changed to a green tick...
I do feel somewhat stupid right now...

[nevcairiel]

CPU usage seems to be back down again, thanks.

Also, here is a log of OCL Error Diffusion on a NVIDIA GTX780:
http://files.1f0.de/tmp/madVR087eOCLDitherNVIDIA.zip

Note that not only did it not work, MPC-HC also didn't close properly and lingered around in memory. Not sure if the two issues are strictly related.

[madshi]

Thanks! The log is confusing me. Mapping the D3D9 textures to OpenCL fails for error diffusion, but it succeeds in an extra test pass I've added (for logging purposes). Will have to think about how to interpret these results. Maybe mapping fails if the textures are still being rendered on or something like that? No clue right now...

Yes, MPC-HC not closing down properly has to do with the OpenCL failure. Will have to see how to handle that situation more gracefully.

[Qotscha]

Originally Posted by madshi

Here's a new test build:

http://madshi.net/madVR87e.rar

I hope that CPU and GPU performance is mostly back to v.86.11 levels (maybe GPU performance could be slightly lower due to modified dithering logic). Can anybody confirm?

For me this did the trick. Playback is smooth and CPU and GPU usage are about the same as with 0.86.11.

[Finnish Flash]

Originally Posted by madshi

The 4600 will probably too slow for this to make sense, compared to the 670. Also, such a logic would require moving a lot of pixels around from one GPU to system RAM and then to the next GPU. This is not likely to be supported any time soon (if ever).

I see. Thanks for answering and have a great weekend!

[cyberbeing]

Originally Posted by madshi

Thanks. Seems that D3D9 <-> OpenCL interop doesn't work properly. I've added a few more logging lines to get more information. Could I please get another log with Error Diffusion with the next build?

madVR 0.87e debug logs

Originally Posted by madshi

I think this is caused by the profiling stuff. Especially the "renderQueue" field value was changed multiple times per second and every time madVR had to re-read all settings etc. I hope the new test build (see below) fixed this problem?

CPU load with 0.87e is now the same as 0.87.0 & 0.87a in my previous post, but it's still more than twice that of 0.86.11.

[DarkSpace]

Originally Posted by madshi

Known problem in official v0.87.0, fixed in test build 87b.

-------

Here's a new test build:

http://madshi.net/madVR87e.rar

In the latest test build, I have the same issues:

if (srcInterlaced) && (!filmMode) "Don't Use OpenCL"
else                              "Use OpenCL"

works just fine (thanks michkrol!), but

if (srcInterlaced && !filmMode) "Don't Use OpenCL"
else                            "Use OpenCL"

doesn't work. If you want me to enter this into the bug tracker, please tell me so.