Get your votes in early ...

I just installed an ATI HD4870 to match my existing HD4870 though the memory sizes are different ... I posted a note regarding the way BOINC reports this. And Rom replied thusly:

Asymmetric GPUs from the same vendor is currently not supported.

The reason both or your GPUs are showing up instead of just the most
capable is because you have the <use_all_gpus/> flag specified in your
cc_config.xml file.

At this time we do not know if/when we'll support the Asymmetric GPU
from the same vendor scenario.

You are going to have to eventually for the simple reason that people, particularly for the wider rigs are not going to be able to upgrade 3-4 GPUs necessarily at the same time...

Even worse, models are dropped and in essence you are going to be telling people that when they want to upgrade and fill a slot and the old model is no longer available that they have to junk a perfectly good card? Not a good move ...

Anyway, please make your objections known on the Alpha list or you are going to be stuck ... forewarned ...

Jack,

I love the rain ...

I will agree there are points at which it may be impractical. I stress MAY! But, in that the basic model of BOINC is one task per processing unit (with some coming exceptions) I am not at all convinced that even your example is not a problem.

I ran a GTX280 and 9800GT with a factor of 3 difference in speed side by side for most of last year with no issues. I know UCB does not want to touch this, heck what issue do they want to touch ... but ... with the one task per GPU I will be honest with you ... I cannot conceive of why it should be an issue. The tasks on the 9800 took 17 plus hours to run and on the 280 about 6 ... so I have had a different experience than you ... and with at least three driver "generations" because I have had several cycles of upgrades (though the 9800 is now on the sidelines) ...

I know that their option is easier ... but if it were easy anyone could play ...

Though the accusation is that I think only I know what is best ... the truth is that I want the best overall options for all ... I think that the draconian policies adopted by UCB are bad and this is just another case where the cure may be worse than the problem ... so, by all means raise your points ... and be sure to also rebut me on the mailing list or UCB will not know that you support their position ... just be sure that you want to never be able to run cards with any differences between them in your rigs ... because that is what their rule is ... no differences of any kind ... and good luck finding that exact card a year or two from now ... :)

{edit}

Last note, silence on this matter UCB will take as consent ... or that no one objects, besides me, to this policy ... stay silent now and you will have to live with it the next time you want to upgrade your GPUs ...

Paul,

Unfortunately, I know more than I can say. As I mentioned in another thread, I'm under a NDA, which is why I gave a (third hand) folding example, rather than first hand experience.

There are/were 2 issues.

Mismatched shader count. (Which caused an issue even on same gen hardware, eg. between 2x GTX260's in the same machine. ie. 192 shader count model and later revision with 216 shader count. At best 216 shader count 260 would run at lower shader count card speed, at worst unexplained errors.)

Mixing hardware with different compute capability. 200 series and 1st CUDA gen 8800 is a classic failure example.
____________
Crunching on Linux: Fedora 11 x86_64 / nVidia 185.18.36 driver / CUDA 2.2

Paul,

Unfortunately, I know more than I can say. As I mentioned in another thread, I'm under a NDA, which is why I gave a (third hand) folding example, rather than first hand experience.

There are/were 2 issues.

Mismatched shader count. (Which caused an issue even on same gen hardware, eg. between 2x GTX260's in the same machine. ie. 192 shader count model and later revision with 216 shader count. At best 216 shader count 260 would run at lower shader count card speed, at worst unexplained errors.)

Mixing hardware with different compute capability. 200 series and 1st CUDA gen 8800 is a classic failure example.

But when Rom indicates that the plan and the code they are putting in place is intended to support one ATI card and one Nvidia card and or some other combinations (not sure if they would support one ATI card with a pair of GTX260s or not) ... but if that is not supporting mismatches I don't know what is ...

But when Rom indicates that the plan and the code they are putting in place is intended to support one ATI card and one Nvidia card and or some other combinations (not sure if they would support one ATI card with a pair of GTX260s or not) ... but if that is not supporting mismatches I don't know what is ...

Where is this discussion taking place, the dev list?

boinc_alpha, thread "Memory, oh the memories"

Get your votes in early ...

I just installed an ATI HD4870 to match my existing HD4870 though the memory sizes are different ... I posted a note regarding the way BOINC reports this. And Rom replied thusly:

Asymmetric GPUs from the same vendor is currently not supported.

The reason both or your GPUs are showing up instead of just the most
capable is because you have the <use_all_gpus/> flag specified in your
cc_config.xml file.

At this time we do not know if/when we'll support the Asymmetric GPU
from the same vendor scenario.

I suggested that this is a bad idea:

You are going to have to eventually for the simple reason that people, particularly for the wider rigs are not going to be able to upgrade 3-4 GPUs necessarily at the same time...

Even worse, models are dropped and in essence you are going to be telling people that when they want to upgrade and fill a slot and the old model is no longer available that they have to junk a perfectly good card? Not a good move ...

Understand clearly what this means, if you have a 3 GPU system their expectation is that all three will be same make, model, and internals... In that GPU cards in the same model line don't always stay the same from one year to the next this is an impossible standard to meet ... unless you have way more money than I and can afford to buy your GPU sets all on the same day ...

I pointed out that this asymmetry was inevitable last year, that GPU installations are more than likely going to be asymmetric than not for many people ... but UCB in cloud land is going to expect that if you want to run GTX295 cards or HD5870s you are going to buy them in batch lots ... I don't know about you ... but I don't always have $1,500-$2,000 to spend all in one swell foop ...

Of course, you can just let the least capable, that is all those GPUs that don't match the top one, sit idle ... won't that be fun ...

Anyway, please make your objections known on the Alpha list or you are going to be stuck ... forewarned ...

I usually agree with you, but not sure on this issue.

You typically would not put two dissimilar CPUs in a dual-socket mobo and I think SLI wants to see two virtually identical GPUs.

"They" have enough problems fixing BOINC for simple systems.

I saw that on the test msgs.

Still doesn't make sense to me to try for a more complex integration when "they" haven't got it right with two of the same.

In my mind it is better to limit configuration possibilities. I mean we don't expect mobo mfgs to accommodate a RAM config of three disparate types of memory chips.........you use two or three of the same chip for memory channels. I haven't seen any recent autos that allow a motorcycle tire and a tractor tire on one side of the car and a pair of airplane landing tires on the other side and it doesn't make sense to try.

So far my installs are just single GPUs and I'd like to see the efforts expended towards getting the basic CPU/GPU config working first.

I saw that on the test msgs.

Still doesn't make sense to me to try for a more complex integration when "they" haven't got it right with two of the same.

It would be a nice to have, but as the other guys have said I think they need to get things working properly to start with, before we try and handle different cards from the same vendor.

My personal opinion is they should treat gpu tasks the same as cpu tasks and swap out as needed, honour TSI and so on. We haven't got to that point yet.

That is the joke, they are saying that the ATI / Nvidia mode is supported but not two cards from the same MFGR with a difference in memory size ... it is looney toons ...

I am aware of the "Use All" flag and use it now.

I am aware of the potential issues of having to schedule the resources separately. In fact, LAST YEAR I was warning UCB that this was an issue ... another case where I was told that it was not a problem. WHen small issues came up because UCB wrote the initial CUDA code with no regard to these issues that was the start of the if they are not identical use only the best one concept.

Sorry guys, another case of "I don't want to hear it because I know better itis ..." and as usual the first reaction to a mistake on their part is to cripple the sources that might give rise to the issues.

Had they bothered to listen, the infrastructure for different size/class cards would already exist. I would mind less bugs in that then this pretense that this was not an issue that could be anticipated.

Secondly, the mechanisms to handle cards from two MFGRs are basically the same as needed to handle two cards from the same MFGR that have different capabilities. As to the things that needs to be tracked... well, that is what they get paid for...

MarkJ is correct that there are significant differences and that there is need to program for them. Some work is more appropriate to run on one card vs another. If anything I would comment that he missed a couple possible additional features like memory bandwidth, bus bandwidth, memory speed, linked (or not, assuming that linked cards can be both applied as linked to a single task to improve speed) ... but that is not the point. The point is that before we even got to adding ATI cards we could have been debugging those issues that might arrive with the already existing asymmetric CUDA installations (I had one myself)...

Tackling the within family problem first is also more logical because it is far more likely to be the normal situation. User buys card ... user buys faster card and links it to have better gaming ... user thinks that he can use this with BOINC ... user thinks UCB are idiots because thy did not think of this ...

If on the other hand I could sit down and tweak the code so it behaves better what is my cost/benefit? Next to nothing. I haven't improved my reach a great deal because I still don't support the other brand. Sure my product is better behaved and I can support more of the same brand, but there is less in that than getting the other brand supported.

Well I just found this thread... I have been running a machine with 1 9800gtx+ and 1 8800 gt for a couple of months now and as of last week I can only get 1 wu at a time, for the 9800. The 8800 no longer runs. Bummer. Since I can't run it anymore I will retire it. I just can't afford to buy $1800 of cards at a time. My car is worth less than that......

Well I just found this thread... I have been running a machine with 1 9800gtx+ and 1 8800 gt for a couple of months now and as of last week I can only get 1 wu at a time, for the 9800. The 8800 no longer runs. Bummer. Since I can't run it anymore I will retire it. I just can't afford to buy $1800 of cards at a time. My car is worth less than that......

Searching through MW forums, about new ATI / AMD GPU 5870\5850, was found quite interesting message posted by Verstapp.
Lets look, what he was found & shared with us:
http://www.theinquirer.net/inquirer/news/1557395/nvidia-bastille-stormed-hackers
Sure, this could add some thoughts.

Which is not the first time that ATI or Nvidia did something like that ... yet, Rom says that the UCB expectation is that mixed ATI and Nvidia installations are going to be easier to support ...

An idea I think UCB should consider: Support a list of GPUs, each with a database section describing the capabilities of that list item. Allow including clusters of GPUs that meet their expectations for matched types within that cluster. Include a mark on each one saying whether it is free for use, already in use, or possibly the user has marked it as not to be used now.

Give the CPU parts of workunits the capability of inspecting the entire list, and choosing at least one item on the list but not currently in use as something it wants to use, returning something saying there is something on the list it can use but it wants to wait until at least one more item on the list becomes free to use, or returning something saying there is nothing on the list it can use. If the CPU part of the workunit gets access to more than one item on the list, it then has the responsibility of dividing up the GPU part of the work among the different items, and possibly freeing some of them for other uses early if it decides not to use certain items this time at all.

That way, the CPU part of the workunit, and not BOINC, gets the responsibility of deciding what GPUs it can use, and can decide whether it is capable of using unmatched types at once.

Also allow the CPU part of the workunit to decide that that it wants to take responsibility for deciding how long to wait for something currently marked as not to be used becomes marked as available for use again.