GPUs Will Process Physics, ATI Says

After this job offer there was nothing more to hear about this project. This is very unlikely.

 

Iirc I read on some site (I cannot find the link anymore) that the ATI API had a backend on SM3 and GLSL for all the other GPUs, while it ran on the metal with ATI ones.

 

Will Ati actually do some PR work and get some Devs on board unlike with HDR+AA?

 

But isn't a little strange that a mid-range GPU would be faster at physics than a dedicated solution?

 

How dedicated is PhysX really? It’s dedicated to do fast floating-point calculations but modern GPUs can do this to. The main advantage of PhysX is the additional MIPS core that can help to save some additional CPU power with offload some of the management.

 

a mid-range GPU, with lower retail price but higher clock speeds...

It's allready brilliant considering the PCIE1x 1300 that was launched at computex, you shouldn't need 4x PCI lanes for physics, right? (or am i underestimating the amount of data that travels the bus?)

 

I can't imagine it's spending 6000+ cycles simply on a sphere-sphere intersection, which is really simple. The benchmark probably includes a lot of data traversal. Maybe they have a bounding sphere heirarchy or something. This is the sort of thing that DB will benefit greatly, so I can imagine ATI coding for this.

10,000 sphere objects would need a hundred million S-S collisions (i.e. 20 sec/frame on R580) if done the dumb way. A heirarchy could reduce that to maybe a hundred thousand or so. However, such a structure is not easy to implement in pixel shaders with a stream processing model.

So any word on whether ATI will release some demos on this stuff?

 

Economies of scale.

 

As there is no tool like ShaderPerf for ATI I run a quick check for the G7X chips. A S-S-C can be done in one pipe in 4 cycles per check. We are sure get some additional overhead for the memory access (32 bit floats) but even in this case I can’t see why it should burn 6000+ cycles per check. Maybe 20 but this is already high.

It sounds more like the run a whole demo that does more than only the checks.

 

= Development costs for the hardware are already paid by people who buy this chip for graphics?

Or does the foundries today offer such great quantity discounts?

 

I believe it's mostly the first. From what I understand, the majority of the cost of most hardware is in R&D.

 

This chip and the whole line of chips using the same architecture (development costs have so far been been spread across 4 chips using the same fundamental architecture).

There is quite a bit of that as well.

 

I know this.

My question was just a try to get more than 2 words from Dio.

 

It seems like it's latency bound to me, rather than bandwidth bound, since the scaling from RV530 to R580 (~5x) is in line with the relative fragment rates (~4.4x) rather than bandwidth (~2x).

So that would seem to imply that the batch size of 48 is still far too large. Is that reasonable?

Or maybe the 5M number is simply the worst case, where every sphere is colliding with 12 others in the tightest packing. I really don't understand this stuff

There is an R2VB Collision demo in the March 06 SDK. Needs SM3.

The Data Parallel Processing architecture needs to get out there, too. It's supposed to be aimed at the GPGPU guys as well.

But it's also down to Havok I guess.

Jawed

 

I hope someone comes up with an Empire Strikes Back Asteroid Field Demo. Fly the Falcon through the field chased by tie fighters whilst using the vehicles advanced vectored thrust and tractor beam to not only navigate the obstacle course safley but swing smaller roids into the tie fighters path.

 

Well, vectored thrust is trivial to program, basically. It's collision detection with the large number of objects that would be tough to do in such a situation.

 

Why? I expect an objects density, mass, weight etc. to be variables in an objects' properties and it would be like applying a texture to an object. your physics card... should be able to do the calculations..
I doubt we'll see something like 20.000 asteroids on screen (everything is still poly sparse.) and even then there should be more than enough memory on a 1600 to hold (a limited amount of data) for such objects

 

Well, the sphere-sphere collision test isn't just a sphere-sphere intersection test ([thread=26078]linky[/thread]), but it's still possible in a handful of cycles, so you're right, 6K+ cycles is nonsense.

Or maybe AABB sweep? I guess implementing the insertion sort would be a bit problematic.

 

Most of the objects won't be acted upon by any force, and therefore won't need any more calculation than collision detection and a simple progression of their movement.

Additionally, even when being acted upon, the most complex rigid body's reaction to forces can be fully-described by ten numbers (its mass, six more for the symmetric 3x3 moment of inertia tensor, and three for the location of the center of mass...you can reduce this all to four numbers by choosing the zero for the model to be the center of mass, and the model's x, y, and z axes to be those which diagonalize the moment of inertia tensor). The calculations for acting of a force upon a rigid body are pretty simple.

The only difficult part would be in dealing with collisions that result in breakaway pieces, but since collisions are going to only happen among a small fraction of the asteroids at any given time, you can spend a significant amount of time with each one and not impact performance.

 

Gravity should be acting on all of them and forces acting will go up from there.