The author of another very nice and powerful monitoring tool under Win, HWiNFO64, is active on another message board. He's very helpful, so it might be a good idea to ask him. PM me if you want me to forward him your contact details :)
- As far as I know the severe performance drop with 319.x and subsequent drivers only affects linux.
MrS
The performance drop shows in Windows 319.x drivers as well but it's not severe, just a small step backwards. Driver tests have been run at a@h over the past week and the results can be seen here.
Maybe the perkit has some way of turning it back on.
That's pretty much what I discovered. You can get a lot of info (temps, fans, clocks, bus state, cores, RAM, etc.) using nvidia-settings. This command will present a headline list:
nvidia-settings -q all | grep Attributes | less
The NVML does have accounting API calls, but documented as Tesla/Quadro only.
The perfkit is Windows-only at present, and from the looks of it may bypass the driver (see diagram in the pdf, showing how the components fit together).
I'll do some more research and start a separate thread if anything useful turns up.
Addendum: After some research it seems likely that GPU-Z (& hwinfo?) uses the function 'NvAPI_GPU_GetDynamicPstatesInfoEx' to get the percentage load for each GPU. However as neither this API nor perfkit is currently available for linux, for now some other approach is needed.
Addendum: After some research it seems likely that GPU-Z (& hwinfo?) uses the function 'NvAPI_GPU_GetDynamicPstatesInfoEx' to get the percentage load for each GPU. However as neither this API nor perfkit is currently available for linux, for now some other approach is needed.
Yes, I do use that function. I don't know about any alternate method (i.e. direct register access).
The performance drop shows in Windows 319.x drivers as well but it's not severe, just a small step backwards. Driver tests have been run at a@h over the past week and the results can be seen here.
Thanks for that information! At GPU-Grid a small performance increase was observed going from 320.49 to 326.80 - could be back again at 314.22 levels now if it's also present at Einstein.
Some progress: On Linux, as reported in other threads here, the new beta driver 331.xx seems to work fine again with E@H apps w/o the previously observed performance issues. So we now seem to have working drivers under Windows and Linux to test CUDA 5.5 apps under. First tests that I did on a single Linux machine indicate that a CUDA 5.5 BRP app performs ca 15% faster on a Kepler GPU than the current, CUDA 3.2 app on that same hardware and driver, so this is promising enough to further investigate. Together with an additional speed-up that seems to be caused by the driver update alone (under Linux at least), teh overall speed-up of using a CUDA 5.5 app and the latest driver could be as high as 30% on some systems.
So finally we are GO for CUDA 5.5 and will release, in the near future, a test app on Albert. We will still have to also keep the legacy CUDA 3.2 app for hosts with older drivers, so the test on Albert is needed to make sure that results from the new CUDA 5.5 and old 3.2 apps validate against each other.
So finally we are GO for CUDA 5.5 and will release, in the near future, a test app on Albert. We will still have to also keep the legacy CUDA 3.2 app for hosts with older drivers, so the test on Albert is needed to make sure that results from the new CUDA 5.5 and old 3.2 apps validate against each other.
Cheers
HBE
Good news that.
In my logs I am seeing
[18:03:41][17896][INFO ] Version of installed CUDA driver: 6000
[18:03:41][17896][INFO ] Version of CUDA driver API used: 3020
So are we looking at a (not officially released but maybe we have released) beta version of CUDA 6.0 ?
RE: The author of another
)
Actually, it's me ;-)
-----
RE: - As far as I know the
)
The performance drop shows in Windows 319.x drivers as well but it's not severe, just a small step backwards. Driver tests have been run at a@h over the past week and the results can be seen here.
Gord
RE: I spent a little time
)
That's pretty much what I discovered. You can get a lot of info (temps, fans, clocks, bus state, cores, RAM, etc.) using nvidia-settings. This command will present a headline list:
nvidia-settings -q all | grep Attributes | lessThe NVML does have accounting API calls, but documented as Tesla/Quadro only.
The perfkit is Windows-only at present, and from the looks of it may bypass the driver (see diagram in the pdf, showing how the components fit together).
I'll do some more research and start a separate thread if anything useful turns up.
Addendum: After some research
)
Addendum: After some research it seems likely that GPU-Z (& hwinfo?) uses the function 'NvAPI_GPU_GetDynamicPstatesInfoEx' to get the percentage load for each GPU. However as neither this API nor perfkit is currently available for linux, for now some other approach is needed.
RE: Addendum: After some
)
Yes, I do use that function. I don't know about any alternate method (i.e. direct register access).
-----
RE: The performance drop
)
Thanks for that information! At GPU-Grid a small performance increase was observed going from 320.49 to 326.80 - could be back again at 314.22 levels now if it's also present at Einstein.
MrS
Scanning for our furry friends since Jan 2002
Hi! Some progress: On
)
Hi!
Some progress: On Linux, as reported in other threads here, the new beta driver 331.xx seems to work fine again with E@H apps w/o the previously observed performance issues. So we now seem to have working drivers under Windows and Linux to test CUDA 5.5 apps under. First tests that I did on a single Linux machine indicate that a CUDA 5.5 BRP app performs ca 15% faster on a Kepler GPU than the current, CUDA 3.2 app on that same hardware and driver, so this is promising enough to further investigate. Together with an additional speed-up that seems to be caused by the driver update alone (under Linux at least), teh overall speed-up of using a CUDA 5.5 app and the latest driver could be as high as 30% on some systems.
So finally we are GO for CUDA 5.5 and will release, in the near future, a test app on Albert. We will still have to also keep the legacy CUDA 3.2 app for hosts with older drivers, so the test on Albert is needed to make sure that results from the new CUDA 5.5 and old 3.2 apps validate against each other.
Cheers
HBE
Great news! Any results from
)
Great news!
Any results from a CUDA 5.5 run on Windows?
-----
RE: So finally we are GO
)
Good news that.
In my logs I am seeing
[18:03:41][17896][INFO ] Version of installed CUDA driver: 6000
[18:03:41][17896][INFO ] Version of CUDA driver API used: 3020
So are we looking at a (not officially released but maybe we have released) beta version of CUDA 6.0 ?
I spied this as well over at gpugrid about 331.xx http://www.gpugrid.net/forum_thread.php?id=3493
RE: So are we looking at a
)
Yep, early access testing of the new major version, supposedly 6.0, will start after Nov., 1st.
Oliver
Einstein@Home Project