ATI 'Crossfire' practical issues

[Dave Baumann]

They are naming convention cock-up modes. (Although they are done to make it a little easier for the end user to understand, which is a little understanable to some degree)

 

[Geo]

So we're thinking (to use NV terms) 8Xs and 12Xs? Rather than, say, Temporal with each card doing one pattern (tho I suppose that wouldn't work for tiling mode).

Where's that 14 coming from then?

 

[Blazkowicz]

So we're thinking (to use NV terms) 8Xs and 12Xs? Rather than, say, Temporal with each card doing one pattern (tho I suppose that wouldn't work for tiling mode).

Where's that 14 coming from then?

pullet out of the Inqu's (enormous) ass?

Temporal AA with each other card doing the pattern is nothing special, you'll do that with AFR and enabling the current "Temporal 2T" so it would be done with nothing new
I'm not fond of Temporal AA as it requires both Vsync and a high framerate.

of course you'll be able to do 12x with TAA 2T or 3T to get an awesomely inflated 24X or 36X AA (imagine HL1 mods with these settings ^^)

 

[Geo]

I'm not fond of Temporal AA as it requires both Vsync and a high framerate.

Yeah, well I was hoping the "high framerate" part would be a given in a dual-R520!

 

[Blazkowicz]

but the CPU has to keep up, ideally if you run at 85Hz you have to maintain a consistent 85fps or higher.
(which should be easy on "old" games )

 

[jvd]

Because the hardware obviously wasn't layed out for it. Both SLi and MVPU use specialized hardware; GPUs have to be either "SLi-" or "MVPU-ready".

SLi isn't just a "bridge" between the cards and a driver as isn't MVPU just a cable between the GPUs + driver

the current sli from nvidia isn't capable of it but how about the newer cards . I'm talking about going foward starting with mvp

 

[Ailuros]

Because the hardware obviously wasn't layed out for it. Both SLi and MVPU use specialized hardware; GPUs have to be either "SLi-" or "MVPU-ready".

SLi isn't just a "bridge" between the cards and a driver as isn't MVPU just a cable between the GPUs + driver

the current sli from nvidia isn't capable of it but how about the newer cards . I'm talking about going foward starting with mvp

I'm confused. You asked me about R3xx boards and MVPU.

AFAIK MVPU will be from R4xx and onwards.

 

[Ailuros]

They are naming convention cock-up modes. (Although they are done to make it a little easier for the end user to understand, which is a little understanable to some degree)

What would stop ATI to use a similar mode as on simFusion boards, where geometry won't scale yet AA samples per chip?

 

[Basic]

Identical frequencies have to be a presupposition; you can't have two GPUs sharing a frame or render alternating frames when they run at different frequencies.

Of course you can. That spec is one of the easiest to have different on the two cards.

 

[KimB]

Identical frequencies have to be a presupposition; you can't have two GPUs sharing a frame or render alternating frames when they run at different frequencies.

Of course you can. That spec is one of the easiest to have different on the two cards.

Well, sure, it'd be easy to run. But it would still run like crap.

 

[Ailuros]

Identical frequencies have to be a presupposition; you can't have two GPUs sharing a frame or render alternating frames when they run at different frequencies.

Of course you can. That spec is one of the easiest to have different on the two cards.

I'd love to hear how you'd handle load balancing with different frequencies, without any side-effects. Anything that doesn't work 100% troublefree isn't debatable. Yes it's an honest question.

 

[Demirug]

Identical frequencies have to be a presupposition; you can't have two GPUs sharing a frame or render alternating frames when they run at different frequencies.

Of course you can. That spec is one of the easiest to have different on the two cards.

I'd love to hear how you'd handle load balancing with different frequencies, without any side-effects. Anything that doesn't work 100% troublefree isn't debatable. Yes it's an honest question.

In the same way you can do it with equal frequencies. A dynamic load balancing that measure the time differcence between the "frame ready" signals to rebalence the workload will not care about different frequencies.

At least this is not an ATI only problem. nVidia will face it too after they allow different overclocking settings for each card in a SLI configuration.

 

[Basic]

Yep, just like Demirug says.

If it's vertex limited and both cards need to transform all geometry, then you'll have a bottleneck in the slower card. But you'd still be able to run them at different clock. When they aren't geometry limited, there's no problem.

Anything that doesn't work 100% troublefree isn't debatable.

That's a rather ridiculous stance, since NO multi-GPU method is 100% trouble free.

 

[Charmaka]

Identical frequencies have to be a presupposition; you can't have two GPUs sharing a frame or render alternating frames when they run at different frequencies.

Of course you can. That spec is one of the easiest to have different on the two cards.

I'd love to hear how you'd handle load balancing with different frequencies, without any side-effects. Anything that doesn't work 100% troublefree isn't debatable. Yes it's an honest question.

[standard "I r dumb" disclaimer]

Going back to the tiling thing mentioned a few pages back, wrt multiple cards with different performances etc, surely the easy solution is just for the driver to have a table listing per-quad effective fill-rate (or whatever measure you want to use) for each card and a simple algorithm to work out the tile order based on this? So if you have card X and card Y, and card X has four quads at speed 1.25 while card Y has three quads at speed 1.0, then card X can do 4*1.25 for every 3*1 card Y can do, giving you a 5:3 workload ratio between cards. That way, LtR your ideal order for (X) tiles will be something like this:
Q1Q5Q2Q3Q6Q4Q7Q1|Q2Q5Q3Q6Q4Q1Q7Q2|
And so on, where the bold quads are card one. (I'm simply laying quads from each card sequentially; there may be a more optimal way). That should give you instant load-balancing between cards of different powers with zero overhead while it's running and while keeping the balancing benefits of tiling. Or did I miss something important?

?