madVR - high quality video renderer (GPU assisted)

[noee]

Which was your GPU again? Can't remember the GPU of all users. How much do the rendering times differ between v0.86 and v0.87? And do you have debanding on or off?

sorry, HD6570, latest Catalyst

Jinc3 w/AR, SD film, 10bit, all explicit OpenCL stuff off (including error diffusion), debanding off.

Avg render FSE mode:
.86: ~23ms (0 dropped frames)
.87: ~25.5ms (constant frame drops)

Not that different. But the render queue is full on .86 and on .87, it hovers at "0-3".

[cyberbeing]

I'd like to get a debug log with this new test build with error diffusion activated. Thanks.

There is a slight problem, since you haven't provided a debug version of the new test builds.

[sneaker_ger]

Too bad. Still same amount of crashing?

I left a note on the bug tracker.

For others:
If you experience crashes after updating from 0.86.11 to 0.87 and are using EMET (http://microsoft.com/EMET), try turning it off. Worked for me. (Yet again time wasted because of this that could've gone into other things, sorry...)

[madshi]

sorry, HD6570, latest Catalyst

Jinc3 w/AR, SD film, 10bit, all explicit OpenCL stuff off (including error diffusion)

Avg render FSE mode:
.86: ~23ms (0 dropped frames)
.87: ~25.5ms (constant frame drops)

Not that different. But the render queue is full on .86 and on .87, it hovers at "0-3".
Hmmmmm... Forced film mode? I did a small change to the dithering algorithm. That might explain the difference, unfortunately. Not much I can do about it, unfortunately... :(

There is a slight problem, since you haven't provided a debug version of the new test builds.
Stupid me. Here it is:

http://madshi.net/madVR87d.rar

[fagoatse]

Out of curiosity, does OpenCL support mean that we can use madvr on lower-end AMD GPU/APUs that would otherwise be too slow to run it? I'm mostly referring to kaveri APUs equipped with really fast ram.

[cca]

sorry, HD6570, latest Catalyst

Jinc3 w/AR, SD film, 10bit, all explicit OpenCL stuff off (including error diffusion), debanding off.

Avg render FSE mode:
.86: ~23ms (0 dropped frames)
.87: ~25.5ms (constant frame drops)

Not that different. But the render queue is full on .86 and on .87, it hovers at "0-3".

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. In the previous version I could play the same DVD with Jinc resizing for both luma & chroma, turn smooth motion ON and still have full queues. Now I don't know what causes such huge perfomance hit but if it's OpenCL, I suggest some switch to completely disable it.

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

[michkrol]

What? The v.087b test build is worse than the official v0.87 build? That confuses me. Are you sure you're testing with the same settings?

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.
Probably because changing them clears the render queue? I'm talking about switching between dxva and normal scaling or turning debanding on/off. Might be worth investigating and perhaps adding some delay to fix this behavior, once you get some free time.

For now, thanks for this release and I'm back to testing :cool:

EDIT: I can easily trigger this behavior with 1080p content, dxva2 downscaling, windowed mode and (renderQueue<30) as a condition to switch debanding off/on. Any other combination of settings works correctly. I'm on Intel HD4000, if that's important.

[cyberbeing]

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

madVR 0.87d OCL Dither debug logs (https://www.mediafire.com/?cgu37g22t21u8r1)

[nevcairiel]

Out of curiosity, does OpenCL support mean that we can use madvr on lower-end AMD GPU/APUs that would otherwise be too slow to run it? I'm mostly referring to kaveri APUs equipped with really fast ram.

No, the OpenCL options will need even more performance than before, if anything it'll need a faster system.

[Qotscha]

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. In the previous version I could play the same DVD with Jinc resizing for both luma & chroma, turn smooth motion ON and still have full queues. Now I don't know what causes such huge perfomance hit but if it's OpenCL, I suggest some switch to completely disable it.

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.

[DragonQ]

So presumably noee, cca, Qotscha, and myself are all having performance issues on different brands of GPUs for the same reason. Hopefully madshi can figure out what the problem is.

[DarkSpace]

Thanks for the new build!
Personally, I only need profiling because both hardware deinterlacing and OpenCL is too much for my card apparently, but that's also why I noticed something. I'd like a confirmation before I report it as bug first, though...
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). Here's the selection code, just in case:

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

Did I do it wrong or should I report this as a bug?

[Thunderbolt8]

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

[michkrol]

Did I do it wrong or should I report this as a bug?
Change it to (srcInterlaced) && (!filmMode) and try again. 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.
installed .87d, didnt change anything, tested an AVC 60p sample, got framedrops which hasnt happened before.

I might be wrong, but isn't this a debug build of 87c, hence should be slower?

[TheShadowRunner]

Hi madshi,
On my system, 0.87.0 has completely killed video playback (black screen at all times and player crashes on exit).
A log: http://videoff7.free.fr/madVR_TSR - log.zip
Thanks for your support.
(Tested with multiple stream types, h264, mpeg2, xvid, multiple decoders, coreavc, ffdshow, lav, same results. Also tested via building a dshow graph manually in graphstudionext, same result = always a black screen)

[Thunderbolt8]

I might be wrong, but isn't this a debug build of 87c, hence should be slower?hm right. its much better with the normal .87 build, but still not as good as it used to be.

[Devrim]

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

[fairchild]

Thanks as always for continuing to improve MadVR madshi. Latest official version for me is just showing a black screen when using it's deinterlacing (using software decoding with Lav Filters). Also the screen doesn't close when I close the playing file/movie in MPC-HC while in FSE mode. Only when I enable Use a separate device for presentation does it work again like it did. I guess I don't recall if this was the behavior in previous version, as I always enable this option. Anyway I simply disabled deinterlacing and enabled YADIF in LavFilters while you iron out that bug. These are the settings I use and it's working fine at first glance with 0.87.0

MadVR settings

Disable deinterlacing

Use a separate device for presentation

Disable Desktop Composition

disable ALL trade quality for performance options

using chroma upscaling: lanczsos 3 (AR), image upscaling: lanczsos 3 (AR)

Also I am not using debanding.

[kazuya2k8]

Tried the official 0.87. Looks like working faster even with debanding ON. But turning on anything related to NNEDI3 gives me blank or freezed frame output.

Using GTX 660 factory OC'd with latest driver.

[namaiki]

My apologies if this has already been reported:

Testing Intel HD4000 with Nvidia 650M (Optimus). I have not replaced C:\Windows\SysWOW64\opencl.dll as was previously suggested. The 650M is selected for use. I have the latest drivers installed (ForceWare 327.02, Intel 3345). I tested with madVR87d. OpenCL error diffusion is not enabled for the below screenshots, but when it is enabled it seems to produce a black image.

How the image normally looks:
http://i43.tinypic.com/10xrlue.jpg

NNEDI Chroma enabled:
http://i43.tinypic.com/2yugkck.jpg
(appears to have a green tint)

NNEDI Chroma and Image doubling both enabled:
http://i40.tinypic.com/2zi0wfd.jpg

NNEDI Image doubling enabled:
http://i42.tinypic.com/4s04th.jpg
(image appears dark and perhaps missing a layer?)

DXVA scaling and nnedi doubling combined does seem to produce a correct image:
https://www.mediafire.com/?mgvmhdovgys5dfr

Note: Video was scaled from 1280x720 to 1920x1080 for 1.5x NNEDI to be enabled.

Logs for the above: https://www.mediafire.com/?wz32v37zzd3u9bj

Original 0.87 was crashing MPC-HC but 87a-d don't.

If I disable Optimus and use the Intel HD4000, the colors are not affected as such but the Intel GPU is too slow for realtime playback.

[alquimio_125]

InstallFilter.exe crashes when clicking install.bat
It actually finishes installing (MadVR.ax Registered Successfully) but when existing InstallFilter.exe it crashes "(InstallFilter.exe Has Stopped Working" appears.

I have an idea why this could be happening. Doesn't occur on my PC, though. In any case I think installation succeeded, so don't worry too much about this.



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.

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

[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

[Salad]

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

AMD Radeon HD 6670, Windows 8.1 x64.

[QBhd]

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

GPU: R9 270X (DirectCU II TOP, factory OC)
Target Rectangle: 1024x768 (rectangular pixel 720p Plasma, circa 2007)
Chroma: NNEDI3 (32 neurons)
Image Downscaling: Lanczos 4 AR
Deband Default: Medium
Smooth Motion: OFF (I use ReClock with 60Hz & 72Hz refresh rates)
Trade Quality: ALL unchecked
General Rendering settings: FSE, desktop comp disabled, seperate device for presentation.

I just watched a few hours of 720p TV and it was AMAZING! the only fear I have is the 18ms render time. Which is just above the 13.8889ms VSync interval.... I can't remeber if that is a bad thing or not. I know it would be bad if it was more than the frame interval, just not sure about the vsync interval.

The above setup is demanding, it gobbles up 41% of my GPU on 720p content.

Keep up the great work madshi

QB

[kasper93]

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

No wonders here, NV is terrible when it comes to OCL :)

@madshi

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 ;)

[zero9999]

0.87c error diffusion dithering works here with Nvidia GT450m Optimus. Maybe it's using the Intel iGPU for openCL?

Edit: turns out the nvidia drivers reset the optimus settings to use the iGPU.so yeah, using the dGPU it's broken here as well

[LigH]

@ James Freeman:

Sorry if I sounded annoyed ... sometimes I am more than I wish to have been the next day.

Well, okay, it may have other implications while reencoding (e.g. provoking more quantization artefacts) to try to make the image "sharp, sharper, sharpest", compared to displaying it only. At least, sharpening is always artifical. It never substitutes real resolution. After all it's a matter of personal taste how much looks how convenient, considering the ringing (edge halos) and aliasing (detail flickering).

[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

[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-articles/Pages/AMDCatalyst13-9WINReleaseNotes.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]

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 (http://www.station-drivers.com/index.php/forum/news/354-intel-hd-graphics-15-33-12-3383-whql) (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]

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]

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:
http://i.imgbox.com/IV9N9nPf.png

0.87b & 0.87c no flushing:
http://i.imgbox.com/KhbrmOgX.png

0.87.0 & 0.87a no flushing:
http://i.imgbox.com/DmnVd8ZY.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.

[truexfan81]

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]

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]

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.

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.

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

madVR 0.87d OCL Dither debug logs (https://www.mediafire.com/?cgu37g22t21u8r1)
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?

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.

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

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

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

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.

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.

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.

I think that should actually be:
HKEY_CURRENT_USER\Software\madshi\madVR\BorderColor
Yes, thanks.

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 (http://www.station-drivers.com/index.php/forum/news/354-intel-hd-graphics-15-33-12-3383-whql) (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.

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.

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.

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

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.

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

Latest official version for me is just showing a black screen when using it's deinterlacing
Known problem. Already fixed in a test build.

turning on anything related to NNEDI3 gives me blank or freezed frame output.
black picture with openCL
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.

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.
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.
So presumably noee, cca, Qotscha, and myself are all having performance issues on different brands of GPUs for the same reason.
installed .87d, didnt change anything, tested an AVC 60p sample, got framedrops which hasnt happened before. and black picture with openCL
On my system, 0.87.0 has completely killed video playback (black screen at all times and player crashes on exit).
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
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).

0.87 gives and mpc-hc crash error when starting a video (latest nightly)
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]

Change it to (srcInterlaced) && (!filmMode) and try again.
Thank you, that did it.
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]

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]

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]

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 (https://www.mediafire.com/?z3td984gw7dd3b5)

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]

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.