NvAPI looks promising. The official doc is here: http://developer.nvidia.com/nvapi
However - inexplicably - it seems to exist only for Windows. Anyway, I'll investigate using NvAPI after 7.0 is out. -- David On 28-Mar-2012 6:34 AM, Richard Haselgrove wrote: > I see you've updated the cores_per_proc to 192 - sorry about that. > > Regarding the API - my attention has been drawn to > https://code.oregonstate.edu/svn/gamercise/Project/StereoBranch/Depends/include/nvapi.h > > which includes - a long way down - a declaration for > NvAPI_GPU_GetGpuCoreCount > > I'm a bit worried about "no NVIDIA GPU *driving a display* was found", in > case it rules out Tesla. We've identified a tester with access to a tesla: > although workplace policies prevent him running SETI on it, we're hoping > he'll be able to run some test software with the NvAPI code. > > With regard to NvAPI_GPU_GetAllClockFrequencies, I'm hearing on the grapevine > that the CUDA 4.2 SDK is now available to registered developers with a valid > NDA. Unfortunately, the developers in question are too busy with their own > code to post here (even those coding science apps for the BOINC platform), > and because I haven't got my own NDA (I'm not a developer at that level), > they can't tell me what they're reading. But you might be able to find > something there that Google can't. > > I'll cross-post this to the boinc_projects list, in the hope that a project > developer can get you up to speed (pun intended) on the Kepler before Rom > tags and builds for v7.0.24 > > >> The 50 GFLOPS is the default when BOINC can't figure out anything else. >> This was the case because it didn't have any code for compute capability >> 3.x. >> >> I added the following to COPROC_NVIDIA::set_peak_flops(): case 3: default: >> flops_per_clock = 2; cores_per_proc = 128; I don't know if these are >> correct. It's too bad that NVIDIA doesn't have an API for getting these. >> >> Clock rate: the client uses a function called cuDeviceGetAttribute() to get >> it. NvAPI_GPU_GetAllClockFrequencies returned zero hits on Google. >> >> -- David >> >> On 23-Mar-2012 4:03 PM, Richard Haselgrove wrote: >>> Intial deliveries of the new card arrived at UK homes today. >>> >>> The good news: a volunteer has been performing offline testing for us, >>> and from the evidence so far there is no sign of any incompatibility with >>> the SETI v6.10 cuda_fermi application, of the kind which caused >>> scientific inaccuracies when the earlier v6.09 cuda23 application was run >>> on Fermi hardware two years ago. >>> >>> The bad news: BOINC itself doesn't fare so well. Our volunteer has passed >>> me these startup logs. >>> >>> 23/03/2012 14:12:49 | | Starting BOINC client version 6.12.34 for >>> windows_x86_64 23/03/2012 14:12:49 | | OS: Microsoft Windows 7: Ultimate >>> x64 Edition, Service Pack 1, (06.01.7601.00) 23/03/2012 14:12:49 | | >>> NVIDIA GPU 0: GeForce GTX 680 (driver version 30110, CUDA version 4020, >>> compute capability 3.0, 2048MB, 361 GFLOPS peak) >>> >>> 23/03/2012 19:26:49 | | Starting BOINC client version 7.0.18 for >>> windows_x86_64 23/03/2012 19:26:49 | | OS: Microsoft Windows 7: Ultimate >>> x64 Edition, Service Pack 1, (06.01.7601.00) 23/03/2012 19:26:49 | | >>> NVIDIA GPU 0: GeForce GTX 680 (driver version 301.10, CUDA version 4.20, >>> compute capability 3.0, 2048MB, 1899MB available, 50 GFLOPS peak) >>> 23/03/2012 19:26:49 | | OpenCL: NVIDIA GPU 0: GeForce GTX 680 (driver >>> version 301.10, device version OpenCL 1.1 CUDA, 2048MB, 1899MB >>> available) >>> >>> His feeling is that 361 GFLOPS peak under BOINC v6.12.34 is an >>> under-estimate, and 50 GFLOPS peak under BOINC v7 is certainly wrong. >>> >>> We need a handler for CC 3.0, and some numbers to plug into it. >>> >>> In code, he is getting >>> >>> prop.major == 3 prop.minor == 0 >>> prop.clockRate == 705500 CU_DEVICE_ATTRIBUTE_CLOCK_RATE >>> prop.multiProcessorCount == 8 >>> CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT >>> >>>> From >>>> http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf, >>>> I'm reading that same multiprocessor count, and the suggestion that >>>> cores_per_proc should be 128 - though that doesn't square with the >>>> advertised total shader count of 1536. >>> >>> There seems to be a problem with speed detection too - the detected 705.5 >>> MHz is also below the advertised rate. >>> >>> Again, I'm advised that *with effect from NV API 295*, the call to >>> "NVAPI_GPU_GetPerfClocks doesn't return correct information anymore, you >>> need to switch to the new NvAPI_GPU_GetAllClockFrequencies function". >>> That suggests that, where available, the new call should be used - though >>> the details of the call specification may still be restricted to NDA >>> documentation - but the older code path needs to be retained for legacy >>> compatibility on hosts with older driver versions. >>> >>> _______________________________________________ boinc_alpha mailing list >>> [email protected] >>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha To >>> unsubscribe, visit the above URL and (near bottom of page) enter your >>> email address. >> _______________________________________________ boinc_alpha mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha To unsubscribe, >> visit the above URL and (near bottom of page) enter your email address. >> > _______________________________________________ boinc_projects mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects To unsubscribe, > visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
