More SLI

[trinibwoy]

Remember that you are not just load balancing the final pixels, but also other, off screen, ops such as render to texture. I would guess that the load balancinghere is more a case of trying to distribute difference offscreen ops to different boards (i.e. if there are two render to texture ops then have one board render one and the other board render another).

Hmmmm that's a whole other kettle of fish - off-screen ops being shared between the cards regardless of the affected on-screen location? Isn't that getting a bit complex? And wouldn't that generate a lot of extra traffic between the boards also?

 

[Dave Baumann]

FAQ's are your friend

Are render-to-texture operations accelerated with NVIDIA's SLI technology?
Yes.
NVIDIA's SLI technology automatically shares and distributes render-to-texture operations across multiple GPUs. There may be some synchronization and communications overhead associated with those operations; that overhead, however, is less than the overall performance boost enabled by multiple GPUs.

Are texture render-targets shared between the multiple GPUs?
Yes.
NVIDIA's SLI technology automatically shares and distributes render-target data across multiple GPUs as necessary.

However, you kind of have to do this to to get the best gains as you can - there may be some apps that actually spend the majority of their rendering time rendering to offscreen buffers, in which case not doing this would result in minimal gains in those cases.

 

[KimB]

Inter card bus? How? In fact, having one do les work than the other is likely to alleviate the work for the bus since (assuming the slower is the slave) there will be less screen drawn by the slave and less data to pass across.

I'm thinking in terms of combining the final frame for output to the monitor. There may be timing issues here in making sure that the data transfer doesn't happen while the relevant portion of the screen is being output to the monitor, for instance.

I don't think it could be load balancing, because the power of the respective cards would just be another variable (or matrix, if you want to get closer to accurate).

 

[Dave Baumann]

I'm thinking in terms of combining the final frame for output to the monitor. There may be timing issues here in making sure that the data transfer doesn't happen while the relevant portion of the screen is being output to the monitor, for instance.

As far as I'm aware the master board buffers the entire frame before output to the monitor. These "timing" issues is what the load balancing is there for in the first place since the very fact that one board is rendering the top half and the other board is rendering the bottom is likely to rsult in uneven loads which, in this respect is the same as having one board faster than the other.

I don't think it could be load balancing, because the power of the respective cards would just be another variable (or matrix, if you want to get closer to accurate).

Yes, this would be the case for load balancing of displayed frame buffer, but it would present more of an issue for ops where you don't have such fine control over load balancing.

 

[KimB]

Yes, this would be the case for load balancing of displayed frame buffer, but it would present more of an issue for ops where you don't have such fine control over load balancing.

I don't see why you wouldn't. As far as I know, the only render targets available are rectangular ones currently. We may get cube map render targets in the future, but until then, they should all be roughly identical in terms of load balancing.

As far as I'm aware the master board buffers the entire frame before output to the monitor. These "timing" issues is what the load balancing is there for in the first place since the very fact that one board is rendering the top half and the other board is rendering the bottom is likely to rsult in uneven loads which, in this respect is the same as having one board faster than the other.

I'm more talking about when the framebuffer is transferred. It seems to me that it would be very inefficient to transfer the framebuffer as it is being rendered (blends, overdraw, etc. will all lead to the same pixel being transferred multiple times), so you'd want to transfer it after rendering. The timing issues I'm referring to would be related to when this is transferred.

 

[Dave Baumann]

I don't see why you wouldn't. As far as I know, the only render targets available are rectangular ones currently. We may get cube map render targets in the future, but until then, they should all be roughly identical in terms of load balancing.

It depends on what "share and distributes" means - still does "SLI" or distributre different offscreen ops to different boards.

It seems to me that it would be very inefficient to transfer the framebuffer as it is being rendered (blends, overdraw, etc. will all lead to the same pixel being transferred multiple times), so you'd want to transfer it after rendering. The timing issues I'm referring to would be related to when this is transferred.

I thought this was a given - yes, all the operations are completed before the frame is "joined" and sent to the display. But these timing issues are no more of an issue for boards of different speeds than rendering different portions of the screen anyway.

 

[trinibwoy]

FAQ's are your friend
However, you kind of have to do this to to get the best gains as you can - there may be some apps that actually spend the majority of their rendering time rendering to offscreen buffers, in which case not doing this would result in minimal gains in those cases.

Ah I see. Thanks. Guess it doesn't require as much overhead as I (blindly) guessed.

 

[digitalwanderer]

Alienware is pimping an nVidia SLI set-up now....for only $6,077.00us.

 

[trinibwoy]

Alienware is pimping an nVidia SLI set-up now....for only $6,077.00us.

That's a steal considering their non-SLI setups are already $5,000. Why are you surprised?

 

[digitalwanderer]

Alienware is pimping an nVidia SLI set-up now....for only $6,077.00us.

That's a steal considering their non-SLI setups are already $5,000. Why are you surprised?

Because Alienware was pushing their proprietary dual ATi solution not too long ago.

 

[trinibwoy]

Because Alienware was pushing their proprietary dual ATi solution not too long ago.

Oh that. I thought your was for the price you quoted. Must mean that Nvidia's solution is either easier to put together, cheaper to build or just faster than their hybrid thing.

 

[ben6]

Hrm ATI supporting SLI in their own chipsets Hrm...

 

[Dave Baumann]

I can promise you, there won't be any "SLI".

 

[trinibwoy]

I can promise you, there won't be any "SLI".

Can you also promise that there won't be any "consumer technology involving multiple ATI GPU'S"?

 

[Raystream]

I can promise you, there won't be any "SLI".

When you say that do you mean there is no "SLI", but another type of multiple card setup working together? Or just nothing at all? Or is there something completely different coming from ATIs horizon?

Raystream

 

[Dave Baumann]

I think the relative noobs have some things to learn...

 

[Fodder]

Tiling or AFR?

 

[digitalwanderer]

When you say that do you mean there is no "SLI", but another type of multiple card setup working together? Or just nothing at all? Or is there something completely different coming from ATIs horizon?

Yes. 8)

I think the relative noobs have some things to learn...

Yes.

 

[Martin Eddy]

I think the relative noobs have some things to learn...

Don't worry, eventually they will get just as frustrated as the rest of us.

 

[NocturnDragon]

Well they still could come up with something MAXX

I can promise you, there won't be any "SLI".