Forum > GPU crunching
Unified installer add flops
efmer (fred):
--- Quote from: Richard Haselgrove on 06 Dec 2009, 07:15:23 am ---
--- Quote from: Jason G on 06 Dec 2009, 05:36:10 am ---Have been thinking about *something* along those lines, so it must be a good idea :P. It's on a pretty long list of stuff that needs looking at ... Have not managed to work out how to best determine a default entry ... I'm hoping to avoid having to parse boinc state files (as they can be problematic for a few reasons) and installer parsing capabilities aren't easy to program.
--- End quote ---
Agreed, parsing state files is a pain. The 'correct' way to do it within BOINC would be a GUI_RPC: but - I've just done one with <get_host_info> (against v6.10.21), and it only mentions the CPU. No reference to the CUDA card at all!!
Fred - please check and confirm: they've forgotten to add any GPU information to the standard GUI_RPC calls (<get_state> says nothing either). I'll check with DA, too.
Pending that, there is no way of getting GPU information even by file parsing - it would have to be direct detection. I would suggest it would be better to query the card(s) directly for shaders/speeds/compute capability, and impute a figure from that - like the old BOINC 'est flops' figure, peak is useless - rather than working from a look-up list which would be difficult to maintain and go rapidly out of date.
--- Quote from: Jason G on 06 Dec 2009, 05:36:10 am ---It might be best to leave that to a separate small GUI app (perhaps optionally installed in installer & run after setup. ) which could be run even sometime after installation (for 'recalibration' to new hardware etc, could evolve into kindof a control panel applet or similar). If that looks like the way to go (when I get to it), then I'll lliase with Richard Haselgrove on the latest best defaults. Since I've been preoccupied with my own 'fiddling', rather than concerned with how flops is dealt with now that new Boinc versions seem to have multipled the performance of my card by five for no apparent technical/practical purpose other than marketing ::).
Jason
--- End quote ---
Happy to work with you on it when the time comes. Remember also that effective flops are strongly dependent on the version of the CUDA .DLLs in use, and judging by recent reports, driver version as well (195.xx on Win7 is horribly slow, I read - but that may just be FUD).
--- End quote ---
I checked the source for the GET_HOST_INFO and it only has information about the CPU stored.
There is some info in the message log, that can be read by RPC calls, but you can only do that after stopping and restarting the BOINC client.
But I don't know how accurate this info is.
Do you know of any plans of making the GPU processing self learning. e.g. add a separate correction factor in the BOINC Client. That would be the best way to go.
Otherwise there are several options, one is read the capabilities of the card directly and make a calculated guess of the actual flops to fill in the xml file.
And I have noticed a performance difference in XP and WIN 7 that is considerable, maybe 10 - 20%. But that will improve after they have solved the problem of making it work at all.
Richard Haselgrove:
--- Quote from: Fred M on 06 Dec 2009, 07:57:48 am ---I checked the source for the GET_HOST_INFO and it only has information about the CPU stored.
There is some info in the message log, that can be read by RPC calls, but you can only do that after stopping and restarting the BOINC client.
But I don't know how accurate this info is.
Do you know of any plans of making the GPU processing self learning. e.g. add a separate correction factor in the BOINC Client. That would be the best way to go.
Otherwise there are several options, one is read the capabilities of the card directly and make a calculated guess of the actual flops to fill in the xml file.
And I have noticed a performance difference in XP and WIN 7 that is considerable, maybe 10 - 20%. But that will improve after they have solved the problem of making it work at all.
--- End quote ---
Yes, I checked those sources as well before asking my calculatedly-naive question on boinc_alpha. Sometimes the simplest questions have the biggest sting in the tail.
I think the start-up message log is a dead-end - not the way to go all all. The information is accurate, but summarised and badly structured - parsing it would involve detecting whether it came from a client reporting 'real' flops or 'marketing' flops, and applying different correction factors to each. David should respond to my question with an 'ooops', and I could ask him to code, as far as possible, the raw technical details returned by the GPU's API.
As regards self-learning: yes, it's been requested many times - basically, to record and maintain TDCF at the app_version level - and agreed in principle many months ago. But boring chores like this tend to get pushed to the back of the development queue. We've had the whole facebook cycle, and the ATI management, before the basic functions are properly debugged. At the moment, I'm pushing him quite hard on debt management (affecting work fetch and task switching), which is still fubar'd 50 weeks after the public CUDA launch.
Richard Haselgrove:
Jorden has reminded us that you can get a sneak preview of the fields that should be in the RPC by looking at a project sched_request.xml file.
efmer (fred):
--- Quote from: Richard Haselgrove on 06 Dec 2009, 08:54:31 am ---Jorden has reminded us that you can get a sneak preview of the fields that should be in the RPC by looking at a project sched_request.xml file.
--- End quote ---
There is a flops value in the file, per application. But it can be the manually placed value or the system value.
And the original system value is about a factor 10 off from the one it should be on my system.
Another problem is that you have to be lucky enough, that there is a cuda task in the scheduler file.
Jason G:
--- Quote from: Fred M on 06 Dec 2009, 12:04:50 pm ---There is a flops value in the file, per application. But it can be the manually placed value or the system value.
And the original system value is about a factor 10 off from the one it should be on my system.
Another problem is that you have to be lucky enough, that there is a cuda task in the scheduler file.
--- End quote ---
Just thinking, another option is to obtain/calculate the values we need programmatically through CudaAPI.
Not sure what Boinc uses now, but IIRC the first releases that supported Cuda derived a value from the clocks & number of multiprocessors.
I think it may be most reliable if we calcuate it ourselves and scale as required. Being independant of Boinc, it should be simpler than processing Boinc files that may be subject to change in content or backend value/meaning per Boinc version.
The other appeal , to me, is that it should (at least partially) work for unknown/unlisted/unreleased cards, which might be an advantage over using lookup tables too ( less maintenance, i.e. not having to make a new release everytime nVidia releases/renames a card) ... it should also account for OC.
Thoughts ?
[Later:] I guess ATI would have it's own similar api method/needs ... for CPU some tiny timed calculation might be sufficient, but as an option can always implement the same bench as used by boinc (a fairly easy initial option, even if we didn't end up sticking with it as is).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version