LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA

[Andy o]

OK, so I put back in my GTX 460, but I have the same problem as Thuan, after using CUVID and closing MPC-HC, my card stays in the P8 power state until I reboot the PC. Before playing the video, it returns promptly to P12, after, it doesn't. This is with 280.26 drivers on Win 7-64. Are all you guys using those drivers?

[thuan]

Maybe it is the driver as I'm also on that driver. At work now so I can't try any other driver version now.

[Andy o]

Tried 280.36 as well, same thing.

[Andy o]

OK, I enabled Nvidia Inspector's Multi Display Power Saver for MPC-HC (set for P8) and the bug went away, now it goes back to P12. (It says *P12 though, don't know what the asterisk is about, but clocks and voltage are P12 indeed).

EDIT: The asterisk seems to indicate that the P state is locked, so in this case it's because it's being forced by NV inspector, not because the driver went back to P12 as it should.

[CruNcher]

Andy o could you try the 280.47 (should be a little better though not perfect) and the 275 driver the 280.26 WHQL can stay sometimes for a very long time in a mode (like it's stuck) it should work better for XP though.

Last info about the P-state improvement and most probably a driver with more conservative switching behavior (though most probably not so fast (low latency start to switch) then the current 280.36 WHQL when it sometimes works )
Though i can understand if Nvidia has to change to higher latency to keep compatible with every low price component card (PMU) on the market again, at least it shows which cards are of high build quality and which not (if you don't overclocked or its pre overclocked and it still resets with a TMD in 3D Games) )

Got an email from nVidia admitting fault with the 280.26 driver, said they are aware of what is causing the problems and that the next driver branch is 285.

I am guessing it's the same people who worked on the 275 set which aren't too bad.

[Andy o]

I could not find a newer one than 280.36, but thanks for letting me know about .47. 280.26 didn't just get stuck for a "very long time" though. It was hours, I went to bed and came back and it was still there. Also, it seems the GTX460 is using more power than I remember, when I compared it back then with the 5770, even at idle.

[nevcairiel]

Originally Posted by Andy o

Tried 280.36 as well, same thing.

They only do very minor changes in the same release branch. If you want to test another driver, test 270 or 275.

Its known that they changed P-state handling in 280. Its also been confirmed by NVIDIA that the handling will return to a more conservative mode in 285, which should see its first beta within 1-2 weeks.

PS:
280.36 and 280.47 are OpenGL 4.2 developer drivers, they typically don't have any other changes except the new OpenGL support.

[CruNcher]

Though the crashs are for sure not Nvidias fault the stuck in some P-state mode might be but the crashs (due to the faster switching) are surely not they just hit a area where low quality non reference cards (or heavily overclocked) wouldn't survive anymore and now drive back, because of the massive (OC Gamer) feedback
I have no crash issues with my MSI 460 GTX Hawk and i saw no other 460 Hawk user reporting problems (non overclocked)

[nevcairiel]

Yeah its really only the factory OC cards that are having those issues.

[Andy o]

Thanks, I think I'll wait for 285, NV Inspector is working fine right now for it. Another thing I found was that now the driver is outputting 24-bit to my display, when months before when I was using it, it used to output 36-bit. I don't think it makes a difference though.

[Alexey1975]

Originally Posted by Andy o

... I found was that now the driver is outputting 24-bit to my display, when months before when I was using it, it used to output 36-bit.

Sorry, but HOW did you "found" it?

[CruNcher]

Not only that came look @ this http://developer.nvidia.com/nvidia-g...E2%84%A2-video

Im thinking about the Scenario for example Sending Lav Cuvid decoded frames directly into Quicksync for example

[nevcairiel]

GPUDirect is old news. Its only for Quadro/Tesla, and is only useful if you need to transfer data between GPUs, not between GPU<->CPU

[CruNcher]

GPUDirect for Video is new http://blogs.nvidia.com/2011/09/chec...e-at-ibc-2011/ and yes my example is like that GPU(NVidia)->Intel(Quicksync) low CPU overhead of course the overhead for Quicksync on the CPU would stay
Especially in situations the Intel GPU cant handle @ decoding anymore when using PP this could come handy

[nevcairiel]

Its not a feature for consumer use, its a API for other hardware developers to interface with the Quadro better. It will never be usable for what you seem to want to use it for. Not to mention that i doubt that you have a Quadro.
And its still old news, it was announced quite a while ago.

[nevcairiel]

Originally Posted by Andy o

OK, so I put back in my GTX 460, but I have the same problem as Thuan, after using CUVID and closing MPC-HC, my card stays in the P8 power state until I reboot the PC. Before playing the video, it returns promptly to P12, after, it doesn't. This is with 280.26 drivers on Win 7-64. Are all you guys using those drivers?

I found out why that's happening. Its madVRs fault.
The latest madVR version has a bug that hangs onto a reference to the video decoder, which causes the video decoder to never be completely destructed. In LAV CUVID case that means it'll hang on to the CUDA interfaces, which apparently cause it to keep the clocks up.

I'm preparing a new version with this behavior changed, by releasing all resources earlier in the process. This should eliminate the symptoms you're seeing, as well as fix a bug when you play too many videos (all resources are eaten up eventually)

Damn you madshi, this bug is getting annoying.

[nevcairiel]

LAV CUVID Decoder 0.13

0.13 - 2011/09/13
- Improved resource release behavior
- Improved VC-1 in EVO with pulldown flags

Download: Installer (32/64-bit, CUDA 4.0+) - 32-bit (CUDA 4.0+) - 64-bit (CUDA 4.0+) -- 32-bit (Older CUDA)

The resource fix solves a problem with madVR 0.74, which caused LAV CUVID to not properly release all resources, keeping the clocks of the card up, and eventually running out of resources, causing the decoder to not work anymore.
Note that this is a madVR bug, and may have other side-effects as well.

Anyhow, have fun with these.

[Xaurus]

Thanks nev!

When I open a "simple" 720p file (~4 mbit/s bitrate) with CUVID 0.13, I notice that the performance sticks at the highest level (p0?), ie. full 3D force.

The video engine load is about ~13% and the GPU load is ~3%.
Is it the decoder or the graphics driver that control the level needed?

It has run for 5 minutes now and still full force.

PS: This is with the new 285.27 drivers and I have set the application preference "Power Management Mode" to Adaptive.

PPS: I am not really worried about power consumption, this is more a scientific question as to whether it's supposed to be like this or not.

[nevcairiel]

CUDA seems to always force P0 mode for some reason.
I recommend to use NVIDIA Inspectors Multi Display Power Saver to force a lower P state. I just set it to limit it to P8 when running mpc-hc - but there are some more extensive rules you could employ to make the selection smarter.

[Andy o]

Thanks for the fix, NEv.

Originally Posted by Alexey1975

Sorry, but HOW did you "found" it?

My display (Pioneer KRP-500M) tells you the bit depth of the signal. FWIW, my 5770 is 30-bit, but again, I don't think higher-than 24 matters, at least not yet.