By using this site, you agree to our Privacy Policy and our Terms of Use. Close
fatslob-:O on 29 March 2014
Edit Thread
Pemalite said:
fatslob-:O said:

Why would anyone want to store the generated vertex's ? The point of tessellation is to create more detail in a procedural way. The endless city demo wouldn't even be possible in the first place because of large memory overhead in storing over a billion triangles! Your reasons for tessellation being superior in the xbox one is wrong for the most part seeing as how the performance scales with CLOCKS which is quite pathetic on AMD's part. How in the hell does a 7870 kick's 7950 in the ass in tessmark ? This still means that even with the higher clocks the xbox one would only perform 5% better than the PS4 in tessmark and if we go to tess factors of under 16 the PS4 will most likely take it due to the fact that somehow their tessellators would actually respond to those factors. 

What AMD needs to seriously do is have a truly parallel solution otherwise it's going to be another embarrassing slaughter on the tessellation front. 

You should ask AMD that same very question. :P

The problem is, the geometry engines need large caches to store data to keep everything fed, when AMD moved from a single geometry engine to having two of them it didn't increase the caches as it was transister and thus die-size constrained at the 40nm fabrication process. (I.E. Radeon 69xx series.)
So their only option was to store it into System Ram or the GPU's Ram, the GPU's Ram was it, hence why in some games AMD's GPU's may use more memory than nVidia to run the same game on those particular cards.

But I do iterate I haven't actually looked into AMD's tessellation improvements with the GCN hardware to any great degree, so I'm not sure if the above still applies.

So I took a bit of snooping on the GCN whitepapers and the only thing that you would need to store is the patch data according to microsoft and that is relatively small. Another thing that the GCN architecture does to alleviate this storage bottleneck is that the patch data can spill to the L2 cache so I'm willing to bet that the storing of patch data isn't as much of a problem as AMD's own implimentation of tessellation. What AMD DOESN'T currently have is the hardware to maintain the exponential increase of triangles. Instead of just having 2 tessellators that are outside of the compute units or streaming multiprocessors maybe it would be a better idea to have tinier tessellation engines in those units. Even if each tessellator doesn't have 1 prim/clk and only does 0.25 prim/clk it would be alot easier to handle the explosion of triangles on 8 or so smaller tessellators rather than just 2 tessellators. 

AMD needs to seriously figure out a truly parallel solution. Their pipeline is serialized from the looks of it and that's probably causing the bottleneck. 

/Edit

Off-topic: Now I know why we don't use tile based renderers ... The system scales like a bitch once you have more than 512 primitives per each 16 x 32 tiles. Eventually the benefits of z buffering such as being able to do stencil shadowing starts to outweigh the drawbacks of a steep slope expense. Tiled based rendering wouldn't be feasible anymore on current gen games that are coming out and it would likely have a much more difficult relationship with tessellation than AMD now which is already bad.