ATi Prepairing to Launch 3 Card System (2x Graphics 1x Physics)

That's rather boring isn't it? Don't we want more 'game-play critical objects'? The implication above is that 'game play objects' and 'large-scale world definitions' can't respond to gpu accelerated stuff.

Why are people excited about this, what am I not understanding?

 

Uhh, but it can accelerate "game play objects' and "large-scale world definitions." Or am I misunderstanding the quote?

 

Seems like physics has been bundled with the CrossFire group for marketing purposes at least (be interesting to know if they are sharing engineers as well). . . possibly as "cool extras" in rationale. Which possibly means a few things, but for the purposes of this threadlet probably explains why folks missed the minor key of "oh yeah, you can do it with two cards too". . . because the major key was clearly intended to show off three cards.

 

This sounds like a much better solution than the seemingly ill fated Ageia cards.

I have a crossfire board running 2 X1300pros
I could upgrade to a single X1900 and use an X1300 or X1600 for physics.

There is no technical reason for this not to work on SLI mobos either, though I doubt it will because of chipset lockouts. However, should ATI (and indeed nVidia) decide to release drivers purely for physics, I don't see how they could stop it working alongside an nVidia display card, or vice versa.

Let's see how it pans out...

 

Thing that wonders me even more is the possibility to run graphics and physics on same GPU. So GPU could help CPU to process physics. This would be pretty cool.

 

It wouldn't be if you're card is allready being pushed to the max.
That's what Ageia's point was about GPU physics, you're sacrificing video quality (i.e. frames/effects) to run physics.

 

Yes, there are some operations that can run as an extra pass within a frame.

 

There are some problems if you want to share one GPU for physics and graphics operations. At first you have to decide if you want to go the single or dual access point way. With the single point way you create only one device context (with OpenGL/Direct3D) and the application will send all commands (physic and graphics) inside this context. The alternate way is to create separate context for graphic and physic. This gives you the option to use another API on the physic context. But AFAIK current GPUs don’t support multiple context usage on hardware. We will se this in the future (WDDM 2.1) but today the driver has to switch the single context on the Chip to the different virtual contexts in the driver. Such a context switch has an impact on the overall performance. IIRC I have read that using two contexts at the same time will cost you 2-3% performance. This let the single point way looks better but there is another problem. Graphics APIs allows the driver to store the commands for some frames in the memory in advanced. If your physics data are inside the graphics data they are stored there to. If you don’t need to read the results back from the CPU you are fine. But if you want something back you can decide to wait until the whole buffer is execute or build some exotic solutions that delivers you the result with a latency of some frames.

 

It would be easy enough to make a 16x -> 1x adapter for low profile X1600 cards. Then they wouldn't have to stick up any higher.

 

As I understand it, you can simply plug a 16x card into a backless 1x port and it'll run fine without any need for adaptors.

 

That link isn't working for me but I don't think you'd have any problem getting the card to fit in the majority of mobos. My 7800GTX runs fine in my backless PCI-e 4x slot.

 

Lets hope they don't lock out Nvidia Chipsets.
If they don't i could plug on in the3 second 16x Slot of my Ultra-D and ATI sold a x1600.
If they lock nvidia Chipsets out i buy nothign and ATI gains nothing.

 

I agree that the best place for physics coding is left to the CPU, particularly that dual core cpus are becoming the norm. Physics engines and software are much more important thatn ridiculous amounts of hardware.