Forum > GPU crunching
GTX 460 superclocked
Ghost0210:
Just to clarify, EVGA can't report or read a Core clock speed on this card
GPU-z reports the following:
GPU Clock = 608 Mhz
Memory = 802 Mhz
Shader = 1215 Mhz
EVGA reports the same figures as GPU-z omitting the GPU clock figure. nVidia's performance tool reads the same.
But this still leaves the question, where is Boinc reading the 3200Mhz and the 810Mhz from in the stderr text. The effective memory clock of the 465 is rated at 3.2Ghz (4*802mhz), so it still looks to me (as a complete novice in how Boinc gets these figures), that Boinc is reading the wrong clock on this chip as it can't read the correct figure through the API if it is the core clock that is supposed to output to the stderr.
I'm making a lot of assumptions here as I don't have enough knowledge of this to make informed judgements, but it does seem logical to me that Boinc is having issues trying to decipher the API, or the hard coded values
Jason G:
--- Quote from: Richard Haselgrove on 01 Aug 2010, 09:52:50 am ---...for Compute Capability 2.1...
--- End quote ---
I'd like to know where this figure comes from if you could direct me to that. I have no Cuda documentation even indicating the existence of this compute capability 2.1, nor how many cores on the die etc. So someone either has information not available even to registered nVidia early access program developers, NDA or otherwise ... presumably by looking in the drivers/control panel which may not be quite right yet.
I reckon the figure of 48 might be questionable, since that would be 1.5 warps which would require an extra warp scheduler, or extension of the existing two to support 24 threads each... That isn't a power of two so it wouldn't make sense to make it that way in engineering terms, since hardware engineers only speak binary and hexidecimal ... with the odd exception of some sort of faulty chip harvesting.
I did mix up Ghosts 465, and TouchevGrey's 460 indeed, but the same possibility exists for the libraries reporting, not necessarily hard wired to one value, but broken or generically derived by formula not adapted for 465 or other new stuff. Also, I think these cards (465 & 460) represent the first the vendors are not forced to use a reference design, but can design their own boards. That opens the further possibility that the required custom BIOSes aren't all using the same mechanisms as nVidia reference ones, so will probably be the subject of either driver, library or firmware updates as time goes on.
--- Quote ---...But this still leaves the question, where is Boinc reading the 3200Mhz and the 810Mhz from in the stderr text....
--- End quote ---
I still reckon something's broken :D [That's the same 810000 shown on my 480... a default of some sort I reckon. For the 3200 Some addition to the GPU properties retrieved by the library might have shifted the data elements one space in the data structure ... They are kindof nearby, so it'd be a fairly simple task to mess up the properties parsing in the Boinc code ... checking ]
Ghost0210:
--- Quote from: Jason G on 01 Aug 2010, 10:16:03 am ---
I still reckon something's broken :D [That's the same 810000 shown on my 480... a default of some sort I reckon. For the 3200 Some addition to the GPU properties retrieved by the library might have shifted the data elements one space in the data structure ... They are kindof nearby, so it'd be a fairly simple task to mess up the properties parsing in the Boinc code ... checking ]
--- End quote ---
Got to agree that something is broken, all the figures indicate (to me atleast) that the 810 and the 3200Mhz figures are either defaults as you said, or Boinc is reading the wrong clock speed (memory instead of core).
The good news is that this doesn't affect the actual speed of the card, but it would be nice to have the correct figures reported ;)
Jason G:
Just looked at (more) Boinc code. To get the attributes it is using the driver api ( nvcuda.dll ) which is installed along with the driver, instead of the cuda runtime ( cudart...DLL) the app uses.
Probably means the parameters will magically fix themselves with a driver update ;) I can't see any problems with how Boinc gets the driver API function entry points, nor how it chooses the attributes to get (eliminated the dodgy data structure parsing suspect).
Jason
Ghost0210:
Good news on that one then. It eliminates any issues with the Boinc source code and hopefully it shouldn't be too much longer till a fresh driver is released onto us
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version