madVR - high quality video renderer (GPU assisted)

[madshi]

there is a problem with defining a custom resolution via Custom Resolution Utility.
I use it to force the display to stay at 75Hz. To do so set up a custom resolution and disable the checkbox "Include extension block" on Nvidia hardware.
In windowed mode now madVR reports 75Hz, but Windows still offers only 60Hz resolution. I don't know why this is that way, maybe oddness of Nvidia driver.
The problem is that madVR fails to enter FSE this way. The Nvidia Control Panels reports 75Hz only.
Could you please extend the refreshrate lookup so that madVR can also detect such custom resolutions, making FSE working?
That won't work. I have to tell D3D9 which display mode to use, and it must be a display mode which really exists. The D3D9 API requests it that way, at least for FSE mode.

I'm currently having troubles getting any kind of DXVA2(in LAV) to work in FS as when going from windowed to FSW(with the latest stable build of PotP) the picture is vertically stretched, then after a second the AR is applied and playback finally starts. OTOH with FSE, the backbuffer queues never fill and it's stuttering like hell. Need to run more tests I guess.
I hope you aren't using the old FSE mode, like you did in XP? In newer OSs you should really be using the new FSE mode. I wouldn't recommend to use DXVA2 decoding, unless your CPU is rather weak. I prefer software decoding. Of course DXVA2 deinterlacing is a different topic, it's currently needed for native video content.

I haven't gone through all previous pages yet but it seems that the backbuffer queues problem is being investigated.
No, it's not.

Yes, and when you exit playback madHcCtrl is closed, as would be the normal case of accessing madVR settings outside of playback. My current tray icon setting is "show tray icon on local pc" and "Lan access" disabled.
I switched to a newer NVidia GPU in my dev PC and tried with GraphStudioNext and I can now reproduce the 5 second delay... :) I'll look into that next.

Is it expected for OpenCL dither to increase madVR CPU load significantly when scaling? GPU load also seems to change a lot, depending on output size. Are you dithering after resize rather than prior? It would also seem that GPU load exactly doubles if you enable Smooth Motion on top of OpenCL dither, which I find a bit strange.
Dithering should be one of the very last steps in rendering, after scaling, after smoothmotion.

Dithering reduces the bitdepth of the image, so doing it any earlier defeats its purpose.
^

Random dithering is currently done before drawing the OSD. Error diffusion is done even later, after drawing the OSD. Both is done after scaling and after smooth motion FRC. As nevcairiel said, it must be that way. Of course when using smooth motion FRC, the number of rendered frames increases, so that will drive up error diffusion cost.

I've read somewhere that when using NVidia OpenCL, the CPU consumption goes up because for some reason NVidia OpenCL just works that way. I think the thread waiting for OpenCL to finish its work is probably running at 100%. Don't ask me why. I don't know if this happens with AMD or Intel, too, haven't really tested that.

Maybe I don't understand this correctly, but with NNEDI, what are the chances of upscaling a video by precisely 2x? Does that mean your video would need to be half of the 1920 pixel width (960) to work?
If I understand it correctly, nnedi will double a small video, then whatever scaling method you've selected will take that and stretch it to the target rectangle size. That's just from reading along the past few pages.

If you double past the target size, then the downscaling method will kick in.
^

Hopefully at some point someone can explain how to setup a profile+script to use NNEDI to say just do less than 720p content (not sure if it benefits 720p to 1080p) to get max image quality. I guess the purpose of NNEDI is to get even more quality out of your image/chroma scaling when going from say a DVD which is at 720x480 to a 1920x1080 screen.

Edit: kinda figured it out a bit, for lower res media, then can use the following options which bypasses using NNEDI for 720p and up content. (since difference is probably sooooo minute anyway)

use NNEDI3 to double luma if scaling 2.0x 64 neurons (bypasses 720p)
use NNEDI3 to quadruple luma if scaling is 3.0x 16 neurons
You can either do that, or use profiles if you want even more control over which algorithm is used when.

You've said that you recommend we select a "cheap" upscaler algorithm such as Lanczos3 AR when NNEDI3 is selected. What happens when NNEDI3 is not in use and only Lanczos3 AR is used to upscale Luma? In that case wouldn't you recommend it switches to another algorithm, such as Jinc3 AR, automatically?
You can do that with profiles, if you want.

-------

I've found a bug in v0.87 which could explain some of the new problems. So all of you who have D3D9 failures or performance regressions, please check this test build:

http://madshi.net/madVR871a.rar

[madshi]

I have to say i love this profile stuff. :D

Profiles for Scaling, profiles for deband/deinterlace.
Now i can watch any file i want to without having to ever manually change settings.

madshi thank you so much :-)
Glad you like it... :)

[huhn]

I've found a bug in v0.87 which could explain some of the new problems. So all of you who have D3D9 failures or performance regressions, please check this test build:

http://madshi.net/madVR871a.rar

freeze with file change in fullscreen exclusive is fixed for me.

the report from Today 09:47 is fixed too.

but video-film mode switch with refresh rate change done through a hot key results in a black screen now.

only happens from video to film mode and only about 50 %

[madshi]

Some progress, at least, thx for the quick feedback. And you can confirm that the remaining issue definitely didn't occur in v0.86.11 *at all*, is that correct?

[huhn]

Some progress, at least, thx for the quick feedback. And you can confirm that the remaining issue definitely didn't occur in v0.86.11 *at all*, is that correct?

with 86.11 the player crashes now i'm sure this didn't happen before but is a new player version always after 3 switches. or even after the first one and that defiantly didn't happen before
this never happen yesterday when when 86.11 settings where reseted after downgrading from 87.1
87.1 instant crash
87.1a blackscreen
86.11 player crash

i try it again after clearing the registry and restarting the pc but at the moment is looks like a old bug in a new form.

[romulous]

Apologies if this is already a known issue, but video playback fails with all 0.87.x versions so far when I enter fullscreen mode on a second display (not using any of the new features of 0.87.x, and FSE mode disabled). Returning to 0.86.11 makes it work again.

I've found a bug in v0.87 which could explain some of the new problems. So all of you who have D3D9 failures or performance regressions, please check this test build:

http://madshi.net/madVR871a.rar

Hi madshi,

This new build finally fixes my problem. However, when you fullscreen with madVR (FSE disabled), there is a delay in playback (a slight pause) before playback continues. This delay is in 0.86.11 as well - but I think it is a slightly longer delay in this new 0.87 build. So the problem is fixed, but I don't think performance is back to 0.86.11 levels as yet.

[DragonQ]

I've found a bug in v0.87 which could explain some of the new problems. So all of you who have D3D9 failures or performance regressions, please check this test build:

http://madshi.net/madVR871a.rar
None of these fixes the performance regression. :(

[leeperry]

I hope you aren't using the old FSE mode, like you did in XP? In newer OSs you should really be using the new FSE mode. I wouldn't recommend to use DXVA2 decoding, unless your CPU is rather weak. I prefer software decoding. Of course DXVA2 deinterlacing is a different topic, it's currently needed for native video content.
I'm of course using the new rendering path :)

Well, I'm confused because Nev told me that DXVA2 works even better than CUVID (http://forum.doom9.org/showpost.php?p=1649403&postcount=16207), I was hoping to get the same kind of performance with DXVA2CP off this HD7850 with mVR as I was getting with CUVID....that'll be a no-go? :(

Software decoding works perfectly but I would really rather have the GPU taking care of video decoding as I bought a low-end CPU expecting to be able to use GPU video decoding.

If DXVA2 really cannot provide the same kind of performance as CUVID, I guess I might switch teams again....this said, IME Asus/nvidia graphic cards are dead silent and this cheap HD7850 (http://www.vtx3d.com/products_features.asp?id=160) is already getting on my nerves as the rest of the rig is whisper quiet, I'll try to make a custom fan speed curve as the fan is fairly capable.

No, it's not.
Oh, well then I'll try to come back with screenshots. Are the backbuffer queues supposed to fill up equally whatever NNEDI is enabled or not?

[romulous]

Hi madshi,

This new build finally fixes my problem. However, when you fullscreen with madVR (FSE disabled), there is a delay in playback (a slight pause) before playback continues. This delay is in 0.86.11 as well - but I think it is a slightly longer delay in this new 0.87 build. So the problem is fixed, but I don't think performance is back to 0.86.11 levels as yet.

Scrub this - the delay is dependant on the file being played. I tested with an AVI file on 0.87 and a MOV file on 0.86.11 - and when I check that AVI file with 0.86.11, that delay is longer than with the MOV file, and seems to be about the same as this new 0.87 build.

I do note however that if I enable the nnedi3 box, the problem returns with this fixed build (fullscreen to second display, playback halts and player goes to 100% CPU). The only difference this time being previously, I could still close the player as normal. Now I can't - task manager intervention is required.

So basically if I used the fixed build with no changes to my 0.86.11 configuration, everything is ok. When I start enabling the new 0.87 options, that is when things start to break.

[madshi]

i try it again after clearing the registry and restarting the pc but at the moment is looks like a old bug in a new form.
Ok, good. I'm mostly interested in *new* bugs at the moment.

None of these fixes the performance regression. :(
Ok. Will have to look at that next.

Well, I'm confused because Nev told me that DXVA2 works even better than CUVID (http://forum.doom9.org/showpost.php?p=1649403&postcount=16207), I was hoping to get the same kind of performance with DXVA2CP off this HD7850 with mVR as I was getting with CUVID....that'll be a no-go? :(
I don't know, I don't use DXVA decoding, never did. Copyback has been a problem with older AMD generations, but it's supposed to be improved in 7xxx. Have you tried native DXVA2 decoding instead? Of course you use forced film mode that way. FWIW, I've *always* said that I prefer and recommend software decoding... ;)

Software decoding works perfectly but I would really rather have the GPU taking care of video decoding as I bought a low-end CPU expecting to be able to use GPU video decoding.
As long as the CPU can handle the decoding load, what's wrong with using software decoding? Or do you have AviSynth scripts you want to run on the CPU?

If DXVA2 really cannot provide the same kind of performance as CUVID, I guess I might switch teams again....
However, OpenCL performance is better with AMD.

Oh, well then I'll try to come back with screenshots. Are the backbuffer queues supposed to fill up equally whatever NNEDI is enabled or not?
If your GPU is fast enough then I would expect all queues to fill up nicely. That said, the whole OpenCL stuff in madVR is just a couple of days old, so there's very little experience how it affects the various queues.

I do note however that if I enable the nnedi3 box, the problem returns with this fixed build (fullscreen to second display, playback halts and player goes to 100% CPU). The only difference this time being previously, I could still close the player as normal. Now I can't - task manager intervention is required.

So basically if I used the fixed build with no changes to my 0.86.11 configuration, everything is ok. When I start enabling the new 0.87 options, that is when things start to break.
Maybe I could say something if I knew which GPU/OS you were using? Anyway, my priority right now is on making the "old" features work alright again. Only after that I'm ready to polish the OpenCL stuff...

[huhn]

I'm of course using the new rendering path :)

Well, I'm confused because Nev told me that DXVA2 works even better than CUVID (http://forum.doom9.org/showpost.php?p=1649403&postcount=16207), I was hoping to get the same kind of performance with DXVA2CP off this HD7850 with mVR as I was getting with CUVID....that'll be a no-go? :(

Software decoding works perfectly but I would really rather have the GPU taking care of video decoding as I bought a low-end CPU expecting to be able to use GPU video decoding.

If DXVA2 really cannot provide the same kind of performance as CUVID, I guess I might switch teams again....this said, IME Asus/nvidia graphic cards are dead silent and this cheap HD7850 (http://www.vtx3d.com/products_features.asp?id=160) is already getting on my nerves as the rest of the rig is whisper quiet, I'll try to make a custom fan speed curve as the fan is fairly capable.


Oh, well then I'll try to come back with screenshots. Are the backbuffer queues supposed to fill up equally whatever NNEDI is enabled or not?
if you got a intel cpu try quicksync it's faster than nvidia dxva and worlds faster than amd dxva.

and nev is totally right he meant dxva2 on a nvidia card.
cuvid is very useful on old nvidia cards but in newer cards both use the same "chip" so cuvid is kinda like dxva copy back just puts your card in highest power state wasting power like a pro.
and dxva is a dead end you can't use this for newer codecs like h265 or vp9.

@ the new backbuffer settings they don't make sense to me.
the max backbuffer valve you can get is always gpu queue -1 at default it is 8 gpu and 8 backbuffer so the backbuffer stays at 6-7 at best.

but these are only my observations with intel, nvidia and amd.

[madshi]

@ the new backbuffer settings they don't make sense to me.
the max backbuffer valve you can get is always gpu queue -1 at default it is 8 gpu and 8 backbuffer so the backbuffer stays at 6-7 at best.

but these are only my observations with intel, nvidia and amd.
Which new backbuffer settings do you mean? Are you talking about windowed or FSE mode? In FSE mode you don't specify the number of backbuffers, but you specify the number of prepresented frames. And that is the only default value I changed in v0.87, IIRC. So I'm confused with what you mean...

-------

@DragonQ, and everyone else who's having performance problems. Does this build help?

http://madshi.net/madVR871b.rar

Is it correct to say that all performance issues have to do with DXVA deinterlacing or DXVA decoding somehow?

@cyber, this should also fix the settings delay.

[huhn]

Ok, good. I'm mostly interested in *new* bugs at the moment.
at the moment i can't get 86.11 running properly.
i get 40 ms render time with default settings with a 1080p23 source on a 1080p screen. so i broke it and my observations are "useless" atm.

i didn't bother you until i now if it's new bug or a old one.

[James Freeman]

but video-film mode switch with refresh rate change done through a hot key results in a black screen now.

only happens from video to film mode and only about 50 %
87.1b

Happens here too.

When changing to Film mode & automatic refresh rate the screen/window turns black.
When force disabling Deinterlacing (in Film mode, after the refresh changed), the video appears again.
BUT, when I manually change the refresh to 72Hz in windows, then open MPC and change to Film mode, everything is OK.


Render times (1080p24) & 87.1b:

Average Stats,
rendering 2.24ms
present 0.08ms

Max Stats:
rendering 2.50ms
present 0.15ms

Full buffers on everything.

I have never had speed issues with any of the builds from 86.11 to 87.1b.

[nevcairiel]

Well, I'm confused because Nev told me that DXVA2 works even better than CUVID (http://forum.doom9.org/showpost.php?p=1649403&postcount=16207), I was hoping to get the same kind of performance with DXVA2CP off this HD7850 with mVR as I was getting with CUVID....that'll be a no-go? :(

AMDs hardware decoder is rather bad compared to NVIDIA. Its extremely slow.

So while DXVA2CB will work on AMD 7000 series GPUs, it'll not reach the levels of NVIDIA hardware because AMDs decoder is just really slow. It can't even be guaranteed that it can do 60fps properly. LAV can only work with the hardware you have, so while i do favor DXVA2CB over CUVID, that doesn't translate that it will magically be fast on other hardware. :)

[huhn]

Which new backbuffer settings do you mean? Are you talking about windowed or FSE mode? In FSE mode you don't specify the number of backbuffers, but you specify the number of prepresented frames. And that is the only default value I changed in v0.87, IIRC. So I'm confused with what you mean...

you are right the present in advance changed to 8.

but the "rule" max gpu queue -1 = max backbuffer/present is still "true". same rule goes for cpu and ivtc(haven't check the ivtc part for a while).
and that's why i don't get why gpu and present are set to 8.
but this has nothing to do with backbuffer mixed them up sorry. and this normally didn't harm only found problems with settings like these with my intel hd4000 and i think this was a long time ago.

i updated back to 87.1a and this version is working, how can i break a old version...

[huhn]

87.1b

Happens here too.

When changing to Film mode & automatic refresh rate the screen/windows turns black.
When force disabling Deinterlacing (in Film mode, after the refresh changed), the video appears again.
BUT, when I manually change the refresh to 72Hz in windows, then open MPC and change to Film mode, everything is OK.


Render times (1080p24) & 87.1b:

Average Stats,
rendering 2.24ms
present 0.08ms

Max Stats:
rendering 2.50ms
present 0.15ms

Full buffers on everything.

can you plz try this with 86.11 my version is crashing now and render times are about 10 ten higher than normal

[omarank]

Hi Madshi

I just tried the latest test build of madVR (madVR871b). As others have reported I too see a regression in performace while playing interlaced videos as compared to v0.86.11. At the moment I am not using any of the new features, not even debanding though debanding works on my system and I find it very impressive.

I have encountered one minor bug in the new release which I guess hasn't been reported. When I press the shortcut keys for <chroma upscaling algorithm - set to "Jinc">, it uses NNEDI3 algorithm and I see a green screen.

I have a GTX260 and I am using v332.21 drivers.

[ryrynz]

HD3000 on 8.1 with 3347 drivers using 0.87.1, when fullscreen exclusive is enabled and not ticking 'use separate device for presentation' and after transitioning to next file after playback I get a black screen.

The black screen is locked and I can't go into windowed mode without bring up Task Manager. Once doing so I can play the video fine in windowed mode, entering fullscreen again will show a frozen picture, audio plays fine.
Entering windowed mode and fullscreen again and FSE mode activates with no issues and video plays fine.

Ticking 'use separate device for presentation' fixes this issue, no issue with deband build 14.

[madshi]

87.1b

Happens here too.

When changing to Film mode & automatic refresh rate the screen/window turns black.
When force disabling Deinterlacing (in Film mode, after the refresh changed), the video appears again.
BUT, when I manually change the refresh to 72Hz in windows, then open MPC and change to Film mode, everything is OK.
As I said, I'm mostly only interested in *new* bugs atm. So please double check whether this problem does not occur in v0.86.11. If it also occurs in v0.86.11 then it's an old bug, which you can enter into the madVR bug tracker, but I'll not look at it right now. Just want to make sure that v0.87.x doesn't contain new bugs compared to v0.86.11 right now.

but the "rule" max gpu queue -1 = max backbuffer/present is still "true". same rule goes for cpu and ivtc(haven't check the ivtc part for a while).
No, it's not true. E.g. when playing 24fps content @60Hz in FSE mode, you can easily have a render queue of 7-8/8 and a present queue of 11-12/12.

[James Freeman]

can you plz try this with 86.11 my version is crashing now and render times are about 10 ten higher than normal

Rendering times are exactly the same or a little longer with 86.11 (87.1b is faster) with 1080p24.

But changing to film mode with refresh change (86.11) crashes mpc-hc.exe, But 87.1b only blackens the image which is better.
Madshi, Its an OLD bug.

Overall, 87.1b is more stable and faster with my system.

[madshi]

I just tried the latest test build of madVR (madVR871b). As others have reported I too see a regression in performace while playing interlaced videos as compared to v0.86.11.
So the 871b build did not help at all compared to the official v0.87.1?

I have encountered one minor bug in the new release which I guess hasn't been reported. When I press the shortcut keys for <chroma upscaling algorithm - set to "Jinc">, it uses NNEDI3 algorithm and I see a green screen.
Thanks, confirmed.

HD3000 on 8.1 with 3347 drivers using 0.87.1, when fullscreen exclusive is enabled and not ticking 'use separate device for presentation' and after transitioning to next file after playback I get a black screen.
Try the 871a or 871b test build.

[ryrynz]

Tried the a build. Fixed.

[James Freeman]

I just tried the latest test build of madVR (madVR871b). As others have reported I too see a regression in performace while playing interlaced videos as compared to v0.86.11.

So the 871b build did not help at all compared to the official v0.87.1?

I disagree.
87.1b works much faster than even 86.11.

http://www.mediafire.com/convkey/8663/7bik5t1l56fiae6fg.jpg

[romulous]

Maybe I could say something if I knew which GPU/OS you were using? Anyway, my priority right now is on making the "old" features work alright again. Only after that I'm ready to polish the OpenCL stuff...

Just to be clear - I haven't enabled the OpenCL stuff. I have a NVIDIA card, and I know madVR's OpenCL does not work on NVIDIA so I haven't bothered with it. This is simply ticking the box in 'Image Doubling' section.

Anyway, NVIDIA GTX 660Ti, Win 7 64bit.

[DragonQ]

I disagree.
87.1b works much faster than even 86.11.
<snip>
You have Smooth Motion off (since you're playing a 30i file at 60 Hz). As I said a couple of posts ago, the performance regression is far worse with interlaced video when using Smooth Motion for me, so what happens when you enable it? Also, that's a ridiculous difference in performance, are you sure your settings haven't changed?

@madshi: 0.87.1b doesn't fix the issue.

When Smooth Motion is off the only difference between 0.86.11 and 0.87.1b is that "split" takes ~50% more time. With Smooth Motion on though, "split", "deinterlace", and "rendering" all take ~100% more time, and "present" takes ~200% more time.

[James Freeman]

This is simply ticking the box in 'Image Doubling' section.

Image Doubling is new to v87 OpenCL feature.
So don't use it with NVIDIA (yet).

[madshi]

I disagree.
87.1b works much faster than even 86.11.
Wow! I wish it would be this way for everybody... :D

Just to be clear - I haven't enabled the OpenCL stuff. I have a NVIDIA card, and I know madVR's OpenCL does not work on NVIDIA so I haven't bothered with it. This is simply ticking the box in 'Image Doubling' section.

Anyway, NVIDIA GTX 660Ti, Win 7 64bit.
Image doubling / NNEDI3 does use OpenCL internally. I know, the settings dialog doesn't make it clear.

[Thunderbolt8]

DragonQ, your GT 430 is quite old by now, maybe thats where the big difference comes from.

[nevcairiel]

I disagree.
87.1b works much faster than even 86.11.

These numbers look unrealistic. I seriously doubt their accuracy.

[romulous]

Image doubling / NNEDI3 does use OpenCL internally. I know, the settings dialog doesn't make it clear.

Yes - the settings dialog is a mess, it certainly doesn't even hint at it, let alone make it clear. :mad:

Bad news - the 87.1b version breaks the previous fixed build. Fullscreening to second display is now broken again. This is without nnedi3 ticked of course.

[leeperry]

Well, I left "ITC Processing" enabled in the HD7850 drivers and that would supposedly do a lot of wonderful things on FS videos...maybe that's my problem, will run more tests.

Have you tried native DXVA2 decoding instead?

Yep, either flavor of DXVA2 seems equally flaky and checking "use OpenCL to process DXVA2" in mVR doesn't help.

As long as the CPU can handle the decoding load, what's wrong with using software decoding?

Well, CUVID worked beautifully IME and I planned on relying on hardware decoding for high bitrate H264/VC1 and I do run a bunch of VST plugins in ffdshow audio, but at the end of the day what matters is the real-world power consumption...I guess I'll have to run a bunch of tests using a wattmeter.

However, OpenCL performance is better with AMD.
Yep, I've seen that and I think I really like the new error diffusion dithering :devil:

If your GPU is fast enough then I would expect all queues to fill up nicely. That said, the whole OpenCL stuff in madVR is just a couple of days old, so there's very little experience how it affects the various queues.
Apparently, HWinfo32 is far more capable and accurate at showing the GPU/VRAM load than GPU-Z (http://www.imagebam.com/image/4ad33c304000291) so I'll check it out and will get back to you on this one.

AMDs hardware decoder is rather bad compared to NVIDIA. Its extremely slow.
Fair enough, thanks for the detailed explanation.

if you got a intel cpu try quicksync it's faster than nvidia dxva and worlds faster than amd dxva.
so I can use Intel's Quicksync for video decoding and output its result on the HD7850? Neato, will give it a shot.

[James Freeman]

you have smooth motion off (since you're playing a 30i file at 60 hz).

these numbers look unrealistic. I seriously doubt their accuracy.

Edit: I forgot to turn off Debanding in 87.1b, which means its even faster than whats in this image. :D

http://www.mediafire.com/convkey/864d/kbgapl1ypc3aw7cfg.jpg

[Thunderbolt8]

testing the ayaka MSSL12.ts clip for performance (mpeg2, 1440x1080 upscaled to 1080p; 29,97 fps), 0.871b is a little faster for me than 0.8611

0.8611:
without deinterlacing: 17.20ms
with deinterlacing: 17.50ms + deint: 3.30ms


0.871b:
without deinterlacing: 16.00ms
with deinterlacing: 16.90ms + deint: 2.95ms

[huhn]

Wow! I wish it would be this way for everybody... :D

these are all screens from 86.11

http://abload.de/img/86.11deinthighquene2ujf3.pnghttp://abload.de/img/86.11idintlowqueneh8kgv.pnghttp://abload.de/img/86.11ivtchighquenemek4e.pnghttp://abload.de/img/86.11ivtclowquene8aj9h.png

ivtc doesn't really care about queues but deinterlacing... how to judge performance this way.

even if amd in this case is changing the deinterlacing mode because the number of buffered frames is to low why are the rendertimes affected?

so I can use Intel's Quicksync for video decoding and output its result on the HD7850? Neato, will give it a shot.you need a fake display or windows 8 for this. and your mainboard must have support for igpu. every mainboard with a vga dvi dp oder hdmi connector can do it and i'm not sure if all intel gpu can do quicksync all ix cpu for sure.

[hannes69]

Just tested 87.1b on AMD HD4550 (quite old, quite slow). Everything is working fine so far. I didn´t test everything (e.g. deinterlacing), but for my typical usage scenario everything works. No black or bluescreens, freezes, stuttering or other unwanted behaviour. I unticked every box in trade quality, ticked the opencl stuff. I tried NNEDI3 for chroma upscaling, it works. I only play 720p without scaling on a projector, by using software decoding, debanding (works great!), involving a 3DLUT and using Bicubic AR chroma upscaling without the need of smoothmotion (I have accurate refresh rates by custom Powerstrip resolutions) I get 70% GPU usage. So ALL features of recent madvr version concerning quality are still usable on my good old GPU. Clearly there is no more headroom left for playing back 1080p or scaling other than native resolution, but for my needs it´s great!
Great work madshi, I had to give a positive feedback right at this time, when 9 out of 10 users report problems at the moment.
Forget about NVIDIA, just define AMD or Intel as a system requirement for using madvr :D

[omarank]

So the 871b build did not help at all compared to the official v0.87.1?


The performance is better in 871b as compared to the official v0.87.1. In the official version, I have performance issues with some progressive videos too which have been fixed in 871b.

I disagree.
87.1b works much faster than even 86.11.


On my system, I am not able to see any performance improvement with 871b for interlaced videos.

http://www.mediafire.com/view/jvcfrevqmvir8r4/COmparison.jpg

[noee]

madshi:
With my VC1 1080i test file, .87b makes substantial perf gains for deint:

DXVA Native (FSE Mode):
.86: ~7.3ms, full queues, perfect playback
.871: ~18.2ms, starved render/backbuffer, many drops
.871b: ~4.10ms, full queues, perfect playback

DXVA CB (FSE Mode):
.871: ~7.5ms, full queues, perfect playback
.871b: ~2.75ms, full queues, perfect playback

HD6570

[DragonQ]

DragonQ, your GT 430 is quite old by now, maybe thats where the big difference comes from.
All of this testing is on my laptop using an Intel HD4000, as I've said several times (although I understand if you haven't been following the past dozen pages). I don't/can't use MadVR on my HTPC since MediaPortal doesn't support it.

One way to fix the problem is to use CUVID (on my NVS 5200M), since that handles the deinterlacing and then all MadVR has to do is mix frames and downscale on the HD4000 (75% load, same as with 0.86.11). I imagine the hugely increased stat times I'm seeing is due to the GPU being maxed out and thus not doing everything asked of it quickly enough when deinterlacing and smooth motion are both being used. The problem is likely a smaller performance regression that pushes the load from 85-90% (0.86.11) to above 100% (0.87.1b). I can't imagine the fact I have Optimus is an issue, since when the decoder is set to anything but CUVID the nVidia card has 0% load (and thus is presumably asleep).

[huhn]

These numbers look unrealistic. I seriously doubt their accuracy.

sorry but i got the same...

87.1b
normal(high) queue settings (http://abload.de/img/87.1deinthighquenenos37.png)
low queue settings (http://abload.de/img/87.1deintlowquene4rske.png)
for 86.11 see above

edit i have a watch at the hd4000 later maybe a intel only problem?

[cyberbeing]

Random dithering is currently done before drawing the OSD. Error diffusion is done even later, after drawing the OSD. Both is done after scaling and after smooth motion FRC. As nevcairiel said, it must be that way. Of course when using smooth motion FRC, the number of rendered frames increases, so that will drive up error diffusion cost.

I've read somewhere that when using NVidia OpenCL, the CPU consumption goes up because for some reason NVidia OpenCL just works that way. I think the thread waiting for OpenCL to finish its work is probably running at 100%. Don't ask me why. I don't know if this happens with AMD or Intel, too, haven't really tested that.

Okay, thanks for clarifying. Next question would be if there is a way to disable OpenCL dither with Smooth Motion via profiles? It seems we are missing a boolean value for 'is Smooth Motion active'? Would it also be possible to add a codec rules for image formats. If I had a boolean for PNG, I could workaround Issue #142 on your bug tracker.

madVR871b
...
@cyber, this should also fix the settings delay.

Confirmed

[madshi]

Because of the GPU performance requirement for error diffusion and the slight improvement in quality with it being done on the CPU, what's the chances of this ever being an option that could be enabled on the CPU in MadVR?
Not a chance, because it would require heavy copyback operations. Much more so than a DXVA2 decoder does.

I disagree.
87.1b works much faster than even 86.11.
Edit: I forgot to turn off Debanding in 87.1b, which means its even faster than whats in this image. :D
What is weird is that in one of your images the max numbers are smaller than the average numbers. Not sure how that could happen.

These numbers look unrealistic. I seriously doubt their accuracy.
I agree that such a big difference looks suspicious. However, I did do one important change in v0.87.0 (see also changelog): In all older versions sometimes when the backbuffer queue was full, rendering performance slowed down dramatically. IIRC, some users reported that they cut the rendering queue size down so that the backbuffer queue never gets full to solve this problem, or something like that.

I've worked around this problem in v0.87.x simply by telling D3D9 to allocate one backbuffer more than needed. I can imagine that James Freeman runs into the original problem with v0.86.11, so that his rendering times are much worse than his GPU is really capable of. And the workaround in v0.87.x could have solved this issue and thus restored the original/full speed of the GPU. This is just a guess, though, I could be wrong. But it could explain the improvement he's seeing. I did have high hopes for the workaround I added. Had one situation on my PC where I could reproduce the original problem, and the workaround fully fixed it.

these are all screens from 86.11

ivtc doesn't really care about queues but deinterlacing... how to judge performance this way.

even if amd in this case is changing the deinterlacing mode because the number of buffered frames is to low why are the rendertimes affected?
How long did you let rendering run when you made these images? Is it possible that with the bigger queue size the rendering times are only so much worse directly at the start of video playback? Maybe after a couple of seconds they slowly come down and then at some point match the rendering times with smaller queue sizes? (With v0.87.1b at least?)

Just tested 87.1b on AMD HD4550 (quite old, quite slow). Everything is working fine so far. I didn´t test everything (e.g. deinterlacing), but for my typical usage scenario everything works. No black or bluescreens, freezes, stuttering or other unwanted behaviour.
Good to hear - thanks for bringing good news for a change... :)

madshi:
With my VC1 1080i test file, .87b makes substantial perf gains for deint:

DXVA Native (FSE Mode):
.86: ~7.3ms, full queues, perfect playback
.871: ~18.2ms, starved render/backbuffer, many drops
.871b: ~4.10ms, full queues, perfect playback

DXVA CB (FSE Mode):
.871: ~7.5ms, full queues, perfect playback
.871b: ~2.75ms, full queues, perfect playback

HD6570
Looks great! Can you confirm that frame dropping behaviour matches these rendering times, just to be safe? Meaning: Can you actually use even more demanding scaling algorithms now compared to v0.86.11? At least the same, without getting frame drops? I'm not sure how much I can really trust the rendering times, although they're usually at least roughly right.

All of this testing is on my laptop using an Intel HD4000, as I've said several times (although I understand if you haven't been following the past dozen pages). I don't/can't use MadVR on my HTPC since MediaPortal doesn't support it.
Ok. So it seems your performance issue is probably the last one remaining. I'm not sure if you said this in the past already, but does your performance issue only occur when some kind of deinterlacing is involved? You did say it had to do with smooth motion FRC. But does interlacing play any role? DXVA deinterlacing? Or film mode? Both or none? Thanks.

Okay, thanks for clarifying. Next question would be if there is a way to disable OpenCL dither with Smooth Motion via profiles? It seems were are missing a boolean value for 'is Smooth Motion active'? Would it also be possible to add a codec rules for image formats. If I had a boolean for PNG, I could workaround Issue #142 on your bug tracker.
We can look at possible additions to the profile variables once all the other issues are resolved. Please let's delay this until then, though. Generally I'm absolutely open to add further profile variables. Anything that makes sense and doesn't cost performance.

[huhn]

How long did you let rendering run when you made these images? Is it possible that with the bigger queue size the rendering times are only so much worse directly at the start of video playback? Maybe after a couple of seconds they slowly come down and then at some point match the rendering times with smaller queue sizes? (With v0.87.1b at least?)

87.1b is at least awesome just have a look at my posting http://forum.doom9.org/showpost.php?p=1664365&postcount=21948

when i switch from 5/5 to 16/8 it takes about 2 sec and the avg deint are at 2 ms again still worlds better than 86.11.
at first i though i have broken 86.11 again but James Freeman got the same...

and the screens for 86.11 where running for at least 18 sec so no they don't get any better

[madshi]

87.1b is at least awesome just have a look at my posting http://forum.doom9.org/showpost.php?p=1664365&postcount=21948

when i switch from 5/5 to 16/8 it takes about 2 sec and the avg deint are at 2 ms again still worlds better than 86.11.
at first i though is have broken 86.11 again but James Freeman got the same...

and the screens for 86.11 where running for at least 18 sec so no they don't get any better
Yes, but even with 871b your screenshots still show lower rendering times for 5/5 than for 16/8. I'm wondering if these rendering times get nearer to each other if you let the video run for a longer time? You could also zoom in and back out again during playback to reset the average rendering times.

[noee]

Meaning: Can you actually use even more demanding scaling algorithms now compared to v0.86.11? At least the same, without getting frame drops?

Yes, I tested for that too on some SD interlaced video I have. With .86, I could run Jinc3/AR luma no problems at all. Same now with .871b on same interlaced video (GPU load is actually a touch lower, ~8% IIRC), but I didn't actually record the numbers, I just watched for a few minutes and monitored frame drops (of which there were none). Software decoding for this SD testing.

If I try NNEDIx2 for the SD interlaced, I have to drop down to NN/Bilin and 16neurons. It appears I have just reached the limits of this card, unless there is some kind of dramatic perf increase with the next OpenCL driver update from our friends at AMD. ;) I would guess that the OpenCL<>D9D3D interop has room for improvement. Whether or not that translates to more headroom for these older, lowly cards is another question.

[DragonQ]

Ok. So it seems your performance issue is probably the last one remaining. I'm not sure if you said this in the past already, but does your performance issue only occur when some kind of deinterlacing is involved? You did say it had to do with smooth motion FRC. But does interlacing play any role? DXVA deinterlacing? Or film mode? Both or none? Thanks.
Yes, it's definitely only "video mode" deinterlacing that makes this problem manifest itself. It's made dramatically worse when Smooth Motion is on, but like I said above, this might just be a red herring since the GPU is at 100% load and can't cope.

Watching progressive videos and/or enabling film mode results in performance on par with 0.86.11 (or slightly better).

[James Freeman]

Yes, but even with 871b your screenshots still show lower rendering times for 5/5 than for 16/8. I'm wondering if these rendering times get nearer to each other if you let the video run for a longer time? You could also zoom in and back out again during playback to reset the average rendering times.

Thanks for the tip.
Play with the volume (mouse wheel) for instant refresh of everything else.

After a few minutes the stable times are (87.1b 1080i30 SM /On):

Avarage:
Deint 0.46
split 2.94
rendering 3.33
present 0.10

Max Stats:
deint 1.03
split 4.12
rendering 4.06
present 0.16

What is weird is that in one of your images the max numbers are smaller than the average numbers. Not sure how that could happen.

I've taken the photo too fast.
It does not matter, 87.1b still the fastest release yet.

[huhn]

nope 16/8 ~2 ms 5/5 0.65 ms over a min should be more than enough. deinterlacing is and was for all test on automatic. deint starts at 9 ms and falls to 2 ms after some time. but gpu load is at ~35% for both.

but there is one thing that doesn't make sense at first look it's ivtc rendertime they are at ~9 ms and deint is at 4.5 ms...
butthat's simple and makes rendertime kinda worthless because in ivtc made the gpu was at 157/300 mhz - 500/300 mhz so at idle most of the time but with deint it was at max powerstate 850/1300 mhz.

so to compare different version we need the powerstate too...

[madshi]

Ah yes, powerstate. Probably makes sense to fix the powerstate to a specific value (max?) while benchmarking rendering times...

[pie1394]

On my HTPC, 0.87.1b is improved on the GPU deinterlacing performance although it is not on pair with 0.86.10. You have done a good job to restore some lost performance. :D

[720x480i60]
0.86.10 : 0.83 ms
0.87.1: 1.64 ms
0.87.1b: 1.38 ms

[1440x1080i60]
0.86.10 : 1.44 ms
0.87.1: 4.21 ms
0.87.1b: 2.12 ms

Note the average number is not always measured the same, but still observed with the similar values on repeated tests.

For my HD7970, it always seems to go up to 925 MHz from 300MHz with madVR playback. The only difference is the fan speed level under different GPU loading. :p


--
Core i5-3570K + Z77 + dual-ch DDR3-2400 + HD7970@925MHz Catalyst 13.12 + Win7x64SP1 + MPC-BE 1.3.0.3 + LavFilter 0.60.1 (DXVA)