nVidia Driver Poll

Kit wrote on 2/7/2014, 9:11 PM

I'd like to find out what nVidia Driver is currently most in use by forum frequenters. Thanks in advance. I was using driver 331.65 but recently got random screen flashes and windows messages about he driver stopping and recovering. Now I'm using:

GeForce GTX 550 Ti driver version: 314.22

Back to post

Comments

Adam QA SCS wrote on 2/12/2014, 12:44 PM

Lou,

Look at the other post that you made, I wrote a comment that may possibly help you.

Thanks,

Adam

bdg wrote on 2/12/2014, 1:31 PM

GTX 560 Ti
301.42 been running fine for several weeks.
These next two gave my screen "measles" (random coloured squares requiring either a warm boot or being "self recovered" by NVIDEA)
332.21
296.1

MikeLV wrote on 2/12/2014, 2:20 PM

Hi all, quick question about the nvidia driver. I'm using a GTX 570 with the 296.10 driver. I'm rendering a DNxHD file right now, and GPU-Z is only showing a 12-13% load. Does this mean that the encoder isn't using my GPU to its full capability or is that the extent to which it will work with the DNxHD codec? Thanks!

OldSmoke wrote on 2/12/2014, 2:27 PM

That is the extend to which DNxHD is supported. CUDA is only used for MCAVC and SONY AVC; all other codecs are using OpenCL. There is still some acceleration just not as much as with CUDA. To test DNxHD without acceleration, you would have to turn off GPU acceleration under preferences.

MikeLV wrote on 2/12/2014, 2:29 PM

I had a feeling the first reply was going to be from you, thanks again for clearing up my confusion; you seem to do that a lot! So if I render an MP4 from Handbrake, will it use CUDA, or only Vegas will use it?

Edit, rendering with handbrake now and there's no load at all on the GPU so that answers that question...

ddm wrote on 2/14/2014, 8:47 PM

Oldsmoke,

Ok, I ran GPU-Z on both the W7 and W8 side and the numbers seem to be identical, it also reports that my bus interface is PCI-e 2x16. My renders seem to fluctuate between a GPU load of 50 to 60 percent. Are you overclocking your video card? GPU-Z reports the following for my GTX 570:
GPU Core Clock: 50mhz
GPU Memory Clock: 67.5mhz
Shader Clock: 101mhz
Shaders 480 unified
Memory type GDDR5
Bus Width 320
Memory Size 1280 mb
Bandwidth 152 GB
GPU Clock 732 mhz
Memory 950 mhz
Shader 1464 mhz

When I run the Bus Interface test in GPU-Z the GPU load flat lines at 99%. Does anything look out of whack to you on those numbers?

Steve Mann wrote on 2/15/2014, 2:16 PM

Display driver stopped responding

Reference: http://msdn.microsoft.com/en-us/windows/hardware/gg487368.aspx
Gg487368.wddm timeout(en-us,MSDN.10).gif

Paraphrased from the Microsoft Developers Network website:
One of the most common stability problems in graphics is when the system appears completely "frozen" or "hung" while processing an end-user command or operation. It is possible that the GPU is "busy" processing intensive graphical operations. This results in nothing being updated on the screen, thus appearing to the user that the system is frozen.
Registry Keys for the Timeout Detection and Recovery
The TDR-related registry keys are located under HKLM\System\CurrentControlSet\Control\GraphicsDrivers.
TdrLevel: REG_DWORD. The initial level of recovery. The possible values are:
TdrLevelOff (0). – Detection disabled.
TdrLevelBugcheck (1) – Bug check on detected timeout, for example, no recovery.
TdrLevelRecoverVGA (2) – Recover to VGA (not implemented).
TdrLevelRecover(3) – Recover on timeout. This is the default value.
TdrDelay: REG_DWORD. The number of seconds that the GPU is allowed to delay the preempt request from the scheduler. This is effectively the timeout threshold. The default value is 2.
TdrDdiDelay: REG_DWORD. The number of seconds that the operating system allows threads to leave the driver. After a specified time, the operating system bug checks the system with the code VIDEO_TDR_FAILURE (0x116). The default value is 5.
TdrTestMode: REG_DWORD: Internal test usage.
TdrDebugMode: REG_DWORD: The debugging-related behavior of the TDR process.
TDR_DEBUG_MODE_OFF (0) breaks to kernel debugger before the recovery to allow investigation of the timeout.
TDR_DEBUG_MODE_IGNORE_TIMEOUT (1) ignores any timeout.
TDR_DEBUG_MODE_RECOVER_NO_PROMPT (2) recovers without break into the debugger. This is the default value.
TDR_DEBUG_MODE_RECOVER_UNCONDITIONAL (3) recovers even if some recovery conditions are not met (for example, recovers on consecutive timeouts).
TdrLimitTime: REG_DWORD (Windows Vista SP1 and later versions only): The default time within which a "TdrLimitCount" number of TDRs are allowed without crashing the system.
TdrLimitCount: REG_DWORD (Windows Vista SP1 and later versions only): The default number of TDRs (0x117) that are allowed in "TdrLimitTime" without crashing the system.

Try changing TdrDdiDelay to "10".

OldSmoke wrote on 2/15/2014, 3:15 PM

@ddm

No there is nothing wrong with your drivers. Your CPU just can't feed enough information to the GPU; that is as good as an i5 will do. The GPU can handle more load but there isn't enough coming. I could also be a board issue, some MB are not as good as others. I don't overclock my GPU in my current system In fact, I down clocked one of my GTX580 to match the second card; one is a EVGA Superclocked @797MHz and I down clocked it to 772MHz to match the other card. Surprisingly that worked better then oc the slower card. My explanation is that while you can over clock, you will hit a frequency where the two components exchanging information will have a lot communication errors that need constant correction and eventually slowing things down. Every system has a sweet spot but that isn't necessary the highest clock.
How many monitors do you have connected to your GTX570? If its only one, you have to make sure that the GPU clock changes when you open Vegas and playback the time line or do a render. Leave GPU-Z running and do a render, check that the card is running at full power and doesn't hang in one of it's low power states.