madVR - high quality video renderer (GPU assisted)

[madshi]

Oh well. The failure replies are pretty much empty. Very weird. Is there a 3s delay for the failures as well as for the success?

[leeperry]

yep, just tried again: the 3 secs wait is mandatory either way..forgot to mention that. And yes, when it fails, the .dat file is empty.

I don't think I'm the only one w/ this problem, maybe their .dat will be more fruitful.

[ryrynz]

I think it would be a good idea to finally implement your final rendering path now and focus on the bugs after, nobody is going to complain about their reported bug not being fixed in the new version. At the end of the day it's your software Madshi.

[pankov]

madshi,
I'm breaking my promise and I'm reporting a problem with v0.43 but it's only to let you know - I can totally live with v0.42 until you finish the new rendering path.
I'm not certain why but v0.43 brought back the GUI redraw problems in ZoomPlayer. It behaves the same as pre v0.41 - I have make something to force a redraw of the GUI.
And again - don't bother fixing this before you implement the new exclusive rendering.

[bjd]

Hmmmm... Do you have to reboot? Or does restarting the media player also help? My first guess would be that either your GPU driver has some kind of memory leak, resulting in problems after a while. Or that your GPU clocks down after a while and fails to clock up again. Can you try locking your GPU clocks and voltages at a fixed value, just as a test? You should be able to do that with one of the tweaker tools, I think.

@madshi - many thanks for this. I like you suspected memory leak, however I did notice looking at GPU-Z, that the card does clock down when Mpc-HC/MadVR is not in use. I have not had chance to fully test, but I am assuming this is the cause. Restarting Mpc-Hc makes no difference so have to resort to a reboot. Now all I have to do is find a way to clock the card at 100% as sadly RivaTuner does not give me any options with the GT430 :confused:

[pirlouy]

Madshi, 1 question: You said that in future, you'd like to adapt screen refresh rate to video framerate, but for videos which are in 23,976fps, they will be displayed at 23,976 fps whereas in the best scenario, it should be displayed at 24fps, no ?
Do you think it's the decoder or a post processing filter which should speed up the video ? Or we have to forget 24fps ?

Maybe I don't understand anything, but it could help me understand it better if you tell me where I'm wrong.

[djsolidsnake86]

very good, flv problem is solved now :)
great madshi!

[yesgrey]

Now all I have to do is find a way to clock the card at 100% as sadly RivaTuner does not give me any options with the GT430 :confused:
Try with NVidia PowerMizer Manager.

[dansrfe]

Feature Request:

Hi madshi. If possible can you implement "save screenshot" in your renderer? Thanks.

[bjd]

Try with NVidia PowerMizer Manager.

Thanks yesgrey, came across a link to it in another forum whilst researching the issue and it works a treat.

I spent about an hour monitoring the Nvidia card using GPU-Z and safely say the Nvidia Power saving logic is not very smart at all :mad:

[leeperry]

the Nvidia Power saving logic is not very smart at all
A great fix is to reflash a BIOS that disables it completely...worked like a treat for me.

I also disabled the Speedstep of the CPU, the CPU/PCI-E Spread Spectrums and CPU/NB clock skews(jitter party \o/ )...this makes Reclock and mVR happy :p

[yesgrey]

I spent about an hour monitoring the Nvidia card using GPU-Z and safely say the Nvidia Power saving logic is not very smart at all :mad:
Yes, that's why I perform my own power saving logic...

I installed nvidia system tools, and created two profiles. One with all the clocks set to the lowest, for day-to-day usage, because for most of the stuff that's plenty enough. For special usage, like when using mpc-hc, I created a profile with the normal clocks to be loaded whenever I use mpc-hc. So, power saving on everyday work, and top performance with mpc-hc.

Furthermore, every time you want to use your nvidia gpu at its top performance, you should open the nvidia control panel, select the "Adjust Image Settings With Preview", and then minimizing it. We need to do this to get low DPC latencies, which otherwise are always very high (nvidia drivers bug).

[fairchild]

I'm assuming doing all these things for power management isn't needed with ATI cards? I always just let my card handle itself and throttle it's clocks dynamically. This shouldn't harm the card correct? For example, depending on the clip, madVR will sometimes take the card from it's idle state of 240mhz it then goes to 500mhz to 850mhz and changes the clock rate on it's own. Some clips it just goes to 850mhz and stays at that for the entirity of the clip, other times like I said it goes from 850mhz to 240mhz as needed.

[nevcairiel]

I never fiddled with those setting on my NVIDIA either, and i never noticed any problems during playback. Maybe its running on too high clocks when idle, but *shrug*

[leeperry]

I'm assuming doing all these things for power management isn't needed with ATI cards? I always just let my card handle itself and throttle it's clocks dynamically. This shouldn't harm the card correct?
When I was using an HD3850, I remember spying on the clocks speed w/ RivaTuner and sometimes it was powering down for a few secs while using HR. I haven't done the same tests w/ mVR, though...but I don't trust all those speedstep mechanisms. Fixed speeds from top to bottom allow for less jitter in the end IMHO. Same goes for Speed Spectrums, some computer audio companies do advise to turn these off completely.

[soulkeeper]

Ah, you're *down*sizing, right? Then it makes sense. I originally thought you were upsizing.

Yes..i'm downsizing...so ne resize done by madvr...but it does it's magic concerning conversion to rgb, upsampling e.t.c..

Should i select YV12 or NV12 as ffdshow output?(the input of ffdshow is YV12..)


Please try again with the next build. Might have been a bug.

no fix with 0.43...still composition rate is not shown in fullscreen exclusive mode....so probably AERO is disabled...

[madshi]

I'm breaking my promise and I'm reporting a problem with v0.43 but it's only to let you know - I can totally live with v0.42 until you finish the new rendering path.
I'm not certain why but v0.43 brought back the GUI redraw problems in ZoomPlayer. It behaves the same as pre v0.41 - I have make something to force a redraw of the GUI.
Ok. I thought this wouldn't happen, but I know what causes it. Doesn't cost me any time to fix, so the fix will be included in the next build.

Madshi, 1 question: You said that in future, you'd like to adapt screen refresh rate to video framerate, but for videos which are in 23,976fps, they will be displayed at 23,976 fps whereas in the best scenario, it should be displayed at 24fps, no ?
Do you think it's the decoder or a post processing filter which should speed up the video ? Or we have to forget 24fps ?
That's a complicated question. There are many options: E.g. you could convert the video to 24.000fps by using eac3to. Or you could use Reclock to change FPS to 24.000fps. Or you could use some other real time filter to perform the FPS change (don't know if any other filter exists, maybe an AviSynth script?). The problem with letting Reclock or some other filter change the FPS is that usually the video renderer doesn't really know about the FPS change. So madVR still thinks it's supposed to render at 23.976. The proper solution for that problem would be for Reclock to modify the video media type, too. But that's not easy to do. So this whole topic is kinda difficult. I guess I'll implement some kind of workaround. E.g. if the movie file name contains the text "@24.000Hz", madVR would force a switch to 24.000Hz instead of 23.976Hz, regardless of what the video track says.

very good, flv problem is solved now :)
Good to hear!

If possible can you implement "save screenshot" in your renderer?
That's already on my to do list. There are a lot of things on my to do list... :)

Furthermore, every time you want to use your nvidia gpu at its top performance, you should open the nvidia control panel, select the "Adjust Image Settings With Preview", and then minimizing it. We need to do this to get low DPC latencies, which otherwise are always very high (nvidia drivers bug).
Ouch!

Was happens if you have high DPC latencies? Audio skips? Bad audio quality? Video stuttering?

I'm assuming doing all these things for power management isn't needed with ATI cards?
I've no idea. In theory it shouldn't be needed for *any* GPU. I've just suggested it as a possible solution because I've been told before that fixing the GPU clocks solved some funny problems. If you don't have any problems, then don't bother looking at the GPU clocks.

Should i select YV12 or NV12 as ffdshow output?(the input of ffdshow is YV12..)
It doesn't matter. It's one and the same to madVR.

no fix with 0.43...still composition rate is not shown in fullscreen exclusive mode....so probably AERO is disabled...
Ok, I'll check that.

[soulkeeper]

It doesn't matter. It's one and the same to madVR.



as it's the same to madvr,isn't it "safer" to choose ffdshow to output YV12(so that it doesn't make any conversion) and let madvr do it's magic?

@offtopic
are there any disadvantages in outputing yv12 in ffdshow?

[madshi]

Conversion between YV12 <-> NV12 is lossless. However, if ffdshow gets YV12 in, it might make sense to also output YV12 to save a tiny bit of CPU power.

[nevcairiel]

Furthermore, every time you want to use your nvidia gpu at its top performance, you should open the nvidia control panel, select the "Adjust Image Settings With Preview", and then minimizing it. We need to do this to get low DPC latencies, which otherwise are always very high (nvidia drivers bug).

What do you consider "very high"?
According to that DPC Latency Checker, i have around 100-110 µs latency. This does not change if i open the panel, or run madVR, or play a game.

This is with a GTX 570 on 266.58 drivers.

[soulkeeper]

Conversion between YV12 <-> NV12 is lossless. However, if ffdshow gets YV12 in, it might make sense to also output YV12 to save a tiny bit of CPU power.

:thanks:

[iSeries]

Hi Mashi,

Any chance of automatic refresh rate changes soon? I can't seem to get MPC-HC's auto refresh rate to work with MadVR (does it work for anyone else?).

[jeremy33]

iSeries, you can try that to have automatic refresh rate changes : AutoFrequency (http://www.homecinema-hd.com/autofrequency_en.html)

[yesgrey]

Was happens if you have high DPC latencies? Audio skips? Bad audio quality? Video stuttering?
It would depend on how high, but usually the audio might skips, the video might stutters, and sometimes even freeze for some seconds...

What do you consider "very high"?
According to that DPC Latency Checker, i have around 100-110 µs latency. This does not change if i open the panel, or run madVR, or play a game.

This is with a GTX 570 on 266.58 drivers.
That's OK, it's what's supposed to be on Win7 (on XP it should be ~50us). In my case, with a GT 240 and the same drivers, I get ~1450us with auto clocks management, ~1000us with fixed clocks, and ~100us with fixed clocks and the control panel opened in the preview tab (any other tab keeps the latencies high).

I've read in NVidia forums that their two next drivers release should improve on this, so let's just hope that it really happens.

[mark0077]

Well I confirmed that on a very busy 1080p music video I have, with avisynth scripts almost maxing out my machine converting from 24 to 50fps, and overall finding this video particular difficult, I consistently get about half as many frame drops when I set my Nvidia GTX 295 to "Prefer maximimum performance" as opposed to "Adaptive" for mpc-hc.exe.

Repeated tests shows about 33 frame drops, maybe 1 frame delay over the 3 minute clip with "Prefer maximum performance" and between 55 and 85 drops with 5-10 frame delays whens et to "Adaptive". I'm surprised myself actually.... I'm unsure if its dpc spikes caused by the gpu changing mode or what, but I think I'll be definitely leaving nvidia control panel set to prefer maximum performance, for mpc-hc.exe...

I'm unsure if this only crops up when the machine is under high stress like mine was but definitely a large difference between the two...(as I often have 0 frame drops when in adaptive mode with my machine under less stress with avisynth scripts etc...) yesgrey did you ever set gpu performance settings on a per exe basis like I'm doing, just be interesting to see the differences in results so we can come to some conclusion. I'm using 267.24 drivers.

[madshi]

Any chance of automatic refresh rate changes soon?
My plan is to implement the final exclusive mode rendering path first. And then probably refresh rate changing next. How long it takes will mainly depend on how many bug fixes I have to do in between.

Well I confirmed that on a very busy 1080p music video I have, with avisynth scripts almost maxing out my machine converting from 24 to 50fps, and overall finding this video particular difficult, I consistently get about half as many frame drops when I set my Nvidia GTX 295 to "Prefer maximimum performance" as opposed to "Adaptive" for mpc-hc.exe.
Oh, that's interesting!

[iSeries]

@ jeremy33 - works perfectly, thanks!

[jeremy33]

Yes I know :) it's a very good little software

[yesgrey]

yesgrey did you ever set gpu performance settings on a per exe basis like I'm doing, just be interesting to see the differences in results so we can come to some conclusion. I'm using 267.24 drivers.
Yes, but using nvidia system tools for it. I removed all PowerMizer keys to disable it completely, and I load/unload my own high performance profile (I'm overclocking my GPU ram to 4000MHz) whenever I start/stop mpc-hc.exe. I'm still using 266.58 drivers.

According to NVidia only its drivers April release should contain the full changes that would improve the DPC latency problems.

[noee]

Any madVR users out there tried with the new Zacate platform (6310 moniker)? Doesn't really appear to have the horsepower needed, looks like a re-branded 4250 IGP on the 40nm node.

[JamPS]

That's weird! Can I have a log, please? Let the blinking run for a couple of seconds, then press pause and resume and let it continue to run for a couple of seconds. Then close MPC-HC.

Ahh, it had to do with "disable desktop composition" being suddenly enabled, without that checked it works again fine :)
Didn't get it to blink like it used to though, will make a log if it does it again.

Here are 2 logs, one with desktop composition disabled, one without.

[madshi]

Ahh, it had to do with "disable desktop composition" being suddenly enabled, without that checked it works again fine :)
Didn't get it to blink like it used to though, will make a log if it does it again.
Can you reproduce the problem with v0.43 at all? I've added a fix to v0.43 which may have fixed the problem completely.

[ExtraEye]

Recently my graphic card's been heating up and i've found shutting down the process "poclbm.exe" solves it.
I would even kill the process, then later it would start on it's own and somehow use my gpu(98%).
I don't know why this is happening, but process explorer pointed me to madvr folder and so for now i deleted it.

NVM: Probably a virus.

[madshi]

There's a poclbm.exe in your madVR folder? Where did that come from? It's not part of madVR.

[nevcairiel]

poclbm.exe is some tool that uses your GPU calculation power to mine for Bitcoin currency blocks. (The more computing power you put in, the more coins you get). I guess you installed that at some point... :d

[Mark_A_W]

I've just built myself up a new PC based on a Core I7 950, with hyperthreading. It's very fast :)
And I'm still running windowed mode as I run an interlaced res for my CRT, and exclusive mode fails.


Anyway, I've had terrible trouble getting madVR to play even remotely smoothly - it's just been a jumpy mess, with dropped and delayed frames jumping 20 or more every few seconds.

Turns out it is the "upload frames in render thread" option. With that disabled I get rock solid results - I can play for ages (hours) with no dropped or delayed frames at all. Turn it on and the mess returns. All other performance settings left at default.


Is anyone else running a hyperthreaded CPU?

Cheers

Mark

[mark0077]

I've just built myself up a new PC based on a Core I7 950, with hyperthreading. It's very fast :)
And I'm still running windowed mode as I run an interlaced res for my CRT, and exclusive mode fails.


Anyway, I've had terrible trouble getting madVR to play even remotely smoothly - it's just been a jumpy mess, with dropped and delayed frames jumping 20 or more every few seconds.

Turns out it is the "upload frames in render thread" option. With that disabled I get rock solid results - I can play for ages (hours) with no dropped or delayed frames at all. Turn it on and the mess returns. All other performance settings left at default.


Is anyone else running a hyperthreaded CPU?

Cheers

Mark
I'm using an i7 920 and have never had such an issue with that setting, but I'm not using interlaced. I assume your problem is nothing to do with your cpu but your gfx card / its drivers or both? What gfx card / driver / os combo are you using?

[Mark_A_W]

I'm using an i7 920 and have never had such an issue with that setting, but I'm not using interlaced. I assume your problem is nothing to do with your cpu but your gfx card / its drivers or both? What gfx card / driver / os combo are you using?


I have an ATi 4850, cat 11.2 and W7 x64.

In this regard, the old PC (Q6600) was the same.

[mark0077]

Ah ok, well if it was me I suppose I would just go and make sure I had the latest bios for my board, and go through each setting in there making sure is A-OK especially ones to do with high precision timing etc... install latest chipset drivers and audio drivers etc and maybe check dpc latency to see if there are issues. I hope you resolve it!

[soulkeeper]

Well,i started using another avisynth script to interpolate 23.976->60 which uses 30%cpu,so now i don't resize to 1280*720 in ffdshow...
Madvr is doing the resize now(about 80% gpu usage ati 5670)..actually it is downscalling cause most movies are 1080p and my display is 720p....
In the settings page there is not a setting about chroma downscalling (in luma downscalling i've selected spline 4taps)...
What is the chroma downscalling method?

Also,is it normal to take 15-20 minutes for my fps to stabilze at 60fps (actually 60.02fps as per mpchc statistics)...shouldn't that be exactly 60fps?

[madshi]

Anyway, I've had terrible trouble getting madVR to play even remotely smoothly - it's just been a jumpy mess, with dropped and delayed frames jumping 20 or more every few seconds.

Turns out it is the "upload frames in render thread" option. With that disabled I get rock solid results
Interesting. On my NVidia integrated GPU playback I seem to have better results with the option enabled.

In the settings page there is not a setting about chroma downscalling (in luma downscalling i've selected spline 4taps)...
What is the chroma downscalling method?
The chroma algorithm you can choose in the settings dialog is applied for both up- and downsampling.

Also,is it normal to take 15-20 minutes for my fps to stabilze at 60fps (actually 60.02fps as per mpchc statistics)...shouldn't that be exactly 60fps?
Which exact "fps" statistic are you talking about?

[madshi]

For future madVR development I need YOUR HELP.

http://madshi.net/madNV12Test.zip

This is a little test program I've written which runs a few texture/surface related tests on your GPU and writes the results to a text file called "madNV12.txt" on your desktop. If you want to help out with future madVR development, please run this tool on your PC and send the "madNV12.txt" file to me via PM or email. Please don't post the results into this thread, otherwise there would be too many posts here. I need test results from as many OS / GPU combinations as possible.

Is there anybody with an Intel GPU who can run this, too? I'm asking this specifically because I know that most madVR users are using NVidia and ATI. Of course I also need test results from as many different NVidia and ATI GPUs as possible, integrated and dedicated.

Thanks for your help!

Just in case you're wondering, here are the test results from my HTPC:

Windows 7 x64 Service Pack 1
NVIDIA GeForce 9400

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-235)
D3DFMT_X8R8G8B8: lossy (16-235)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: luma lossless (16-236), chroma lossy
D3DFMT_A2B10G10R10: luma lossless (16-236), chroma lossy
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: luma lossless (16-235), chroma lossy
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-235)
D3DFMT_X8R8G8B8: lossy (16-235)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: luma lossless (16-236), chroma lossy
D3DFMT_A2B10G10R10: luma lossless (16-236), chroma lossy
D3DFMT_A16B16G16R16: luma lossless (16-235), chroma lossy
D3DFMT_A16B16G16R16F: luma lossless (16-235), chroma lossy
D3DFMT_A32B32G32R32F: luma lossless (16-235), chroma lossy

DXVA Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-190)
D3DFMT_X8R8G8B8: lossy (16-190)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-191)
D3DFMT_A2B10G10R10: lossy (16-191)
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: lossy (16-178)
D3DFMT_A32B32G32R32F: StretchRect failed

DXVA Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-235)
D3DFMT_X8R8G8B8: lossy (16-235)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: luma lossless (16-236), chroma lossy
D3DFMT_A2B10G10R10: luma lossless (16-236), chroma lossy
D3DFMT_A16B16G16R16: luma lossless (16-235), chroma lossy
D3DFMT_A16B16G16R16F: luma lossless (16-235), chroma lossy
D3DFMT_A32B32G32R32F: luma lossless (16-235), chroma lossy

D3D9 Surface speed test:
NV12: upload 458 fps, download 27 fps, trick download failed
YV12: upload 278 fps, download 26 fps, trick download failed
A8R8G8B8: upload 164 fps, download 96 fps, trick download failed

DXVA Surface speed test:
NV12: upload 188 fps, download 252 fps, trick download failed
YV12: upload 278 fps, download 26 fps, trick download failed
A8R8G8B8: upload 160 fps, download 12 fps, trick download failed

A8R8G8B8 Texture speed test:
default: upload 81 fps, download 101 fps
dynamic: upload 112 fps, download 29 fps, trick download 74 fps
As you can see, it's just a bunch of tests. In the first sections I'm testing which methods the GPU/driver supports for converting NV12 surfaces to RGB textures and whether the conversion is "lossless" (meaning whether the conversion is fully reversible). In the last past of the tests I'm doing some speed tests to find out how fast GPU textures and GPU surfaces can be read from and written to. The test results will help me choosing the right algorithms for future development.

For comparison here's my development PC:

Windows XP Service Pack 3
AMD Radeon HD 6800 Series

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (0-255)
D3DFMT_X8R8G8B8: lossy (0-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: lossy (0-255)
D3DFMT_A2R10G10B10: lossless (0-255)
D3DFMT_A2B10G10R10: lossless (0-255)
D3DFMT_A16B16G16R16: lossless (0-255)
D3DFMT_A16B16G16R16F: lossless (0-255)
D3DFMT_A32B32G32R32F: lossless (0-255)

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (0-0)
D3DFMT_X8R8G8B8: lossy (0-0)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: VideoProcessBlt failed
D3DFMT_A2R10G10B10: VideoProcessBlt failed
D3DFMT_A2B10G10R10: VideoProcessBlt failed
D3DFMT_A16B16G16R16: VideoProcessBlt failed
D3DFMT_A16B16G16R16F: VideoProcessBlt failed
D3DFMT_A32B32G32R32F: VideoProcessBlt failed

DXVA Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (0-255)
D3DFMT_X8R8G8B8: lossy (0-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: lossy (0-255)
D3DFMT_A2R10G10B10: lossless (0-255)
D3DFMT_A2B10G10R10: lossless (0-255)
D3DFMT_A16B16G16R16: lossless (0-255)
D3DFMT_A16B16G16R16F: lossless (0-255)
D3DFMT_A32B32G32R32F: lossless (0-255)

DXVA Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (0-0)
D3DFMT_X8R8G8B8: lossy (0-0)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: VideoProcessBlt failed
D3DFMT_A2R10G10B10: VideoProcessBlt failed
D3DFMT_A2B10G10R10: VideoProcessBlt failed
D3DFMT_A16B16G16R16: VideoProcessBlt failed
D3DFMT_A16B16G16R16F: VideoProcessBlt failed
D3DFMT_A32B32G32R32F: VideoProcessBlt failed

D3D9 Surface speed test:
NV12: upload 181 fps, download 4 fps, trick download failed
YV12: upload 184 fps, download 4 fps, trick download failed
A8R8G8B8: upload 105 fps, download 2 fps, trick download failed

DXVA Surface speed test:
NV12: upload 178 fps, download 4 fps, trick download failed
YV12: upload 181 fps, download 4 fps, trick download failed
A8R8G8B8: upload 107 fps, download 2 fps, trick download failed

A8R8G8B8 Texture speed test:
default: upload 58 fps, download 174 fps
dynamic: upload 139 fps, download 2 fps, trick download 169 fps
As you can see the test results vary quite a bit. I'm not sure how much of the difference is GPU related and how much is OS related.

[Razoola]

I have sent result of my gtx295 via PM.

[madshi]

Thanks in advance to everyone who helps out. Please understand if I don't reply to everyone... :) Please don't "announce" your PM/eMail in this thread. It's not necessary, I regularly check my PMs and eMails.

[madshi]

I've just noticed something in a report I just received. The first section reads like this:

Windows 7 x64 Service Pack 1
NVIDIA GeForce GTX 260

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (0-255)
D3DFMT_X8R8G8B8: lossy (0-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (0-255)
D3DFMT_A2B10G10R10: lossy (0-255)
[...]
If you have an NVidia GPU and if in the "D3D9 Surface StretchRect" section the test results say "(0-255)" that means that your NVidia GPU outputs video levels, by forcefully stretching all data behind madVR's back. This can result in banding artifacts. The fix for this problem is to create custom resolutions. You can double check whether the fix works by running madNV12Test again. If it reads "(16-235)" in the "D3D9 Surface StretchRect" section, that means you're getting proper output levels for best madVR quality.

Please note: This only applies to NVidia!

Edit: It seems that the "Adjust video color settings - Advanced - Dynamic Range" settings also affect these results. You should probably set them to "Video Player Settings" if you want to find out whether you get proper output levels with madVR. Probably only then my advice above is valid.

[madshi]

Ok, time for some first conclusions.

upload speeds:
ATI: good (win7); acceptable (XP)
NVidia: good
Intel: acceptable

texture download speeds:
ATI: good (win7); acceptable (XP)
NVidia: good
Intel: acceptable

surface download speeds:
ATI: catastrophic
NVidia: fantastic (newer hardware/drivers); catastrophic (XP with older hardware/drivers)
Intel: catastrophic

reliability of NV12 -> RGB conversion
ATI: good (pretty much always the same)
NVidia: bad (influenced by various video options, sometimes weird results)
Intel: good (pretty much always the same)

lossless reversibility of NV12 -> RGB conversion
ATI: good
NVidia: bad (no way to stop driver from doing chroma upsampling, sometimes weird results for luma)
Intel: very bad (even luma is never reversible)

-------

Seems to me that ATI users might benefit from going win7. For NVidia users XP seems to do just fine (in these tests, at least), as long as you don't have old hardware + old drivers. Intel is really bad, even in win7.

P.S: Just to clarify: Most of these test results don't affect the current madVR version.

[namaiki]

madshi, did you get any results from users with Intel graphics on sandy bridge? I think it's called Intel HD Graphics 3000.

[madshi]

Don't know for sure. I've two reports with "Intel(R) HD Graphics", one with "Mobile Intel(R) 4 Series Express Chipset Family" and one with "Mobile Intel(R) 965 Express Chipset Family".

[namaiki]

Darn. Looking at the driver inf, it seems that the latest generation Intel Sandy Bridge graphics will come up as "Intel(R) HD Graphics Family".

[Razoola]

I noticed that the report created by your program does not report the graphic card driver version. It might be a good thing to have this reported in the case of nvidia at least given the issue you have already found