XBOX 360 hardware tesselation

[SentinelQW]

The X 360 maximum setup limited polygon performance: 500 million/sec
When system use a hardware tesselation, the performance: 250 million/sec
I know the real time hardware tesselation=micro polygons+displacement mapping technique
The question: 250 million hardware tesselated polygons detail, how many normal polygons in comparsion?
Theoreticaly, and real in game situations?

 

[Guden Oden]

What is it you're actually wanting to know, don't the numbers explain themselves? You've answered your own question. 500M normal case, 250M tesselated. Theoretical paper-specs, of course.

 

[LightHeaven]

I have a question about this: Does the tessalator limits the overall pefomance of the gpu to 250kk or not, meaning that you could still use the vertex shaders to complete the other 250kk?

 

[robofunk]

Isn't the whole point that it's 250M in addition to some number less then 500M. Creating more geometry out of less.

 

[LightHeaven]

Isn't the whole point that it's 250M in addition to some number less then 500M. Creating more geometry out of less.

I once belived that was the case too, but interpreting from the info avaiable i got the impression that it limits the actual perfomance to something lower than 250M...

I could have misinterpreted it thought...

 

[London Geezer]

You'd think, with those numbers, we shouldn't see ANY straight angular polygonal edges in games, but we do... (Not just talking about X360 here, just to cool the potential flames down)

 

[[maven]]

The peak triangle rate is 500 million triangles per second. Geometry throughput is limited by the peak triangle rate when rendering meshes, because post-transform vertex reuse allows for less than one vertex to be transformed per triangle.
The tessellation engine can generate one new vertex every two clock cycles. On highly tessellated primitives, the peak triangle rate can still be reached because the number of new vertices per triangle approaches 0.5, because of post-transform vertex reuse.

Now, the important point is memory bandwidth. For example, at the peak vertex rate fetching 44.8 bytes per vertex consumes all of main memory bandwidth. Similarly, at the peak pixel rate fetching 5.6 bytes per pixel consumes all of main memory bandwidth. Memory utilization is not 100-percent efficient, and the CPU also consumes main memory bandwidth, so these numbers will most likely be lower in practice. It is important to compress vertices and textures to reach the peak vertex rate and peak pixel rate.

 

[Guden Oden]

I have a question about this: Does the tessalator limits the overall pefomance of the gpu to 250kk or not, meaning that you could still use the vertex shaders to complete the other 250kk?

The "vertex shaders" (xenos has no specific vertex shader units) can transform a lot more vertices than 500M per second. I wouldn't be surprised if the theoretical peak if all the shader units are put on transformation duty was a couple billion per second. That's not where the limit is though; it's the polygon setup engine that's throttled to 500M, and this step comes after transform. So you could transform a trillion polys/s using black magic and whatnot, but xenos could still not actually process that many due to the setup limit.

Isn't the whole point that it's 250M in addition to some number less then 500M. Creating more geometry out of less.

It does create more out of less, but the more out of less refers to the actual GEOMETRY. Not to the theoretical max limits of the hardware...

Even so, 250M is well over a hundred times more than there are screen pixels even at the highest rez x360 is specced for, so I don't think programmers need to worry the slightest.

 

[LightHeaven]

The peak triangle rate is 500 million triangles per second. Geometry throughput is limited by the peak triangle rate when rendering meshes, because post-transform vertex reuse allows for less than one vertex to be transformed per triangle.
The tessellation engine can generate one new vertex every two clock cycles. On highly tessellated primitives, the peak triangle rate can still be reached because the number of new vertices per triangle approaches 0.5, because of post-transform vertex reuse.

Now, the important point is memory bandwidth. For example, at the peak vertex rate fetching 44.8 bytes per vertex consumes all of main memory bandwidth. Similarly, at the peak pixel rate fetching 5.6 bytes per pixel consumes all of main memory bandwidth. Memory utilization is not 100-percent efficient, and the CPU also consumes main memory bandwidth, so these numbers will most likely be lower in practice. It is important to compress vertices and textures to reach the peak vertex rate and peak pixel rate.

But isnt the whole point of tessalation to work around the bandwidth limitations and still allows a lot of polygons?

Specially in a hardware tessalator i would think that it generates the vertx on the fly not using system memory for that...

 

[[maven]]

But isnt the whole point of tessalation to work around the bandwidth limitations and still allows a lot of polygons?

Specially in a hardware tessalator i would think that it generates the vertx on the fly not using system memory for that...

Of course. So you're saying 250 million vertices / sec (pre-transform cache) is not enough for "a lot of polygons"?

 

[LightHeaven]

Of course. So you're saying 250 million vertices / sec (pre-transform cache) is not enough for "a lot of polygons"?

No, I'm saying that maybe them can be close to be achieved without using all the bandwidth that 360 has to offer, because i thought that this is what you said...

 

[Dr. Nick]

I don't remember Dave saying that the performace of the Xenos could only do 250m when the tesslation unit was on. I remember it being something like the tesslation unit by itself could do 250m while the Xenos' shaders could do in theory close 6b but is setup limited to doing 500m and because of that the Xenos would be able to get very close to that setup number because of the shaders.

Maybe he can explain it again.

 

[expletive]

The peak triangle rate is 500 million triangles per second. Geometry throughput is limited by the peak triangle rate when rendering meshes, because post-transform vertex reuse allows for less than one vertex to be transformed per triangle.
The tessellation engine can generate one new vertex every two clock cycles. On highly tessellated primitives, the peak triangle rate can still be reached because the number of new vertices per triangle approaches 0.5, because of post-transform vertex reuse.

Now, the important point is memory bandwidth. For example, at the peak vertex rate fetching 44.8 bytes per vertex consumes all of main memory bandwidth. Similarly, at the peak pixel rate fetching 5.6 bytes per pixel consumes all of main memory bandwidth. Memory utilization is not 100-percent efficient, and the CPU also consumes main memory bandwidth, so these numbers will most likely be lower in practice. It is important to compress vertices and textures to reach the peak vertex rate and peak pixel rate.

Isnt there an addition 10GB/sec of bandwidth from the Xenon to Xenos for tasselation/procedural synthesis type data?

 

[Laa-Yosh]

You can tesselate after transformation and other vertex processing stuff, maybe even after per-vertex light setup (and interpolate through the tesselation); complex skinning and cloth and collision could eat up a lot of VS cycles which you can spare this way and thus get higher vertex counts. And adaptive tesselation will keep post-tesselation polycounts low enough without compromising the looks...

 

[LightHeaven]

You can tesselate after transformation and other vertex processing stuff, maybe even after per-vertex light setup (and interpolate through the tesselation); complex skinning and cloth and collision could eat up a lot of VS cycles which you can spare this way and thus get higher vertex counts. And adaptive tesselation will keep post-tesselation polycounts low enough without compromising the looks...

Thats all i wanted to hear

Thank you all... i learn so much from this thread.