madVR - high quality video renderer (GPU assisted)

[markanini]

I am forced to restart MPC-HC to watch a new video when NNEDI3 doubling is enabled, otherwise I get a black screen. HD7770 driver v14.2 beta.

[scollaco]

More noob questions from me: I just wanted to clarify something calibration and pc levels/tv levels...

Right now I've setup the following:
1) My PC is set to output RGB(0-255) PC levels using the registry hack tool on all refresh rates.
2) I set MadVR's source input level to TV levels (autodetect)
3) I set MadVR's output level to PC levels
4) I set my projector to accept HDMI expanded (PC levels)

First question:
Is this is the cleanest way for sending the video signal to madVR?

Second question:
When I had tried to calibrate, I don't see the bars below black and above white..like they are clipped. Which seems fine to me...but should I be calibrating with source input at PC levels or is it fine to calibrate to this clipped information...which method is preferred ?

If this has been discussed before I apologize...I couldn't find it searching the thread.

[kasper93]

@madshi:

@alexmarsev noticed that in >= v0.87.5 not all resources are properly freed. Looks like old threads are not terminated. You can easily reproduce by reloading movie multiple times (CTRL+E in MPC-HC) https://dl.dropboxusercontent.com/s/2slh5k3g8sucgye/mpc-hc_madvr_can_has_more_threads.png

(additionally memory consumption is increased slightly on every reload, but this is most likely cause by very same thing)

[turbojet]

Originally Posted by turbojet View Post
madshi: Is overlay being at least 16 shades(?) darker than window and FSE mode over nvidia svideo an issue that can be corrected by madvr?
You should fix it by creating custom resolutions in the NVidia control panel for all modes you're interested in. The key problem is that seemingly in windowed and FSE mode NVidia does violence to madVR's output. Of course it would be possible for me to offer different settings for Overlay mode compared to windowed/FSE mode, but that's not really a good idea. Because if you get different levels in Overlay mode that just proves that windowed/FSE modes are broken for you. And "broken" means you get suboptimal quality with banding artifacts etc.

Custom resolution is disabled in nvidia cp when that display is selected, cru doesn't see the display. Shouldn't overlay be following what the device properties are set to in madvr? On dvi and hdmi outputs it does but nvidia svideo overlay seems stuck on limited range and ends up double clipping even if madvr is set to full range.

[noee]

Interesting. So this really did fix the problem?

Argh...I just lost my whole long post, but short answer is "Yes". lol, did you just rename the lib or build it with no changes? Seriously, I can reproduce it from 87.6 where all is well to 87.7 where it flashes on every click in the primary screen and the "b" which it now works again as expected.

I did notice that MC19 shows two madHCCtrl.exe processes under MediaCenter19, don't recall ever seeing that before.

Edit, my sig is wrong, I'm on CCC14.2B and b122 of MC19, again, playback on secondary.

[madshi]

Odd, my presentation glitches and dropped frames issue have disappeared (with current and previous madVR version).
I haven't changed much recently, but at least the Nvidia driver (now 335.23).
The only thing I have to do now is raising GPU queue size to 16 (or at least a higher value than 8) for debanding and using non DX11 Compute dithering for 4k video (670 is too slow with expensive scaling algorithms).
Good to hear!

I am forced to restart MPC-HC to watch a new video when NNEDI3 doubling is enabled, otherwise I get a black screen. HD7770 driver v14.2 beta.
Doesn't happen here. But I'm not using v14.2. Don't know if it has to do with that or not.

1) My PC is set to output RGB(0-255) PC levels using the registry hack tool on all refresh rates.
2) I set MadVR's source input level to TV levels (autodetect)
3) I set MadVR's output level to PC levels
4) I set my projector to accept HDMI expanded (PC levels)

First question:
Is this is the cleanest way for sending the video signal to madVR?
You could also set madVR output to TV levels and your projector to standard (TV levels). Doesn't make much of a difference. I like using PC levels, though, because that way both video rendering and desktop/applications will look alright.

When I had tried to calibrate, I don't see the bars below black and above white..like they are clipped. Which seems fine to me...but should I be calibrating with source input at PC levels or is it fine to calibrate to this clipped information...which method is preferred ?
That's as expected, when using PC levels. Of course you could calibrate with madVR and your projector set to TV levels, but I'm not sure if that's worth the effort. But I'm not the expert on calibration, so I can't say for sure.

@alexmarsev noticed that in >= v0.87.5 not all resources are properly freed. Looks like old threads are not terminated. You can easily reproduce by reloading movie multiple times (CTRL+E in MPC-HC) https://dl.dropboxusercontent.com/s/2slh5k3g8sucgye/mpc-hc_madvr_can_has_more_threads.png

(additionally memory consumption is increased slightly on every reload, but this is most likely cause by very same thing)
Good find - thanks! Seems that I didn't release the DirectCompute device properly, due to a lower/upper case type error... :o This will be fixed in the next build.

Shouldn't overlay be following what the device properties are set to in madvr? On dvi and hdmi outputs it does but nvidia svideo overlay seems stuck on limited range and ends up double clipping even if madvr is set to full range.
I'm confused. Your earlier reports led me to believe that Overlay outputs 0-255 on your PC and windowed/FSE outputs 16-235. Is that not correct? Also at one point I think you said this was all dependent on the refresh rate used, IIRC? What you're saying now sounds totally different. I can't really help if your reports change so much all the time. I don't know, anymore, what the problem is or what it isn't.

short answer is "Yes". lol, did you just rename the lib or build it with no changes?
No, I did a change, just didn't expect it to make a difference. But then it was the only change that made sense. Anyway, good to hear that it helped.

I did notice that MC19 shows two madHCCtrl.exe processes under MediaCenter19, don't recall ever seeing that before.
madHcCtrl is also used as a helper process to restore the original display mode, if you're using the madVR display mode switcher, or to restore the original GPU gamma ramps, if you let madVR clear those. This is done by using madHcCtrl as a helper process because if I let madVR restore these things, and if then the media player crashes or freezes, nobody will restore the original settings, anymore. Letting madHcCtrl do the restoring makes this all much more reliable. Basically you can even terminate the media player via taskmanager. The madHcCtrl helper process will notice that the media player process went down and will thus automatically restore the original display mode and the original GPU gamma ramps.

[turbojet]

Quote:
Originally Posted by turbojet View Post
Shouldn't overlay be following what the device properties are set to in madvr? On dvi and hdmi outputs it does but nvidia svideo overlay seems stuck on limited range and ends up double clipping even if madvr is set to full range.
I'm confused. Your earlier reports led me to believe that Overlay outputs 0-255 on your PC and windowed/FSE outputs 16-235. Is that not correct? Also at one point I think you said this was all dependent on the refresh rate used, IIRC? What you're saying now sounds totally different. I can't really help if your reports change so much all the time. I don't know, anymore, what the problem is or what it isn't.

The refresh rates issue was on another computer over hdmi and that was fixed with a third party tool. The inf driver hack didn't work neither did madLevelsTweaker.

What I'm talking about now is output to a limited range display over svideo. nvidia forces limited range, setting madvr to full range looks fine in windowed and fse. However when switching to overlay madvr gets forced to limited range and it gets double clipped so everything is very dark and oversaturated (level 32 is still black). Overlay mixer and evr-cp with d3d9 overlay have the correct range.

[madshi]

What I'm talking about now is output to a limited range display over svideo. nvidia forces limited range, setting madvr to full range looks fine in windowed and fse. However when switching to overlay madvr gets forced to limited range and it gets double clipped so everything is very dark and oversaturated (level 32 is still black).
That is probably with madVR set to full range? If your TV can't do full range over svideo, then you have to switch madVR to TV level output. Do you get correct levels then (with Overlay)?

[turbojet]

madshi: Switching to pc levels fixes overlay but now window and fse are crushed.

[Ceremony]

why doesnt the composition rate adapt to my monitors frequency? it seems to only use the frequency my main monitor uses (70Hz) and not that of my other devices (50Hz).

tried exclusive full screen mode as well: stuck at 70Hz...

[Eiffel]

You mean you can't "unpress" both buttons at the same time? Works just fine on my PC. Are you talking about madTPG running on its own? Or while ArgyllCMS and/or HCFR are doing measurements through madTPG? In the moment when ArgyllCMS/HCFR take control of madTPG, they have the "power" to enforce these buttons to be pressed. However, as long as no other software is remote controlling madTPG, it should be possible to unpress both of those buttons at the same time.

Madshi, the issue I described started with madVR 0.87.5. Older versions of the madTPG executable do not exhibit this issue.

[Eiffel]

Do you have a a set of linear VidoeLUTs attached to your 3DLUT (collink option "-a")?

Yes, this is what I use:

dispcal.exe -v2 -dmadvr -c1 -yn -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0

dispwin.exe -v -dmadvr -c
dispread.exe -v -dmadvr -c1 -yn -K
colprof.exe -v -qh -ax -bl -C -M madVR -D
collink -v -qh -G -iaw -r65 -n -3m -et -Et -IB:2.4 -a

[markanini]

I am forced to restart MPC-HC to watch a new video when NNEDI3 doubling is enabled, otherwise I get a black screen. HD7770 driver v14.2 beta.Doesn't happen here. But I'm not using v14.2. Don't know if it has to do with that or not.


Solved it by uninstalling the Intel HD and Open CL driver. :)

[agustin9]

why doesnt the composition rate adapt to my monitors frequency? it seems to only use the frequency my main monitor uses (70Hz) and not that of my other devices (50Hz).

tried exclusive full screen mode as well: stuck at 70Hz...

That's how composition works, but I don't think it bothers madvr

[Asmodian]

Yes, this is what I use:

dispcal.exe -v2 -dmadvr -c1 -yn -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0

dispwin.exe -v -dmadvr -c
dispread.exe -v -dmadvr -c1 -yn -K
colprof.exe -v -qh -ax -bl -C -M madVR -D
collink -v -qh -G -iaw -r65 -n -3m -et -Et -IB:2.4 -a

You have linear VideoLUTs appended to the 3DLUT so if you have the 3DLUT enabled the VideoLUTs are disabled automatically. You would also have a very bad calibration if you enabled them.

If you want to test with VideoLUTs enabled use "-H" in collink instead of "-a". VideoLUTs will be forced on if you enable a 3DLUT created with "-H".

edit: Or you could not use "-a" or "-H" and be able to enable & disable the VideoLUTs at will. The 3DLUT would only be correct with the VideoLUT enabled.

edit2: I just noticed you also use "-K" in dispread, you might get slightly more accurate results with "-k" if you create the 3DLUT without using "-a".

[Asmodian]

That's how composition works, but I don't think it bothers madvr

This is correct, it is an issue with Windows 7 that is not present in Windows 8.1.

I understand a v-sync is forced at the composition rate by Aero so you might try the "disable desktop composition" option if you are experiencing issues caused by the composition rate.

[StinDaWg]

You can't use it with jrmc until it or madvr adds pixel shader support. To use it with mpc-hc copy the script (check my sig) into a txt file, rename it .hlsl and put it in mpc-hc's shaders directory. In mpc-hc right click>shaders>select shaders.

The defaults are horrible, I'd suggest pattern 3 and adjusting strength between 0.5-2.0, increasing clamp improves really fine detail without artifacts if adjusted correctly, I use 0.5.
Someone needs to start a LumaSharpen thread. I have so many questions, but this probably isn't the appropriate place to ask.

I've been using 1.5 sharpness, .05 clamp, and pattern 3. I'd really like to understand what makes this pattern better or what the optimal settings are in general and the best way to test.

[XMonarchY]

When I try to use the latest madVR with ArgyllCMS, I get "Windows Access Failed" message and madTPG screen is now gray instead of black, but I guess that was intended... Older version of madVR (0.87.6) works fine though.

[G_M_C]

Hello madshi,

I've been testing madVR 87.7 (and the test-build before that).

For my test i've used my bluray of howls moving castle, and a 10-bit test-encode (x264) ive made from it.

But mainly ive used chapter 4 of my bluray of Samsara (http://www.imdb.com/title/tt0770802/). This scene provides the best test i know. It goes from the bleak greyish landscape of Tibet (contrast/greyscale performance test) to a scene where monks lay out a mandala with pure primary-coloured and black/white sand where you can see individual grains of sand (colour, contrast, detail - performance test).

For my tests i've chosen to use nnedi, 32 neurons, to do chroma up-sampling. The reason for this is that
- As fas as i understand, chroma up-sampling, normally speaking always involves doubling (4:2:x to 4:4:x involves a doubling afaik).
- Based on the screen-shots you posted when you presented nnedi, it was my feeling that nnedi provided the most accurate up-sampling of all scalers; even with odd artifacts.

Based on my tests i found that Error diffusion, on low setting gets best result (ED option 2). I also use chroma dithering with that option. This because it lowers luma artifacts, knowing that human eyes are more sensitive to luma then to chroma. to my reasoning that means the fewer luma-artifacts the better.

Setting dithering to 'chance every frame' results is a visible layer of slight noise, resembling slight film-grain.

Using an other scaler improves performance notably, but gives slightly less detail and color-accuracy on the Samsara tests.

For my use, and based on my eyes, combining both nnedi-32 for chroma up-sampling and ED-2+chroma up-sampling provides very natural looking image. On my calibrated plasma it provides the suggestion as if 'looking through a very clean window'. I've chosen to stick with these settings.

Mayby in the future i can use more neurons for chroma upsampling, but i dont know if it would provide even better results.


You can't use it with jrmc until it or madvr adds pixel shader support. [...]

On my PC i can use pixel shaders icw MPT-HC and madVR. It does seem to work. But i have no idea what the difference is between adding a shader before or after resizing. For instance does it before mean 'before madVR does its chroma upsampling / magic' ? I'd be interested to know.

[jaju123]

Madshi can you describe the AMD interop bug? I managed to get in touch with an AMD representative who is eager to fix the issue, I just need some more info. If you can PM me some info or type it here that would be great!

[aufkrawall]

Is rerender frames while fade in/out (checkbox unchecked) known to cause unstable playback with H.264 interlaced?

[DrNein]

MadShi!!!! ESET Smart Security think your newest version is a virus.. "Probably unknown NewHeur_PE virus"... I'm just informing you even if there is no virus...

SUPERAntiSpyware reckons "InstallFilter.exe" is "Trojan.Agent/Gen-PennyStockChaser".

[madshi]

madshi: Switching to pc levels fixes overlay but now window and fse are crushed.
You mean if you switch madVR to *TV* output levels, correct?

Madshi, the issue I described started with madVR 0.87.5. Older versions of the madTPG executable do not exhibit this issue.
Ok, but you didn't answer any of the questions I asked you. Sorry, can't help you if you ignore my questions.

Solved it by uninstalling the Intel HD and Open CL driver. :)
Oh, interesting. Somewhat strange, though, I have the Intel stuff installed on my PC, too, and it doesn't seem to make any problems here...

This is correct, it is an issue with Windows 7 that is not present in Windows 8.1.
It is not? Didn't know that, that's a nice improvement then.

Mayby in the future i can use more neurons for chroma upsampling, but i dont know if it would provide even better results.
I rather doubt it. I think for chroma upsampling probably 32 neurons is as high as you need to go.

On my PC i can use pxel shaders icw MPT-HC and madVR. It does seem to work. But i have no idea what the difference is between adding a shader before or after resizing. For instance does it before mean 'before madVR does its chroma upsampling / magic' ? I'd be interested to know.
You can e.g. run the sharpening shader on the video in its original resolution. Or you can run it on the video after madVR has scaled it to the target resolution. Some shaders produce better image quality if you run them before scaling, others after scaling.

Is rerender frames while fade in/out (checkbox unchecked) known to cause unstable playback with H.264 interlaced?
No. However, if you uncheck that box you might want to increase the GPU queue size a bit. I'd suggest at least 12 frames, maybe 16.

When I try to use the latest madVR with ArgyllCMS, I get "Windows Access Failed" message and madTPG screen is now gray instead of black, but I guess that was intended... Older version of madVR (0.87.6) works fine though.
I can't seem to be able to reproduce that here. It works just fine here. Please make sure that the madTPG version you're starting matches the madVR version you have installed, otherwise there might be problems.

Madshi can you describe the AMD interop bug? I managed to get in touch with an AMD representative who is eager to fix the issue, I just need some more info. If you can PM me some info or type it here that would be great!
Well, that would be great, of course! I've uploaded a small OpenCL interop speed test tool. Full source code included. You can forward this (and ideally also my whole reply to you) to the AMD representative:

http://madshi.net/OpenClSpeedTest.zip

On my PC with an HD7770 I get the following results:

D3D9 StretchRect: 1834 fps
D3D9 HLSL PixelShader: 2407 fps
OpenCL copy: 1986 fps
OpenCL kernel: 2117 fps
OpenCL copy interop: 427 fps
OpenCL kernel interop: 424 fps

Error Diffusion OpenCL: 466 fps
Error Diffusion OpenCL interop: 134 fps
Error Diffusion OpenCL interop 2: 192 fps
Error Diffusion DirectCompute: 347 fps
Error Diffusion DirectCompute interop: 316 fps
Error Diffusion DirectCompute interop 2: 297 fps
If you look at the top of the measurements, the test tool measures how fast my HD7770 can copy a 1920x1080 video frame, using different methods, including D3D9 StretchRect, a simple PixelShader, an OpenCL "copy" command or a simple OpenCL kernel. As you can see, all of these measure somewhat similar with about 2000 fps. The 2nd test section compares doing Error Diffusion via OpenCL and via DirectCompute.

According to these tests (and my own experience) AMD's OpenCL implementation is working pretty well and fast, as long as you use only native OpenCL image objects. But as soon as I try to integrate OpenCL into my D3D9 rendering pipeline, speed suffers quite noticeably. A simple 1920x1080 frame copy slows down from 2000 fps to 425 fps. Or worse: Error diffusion slows down from 466 fps to just 134 fps. 466fps means one frame takes about 2.5ms to process. 134fps means one frame takes about 7.5ms to process. So basically the interop between OpenCL and Direct3D costs about 5ms per 1080p frame on my PC. And I think this test is making the cost "look good". In real world usage the cost seems to be rather higher. Some users are reporting interop to cost about 10ms per frame. Which is A LOT, considering that for 1080p60 playback each frame must be fully processed and displayed in 16.7ms per frame. And we're talking about 1080p here. I don't even want to think about 4K.

In contrast to that, I can do DirectCompute interop with my Direct3D9 rendering pipeline without any noticeable interop cost at all! Which is how it should be, IMHO. I don't see why there should be any noticeable interop costs. FWIW, neither NVidia's nor Intel's D3D9 <-> OpenCL interop seems to cost much performance. AMD is the only one with a noticeable interop penalty.

And another key problem is that the D3D9 <-> OpenCL interop cost does *not* seem to depend on the GPU speed. The very fastest and the very slowest AMD GPUs both seem to have interop costs of about 5-10ms per 1080p frame.

If this could be fixed, that would be great!

Edit: Here's a user report who has interop costs of about 73ms per 1080p frame (!!), with an HD5870:

http://forum.doom9.org/showpost.php?p=1673651&postcount=25002

[michkrol]

SUPERAntiSpyware reckons "InstallFilter.exe" is "Trojan.Agent/Gen-PennyStockChaser".

It's another false positive. Comes clean with my Avast. The best you can do is report it to them http://forums.superantispyware.com/index.php?/topic/6825-how-to-submit-false-positives/

Also VirusTotal is a pretty neat site that let's you upload files to scan with ~50 different antivirus/antimalware apps. Here are the results for newest madVR https://www.virustotal.com/en/file/0e098c350ce5132e82f7f4fbdc17c546f4424757c000a971a665851abffe1046/analysis/1394854647/

[seiyafan]

This is on my R9 270x:

D3D9 StretchRect: 2832 fps
D3D9 HLSL PixelShader: 2133 fps
OpenCL copy: 3050 fps
OpenCL kernel: 3612 fps
OpenCL copy interop: 400 fps
OpenCL kernel interop: 462 fps


The difference is even greater!!!!!!!

[romulous]

OpenClSpeedTest.zip instantly crashes on my system (NVIDIA GTX660 Ti) - guess that is to be expected until NVIDIA fix the OpenCL issue(s) in their newer drivers.

romulous

[madshi]

It wasn't meant to be used on NVidia GPUs. I've written this just for AMD to demonstrate the interop problem. It requires support for the official OpenCL 1.2 D3D9 interop extension, which NVidia doesn't support atm.

[romulous]

It wasn't meant to be used on NVidia GPUs. I've written this just for AMD to demonstrate the interop problem. It requires support for the official OpenCL 1.2 D3D9 interop extension, which NVidia doesn't support atm.

Ah - sorry about that. I got confused by your mention of the NVIDIA interop not being badly impacted performance wise (thought you must have measured it via the tool, and was curious about what the figures would be on my system).

[Ceremony]

Have there been performance tests with AMD's A10-7850K yet? NNEDI is probably out of the question, but what about Jinc resizing? Can the integrated graphics chips handle that?
Im considering building such a HTPC for about 400-500€

[kostik]

OpenClSpeedTest crashes for me also, but using opencl and error difussion works for me in madVR . I also have Nvidia video card.

[noee]

Have there been performance tests with AMD's A10-7850K yet? NNEDI is probably out of the question, but what about Jinc resizing? Can the integrated graphics chips handle that?
Im considering building such a HTPC for about 400-500€

I had an opportunity with a Kaveri system and madVR, but only for a very limited time, as I messed up the build and had to deliver it under deadline. But, yes, Jinc3 AR was fine with the SD material I tested.

Unfortunately, I had no other material to check and I did not verify NNEDI3 doubling.

I am hoping to build another here soon and do a more thorough analysis.

[madshi]

I tried apimonitor, I hope I have what you need, it's the first time I use this software. I only checked "Audio and Video" and "Graphics and Gaming", here are the results. I included capture file and the same content in text files in case you can't read the capture file (like I said I don't know this software).

https://www.mediafire.com/?25ploj5619ohh50
Did I reply to this one? I think not, but I'm not sure. Just to be safe:

Unfortunately the log doesn't tell Direct3D changes the display mode. Which means that Direct3D does that through an API which the API Monitor didn't hook/watch... :( So back to square one: I can probably only do anything about this if I'm able to reproduce it on my PC, which currently I can't.

[cyberbeing]

On my PC with an HD7770 I get the following results:

D3D9 StretchRect: 1834 fps
D3D9 HLSL PixelShader: 2407 fps

Error Diffusion DirectCompute: 347 fps
Error Diffusion DirectCompute interop: 316 fps
Error Diffusion DirectCompute interop 2: 297 fps

If that DirectCompute error diffusion kernel is anything like the one in madVR, it confirms my previous suspicion that the dither compute time is definitely much slower on NVIDIA vs AMD. With my GTX770 I get the following results (321.10 Driver), after re-compiling the binary with the OpenCL components removed:

D3D9 StretchRect: 7083 fps
D3D9 HLSL PixelShader: 7765 fps

Error Diffusion DirectCompute: 171 fps
Error Diffusion DirectCompute interop: 166 fps
Error Diffusion DirectCompute interop 2: 164 fps

[madshi]

If that DirectCompute error diffusion kernel is anything like the one in madVR, it confirms my previous suspicion that the dither compute time is definitely much slower on NVIDIA vs AMD. With my GTX770 I get the following results (321.10 Driver), after re-compiling the binary with the OpenCL components removed:

D3D9 StretchRect: 7083 fps
D3D9 HLSL PixelShader: 7765 fps

Error Diffusion DirectCompute: 171 fps
Error Diffusion DirectCompute interop: 166 fps
Error Diffusion DirectCompute interop 2: 164 fps
That's quite interesting. The StretchRect/PixelShader results are great! The DirectCompute results not so much. Would be interesting to test the new Maxwell GPUs, maybe they do better at DirectCompute?

[6233638]

mainly ive used chapter 4 of my bluray of Samsara (http://www.imdb.com/title/tt0770802/). This scene provides the best test i know. It goes from the bleak greyish landscape of Tibet (contrast/greyscale performance test) to a scene where monks lay out a mandala with pure primary-coloured and black/white sand where you can see individual grains of sand (colour, contrast, detail - performance test)
...
Setting dithering to 'chance every frame' results is a visible layer of slight noise, resembling slight film-grain.
I think you're just seeing film grain that's in the source, or something that is a result of your compression. I don't really see any difference if I turn dither on or off, and certainly nothing switching between static/dynamic dither.

I do sometimes notice a slight flicker/pulsing brightness in the smooth areas of the image (e.g. the sky) which always has me questioning whether it's in the source or due to the fact that dither is not linked to the framerate. (it's most likely the source, but now that idea is in my head, I notice it all the time)

[nevcairiel]

That's quite interesting. The StretchRect/PixelShader results are great! The DirectCompute results not so much. Would be interesting to test the new Maxwell GPUs, maybe they do better at DirectCompute?

On a GTX 750 (Maxwell):

D3D9 StretchRect: 2312 fps
D3D9 HLSL PixelShader: 2258 fps
Error Diffusion DirectCompute: 276 fps
Error Diffusion DirectCompute interop: 374 fps
Error Diffusion DirectCompute interop 2: 350 fps

[sajara]

Just for the sake of to see how a low end GPU, Radeon 5730M, (but still beefy enough for everything, bar NNEDI) would perform, here are my results:

D3D9 StretchRect: 772 fps
D3D9 HLSL PixelShader: 333 fps
OpenCL copy: 820 fps
OpenCL kernel: 700 fps
OpenCL copy interop: 231 fps
OpenCL kernel interop: 231 fps

Error Diffusion OpenCL: 101 fps
Error Diffusion OpenCL interop: 46 fps
Error Diffusion OpenCL interop 2: 74 fps
Error Diffusion DirectCompute: 56 fps
Error Diffusion DirectCompute interop: 54 fps
Error Diffusion DirectCompute interop 2: 52 fps

ED OpenCL results vs ED DCompute are interesting, but I can vouch that in practical terms, OCL ED was ~56% on my GPU and DC ED is ~34%, so I don't know how to interpret these numbers.

[*Touche*]

Have there been performance tests with AMD's A10-7850K yet? NNEDI is probably out of the question, but what about Jinc resizing? Can the integrated graphics chips handle that?
Im considering building such a HTPC for about 400-500€

A10-5800k @ 1000 MHz can do 720p24->1080 with no trade quality options checked, with debanding, Jinc3 AR luma/chroma upscaling and error diffusion dithering. NNEDI is out of the question.

[iSunrise]

On a GTX 750 (Maxwell):

D3D9 StretchRect: 2312 fps
D3D9 HLSL PixelShader: 2258 fps
Error Diffusion DirectCompute: 276 fps
Error Diffusion DirectCompute interop: 374 fps
Error Diffusion DirectCompute interop 2: 350 fps
That looks promising. Only about 1/10 less FPS at the worst case. Definitely a lot better than cyberbeing's results.

[nevcairiel]

That looks promising. Only about 1/10 less FPS at the worst case. Definitely a lot better than cyberbeing's results.

That is assuming it increases as raw performance increases. :p

[sajara]

For some reason, my first test put a pretty low score on the D3D9 tests, maybe card was idling and power states did not jump fast enough, i really don't know. But here are the final scores after 4 runs:

http://i.imgur.com/qQy6g1F.png

[madshi]

On a GTX 750 (Maxwell):

D3D9 StretchRect: 2312 fps
D3D9 HLSL PixelShader: 2258 fps
Error Diffusion DirectCompute: 276 fps
Error Diffusion DirectCompute interop: 374 fps
Error Diffusion DirectCompute interop 2: 350 fps
Thanks! That looks really promising. Though, I wonder why interop seems to speed things up in your case!? That's rather surprising. Is that reproduceable every time?

Just for the sake of to see how a low end GPU, Radeon 5730M, (but still beefy enough for everything, bar NNEDI) would perform, here are my results:

ED OpenCL results vs ED DCompute are interesting, but I can vouch that in practical terms, OCL ED was ~56% on my GPU and DC ED is ~34%, so I don't know how to interpret these numbers.
FWIW, I think the error diffusion shaders don't match. Meaning the DC ED is probably a newer algorithm, doing more work, while the OCL ED is the very first version, doing less work. The purpose of the test tool was not to compare OCL ED vs. DC ED, but it was interop costs OCL vs DC. Because of that I didn't invest any time to make sure that the ED algorithms were identical in OCL and DC.

That is assuming it increases as raw performance increases. :p
I think it should.

[kasper93]

And my poor HD5870

---------------------------
speed measurements:
---------------------------
D3D9 StretchRect: 2245.072021 fps
D3D9 HLSL PixelShader: 4834.187012 fps
OpenCL copy: 4395.217773 fps
OpenCL kernel: 3370.635010 fps
OpenCL copy interop: 91.733017 fps
OpenCL kernel interop: 98.520515 fps
Error Diffusion OpenCL: 401.759674 fps
Error Diffusion OpenCL interop: 13.235280 fps
Error Diffusion OpenCL interop 2: 52.057819 fps
Error Diffusion DirectCompute: 228.971298 fps
Error Diffusion DirectCompute interop: 218.831314 fps
Error Diffusion DirectCompute interop 2: 214.933136 fps

The same card without aero
---------------------------
speed measurements:
---------------------------
D3D9 StretchRect: 5446.919922 fps
D3D9 HLSL PixelShader: 5224.660645 fps
OpenCL copy: 4317.416504 fps
OpenCL kernel: 3300.330078 fps
OpenCL copy interop: 91.844238 fps
OpenCL kernel interop: 97.938782 fps
Error Diffusion OpenCL: 401.779083 fps
Error Diffusion OpenCL interop: 13.242332 fps
Error Diffusion OpenCL interop 2: 51.752998 fps
Error Diffusion DirectCompute: 227.469162 fps
Error Diffusion DirectCompute interop: 218.710220 fps
Error Diffusion DirectCompute interop 2: 213.650116 fps

Sadly OpenCL interop is VERRRY slow ;/ Would be really great if they improve that on driver level.

[Ver Greeneyes]

That is assuming it increases as raw performance increases. :pCould be that the maximum FPS (on the stretchrect and shader tests) is capped by memory bandwidth or bus speed, whereas the directcompute stuff is capped by processing power. In that case the Maxwell 750 is still something like 276 / 171 ≈ 60% faster than the Kepler 770. Of course that's purely speculation. It seems a bit weird that the versions with interop are faster on the Maxwell though.

[e-t172]

Interested? I don't think it would be of help for madVR development because I don't think it's madVR's fault and there's probably nothing I can do about it. But I'd be willing to look into a debug log to help you. Although I think what I'll find will probably be an unexplained period where either the GPU rendered very slowly, or where madVR got no CPU time. Do you have any software running which might be using the GPU? Try closing that. Are there any background processes or services which might stress the CPU every once in a while? Try stopping them, too. Also try giving the media player process a higher priority. Maybe any of that helps?

Hey madshi,

So I did what you suggested and then some: I used Process Monitor (http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx) to find if any other processes were doing anything while the frame drops happen. I disabled all background processes I could find in the resulting traces. Then I tried disabling as much hardware as possible (unplugging all USB except mouse and keyboard, unplugging network, disabling onboard devices in BIOS, switching SATA controllers, etc.). I switched all power options (GPU and Windows) to maximum performance. I changed MPC-HC process priority to High. None of that makes any difference.

I tried going back to NVidia driver 321.10. I suspect it's slightly better but nevertheless, I still get frame drops.

Then I tried using XPerf (http://blogs.msdn.com/b/ntdebugging/archive/2008/04/03/windows-performance-toolkit-xperf.aspx) and while I'm still unable to fix the problem, I managed to observe some interesting phenomenon:

http://i.imgur.com/us434JZs.png (http://imgur.com/us434JZ)

It appears that every ~7 seconds, a madVR thread (blue spiky line) is blocked during a significant amount of time (10-15 milliseconds). Stack information indicates that during these spikes the vast majority of the time is spent in GetRasterStatus() (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174402%28v=vs.85%29.aspx). madshi: does that make sense to you? This happens all the time and with both NVidia drivers 321.10 and 335.23. Reading the documentation for GetRasterStatus() I am confused as to why any code would spent so much time in this seemingly lightweight non-blocking method like that, especially with such weird periodicity.

Now this might or might not be related to the frame drops, but I suspect it is because every time a frame drop happens it appears to be time-aligned with one of these spikes. In fact with 335.23 (and maybe with 321.10, I'm not sure) in some (not all) frame drop instances it can get much worse:

http://i.imgur.com/fmzi5fys.png (http://imgur.com/fmzi5fy)

The blue line is the madVR thread with the aforementioned spike. The green spike is a massive CPU spin in a kernel thread with a nvlddmkm.sys (NVidia driver) stack trace. It lasts for an enormous amount of time (230 ms in this instance), during which an entire CPU core is hosed and madVR seems to freeze, resulting in a burst of 5+ frame drops. What's interesting there is that the green spike seems to directly follow the blue spike, and the correlation doesn't seem to be a coincidence (the blue spike happens every 7 seconds and the green one follows less than 100 milliseconds after that - or maybe even less due to the sampling resolution). Technically that's probably a NVidia driver bug as it's never supposed to do that but maybe some behavior in madVR is triggering it.

madshi: here are some logs (https://drive.google.com/file/d/0B4SHVPm2DfK5U3E2cU1PTTJPNHc/edit?usp=sharing). The "try15" one is with 335.23 and relates to the graph above. The drop happens at timestamp 00439135 in the log. The "try16" one is with 321.10 and the drop happens at timestamp 01562318. In both runs, care has been taken to disable all unnecessary hardware and background processes to make the test as "pure" as possible. All madVR options are set to defaults except for Smooth Motion which is enabled. Sorry for the giant "try16" log - I sometimes have to wait a long time before the issue shows up again.

I really hope you can make sense of this, because I'm *really* out of options now. My only possible next steps are nuclear options like a Windows reinstall or even replacing the GPU or motherboard...

By the way, feature request: it would be nice if madVR could log the current system time in human-readable form every second or so, as it makes it easier to correlate the entries in the log with external tools like Process Monitor or XPerf.

[iSunrise]

That is assuming it increases as raw performance increases. :p
Yeah, we'll have to wait and see. :p

[markanini]

HD7770 Calayst Beta

http://i.imgur.com/X4blITZ.png

[madshi]

And my poor HD5870

OpenCL kernel: 3351.992920 fps
OpenCL copy interop: 91.797607 fps

Error Diffusion OpenCL: 402.034302 fps
Error Diffusion OpenCL interop: 13.219771 fps
Seriously!?!? This is not funny, anymore. 402fps = 2.5ms rendering time. 13.22fps = 75.6ms rendering time. So on your PC interop cost per 1080p frame is 73.1ms. That's insane.

It appears that every ~7 seconds, a madVR thread (blue spiky line) is blocked during a significant amount of time (10-15 milliseconds). Stack information indicates that during these spikes most of the time is spent in GetRasterStatus() (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174402%28v=vs.85%29.aspx). madshi: does that make sense to you? This happens all the time and with both NVidia drivers 321.10 and 335.23. Reading the documentation for GetRasterStatus() I am confused as to why any code would spent so much time in this seemingly lightweight non-blocking method like that, especially with such weird periodicity.
Yes, it does make sense. madVR calls GetRasterStatus() all the time to decide in which exact moment to present frames. Especially in windowed and overlay modes the information collected from GetRasterStatus() is extremely important. In FSE mode it's a bit less important, but still a bit.

I agree with you, there's no possible reason why a call to GetRasterStatus() would block for any serious amount of time. Furthermore, madVR intentionally uses a separate D3D9 device to call GetRasterStatus() to avoid any conflicts with the rendering and presentation devices! So there's basically one D3D9 device which is used for nothing else but calling GetRasterStatus() once every millisecond (Sleep(1)).

Such a block for 10-15ms could cause problems in windowed/overlay mode, but I believe FSE mode should not even notice that, unless the driver internally blocks, too, and fails to flip to an already planned video frame via VSync hardware interrupt. That would then be one situation which would end up as a presentation glitch.

The blue line is the madVR thread with the aforementioned spike. The green spike is a massive CPU spin in a kernel thread with a nvlddmkm.sys (NVidia driver) stack trace. It lasts for an enormous amount of time (230 ms in this instance), during which an entire CPU core is hosed and madVR seems to freeze, resulting in a burst of 5+ frame drops. What's interesting there is that the green spike seems to directly follow the blue spike, and the correlation doesn't seem to be a coincidence (the blue spike happens every 7 seconds and the green one follows less than 100 milliseconds after that - or maybe even less due to the sampling resolution). Technically that's probably a NVidia driver bug as it's never supposed to do that but maybe some behavior in madVR is triggering it.
I can't say if madVR is triggering it, at least I wouldn't know which madVR behaviour would/could be responsible for that. But one thing is probably important to mention: There are quite a lot of madVR users, many of them posting regularly in this thread, and I think the majority of them have NVidia GPUs, but it seems you're the only one who has this specific problem (at least that I'm aware of). That indicates that there is probably something special about your PC. Have you tried updating the GPU BIOS? Not sure if that would help, but it might be worth a try. It could also be a weird GPU hardware problem. I don't really know. Have you tried reinstalling the OS (ouch!)? Not sure what else I could suggest... :( The easiest test might be to get another (cheap?) NVidia GPU just to double check whether replacing the GPU would solve the problem or not. Or you could try plugging your GPU into a different PCIe slot, if your mainboard has more than one.

here are some logs (https://drive.google.com/file/d/0B4SHVPm2DfK5U3E2cU1PTTJPNHc/edit?usp=sharing). The "try15" one is with 335.23 and relates to the graph above. The drop happens at timestamp 00439135 in the log. The "try16" one is with 321.10 and the drop happens at timestamp 01562318. In both runs, care has been taken to disable all unnecessary hardware and background processes to make the test as "pure" as possible. All madVR options are set to defaults except for Smooth Motion which is enabled. Sorry for the giant "try16" log - I sometimes have to wait a long time before the issue shows up again.
I appreciate the time you took to create clean logs etc, but unfortunately driver problems like this (threads getting stuck in NVidia drivers) are not really an ideal candidate to use logs for. The logs help mostly if there are problems in madVR. I've had a quick look at the logs and the only thing I can see in there is that when the frame drops occur, shortly before there's nothing in the logs for e.g. 200ms or so, which is a dramatically long time. And I can't see from the logs *why* nothing is occurring, it just looks like madVR isn't getting any CPU time or something like that...

I really hope you can make sense of this, because I'm *really* out of options now. My only possible next steps are nuclear options like a Windows reinstall or even replacing the GPU or motherboard...
I'm not sure if there are other options than that, to be honest... :( Do you have an old GPU lying around somewhere? That would be the easiest and quickest way to double check if replacing the GPU would help.

By the way, feature request: it would be nice if madVR could log the current system time in human-readable form every second or so, as it makes it easier to correlate the entries in the log with external tools like Process Monitor or XPerf.
True. Though, usually users don't really know how to interpret logs, and I personally don't have much use for such timestamps from the users' PCs because I never got logs from other tools from a user yet.

[XMonarchY]

madshi, I uninstalled madVR using uninstall.bat from ALL locations, then did the same for restore default settings.bat, then I removed all the files from all location, ran several file cleaners, registry cleaners, restarted, re-downloaded the latest madVR, ran restory default settings.bat again, opened madTPG and the screen turned gray again (not due to 16-235 range)...

Here is what happens when I open madTPG.exe. At first Windows shows me the Security Warning. I press RUN. Then madTPG appears and it has a valid black screen. Then, I get madHcCtrl.exe Security Warning. As soon as I press RUN - madTPG screen goes from black to gray and then I get Windows Access problem... so it is something in madHcCtrl.exe I presume (not saying its madVR's issue), a setting or something... yet, all is at default, no old settings used. I really have no idea... Maybe the latest 335 nVidia drivers did this...

[Eiffel]

Ok, but you didn't answer any of the questions I asked you. Sorry, can't help you if you ignore my questions.

I presume you were looking for the following questions

You mean you can't "unpress" both buttons at the same time?

Yes, I cannot do that with the recent builts.

Works just fine on my PC. Are you talking about madTPG running on its own? Or while ArgyllCMS and/or HCFR are doing measurements through madTPG? .

This issue is with madTPG running on its own and with HCFR (I'm not sure how to try while ArgyllCMS are doing automated measurements)...

In the moment when ArgyllCMS/HCFR take control of madTPG, they have the "power" to enforce these buttons to be pressed. However, as long as no other software is remote controlling madTPG, it should be possible to unpress both of those buttons at the same time..

While not a question, I can't unpress both of these buttons (at least one of the buttons will be blue no matter what I try). I suspect it has do with the logic controlling the buttons... when disable VideoLUTs is grey (ie the VideoLUT is enabled), and disable 3dlut is blue (ie disabled), pressing the disable 3dlut button toggles the state of Both buttons.