HSR vs Tile-Based rendering?

[Simon F]

How do aniso and tile overlap relate to each other ? What aniso are we talking about aniso texture sampling ?

K-

If you have long, thin triangles, you'll need to read in that triangle data for more than one tile. I was using the term high anisotropy to describe this situation, since, for example, a uniformly-tesellated mesh when viewed at high angles will exhibit this problem.

Ahh that makes more sense.

Yes, you frequently do have triangles that go into more that one tile. If they are ~equilateral this is absolutely fine.

If, OTOH, a triangle has a small area compared to its length, then it is far less efficient, but you should ask yourself (or better still, measure) "what happens on an IMR in this case?".

 

[Dave B(TotalVR)]

Well if the triangle is tall and thin Simon, as apposed to short and fat, I would assume it turds on your IMR's memory efficiency.

 

[Simon F]

Well if the triangle is tall and thin Simon, as apposed to short and fat, I would assume it turds on your IMR's memory efficiency.

Not quite the way I would put it but, basically, that is correct.

 

[Dave B(TotalVR)]

8)

 

[KimB]

If, OTOH, a triangle has a small area compared to its length, then it is far less efficient, but you should ask yourself (or better still, measure) "what happens on an IMR in this case?".

Well, on an IMR this should be no different than small triangles, which are a case that will need to be optimized for with IMR's. One case of small triangles that may be able to be optimized efficiently in IMR's is a skinned mesh. A first optimization would be to queue up enough triangles so that you can render the pixels in memory-friendly order. Given that an optimized mesh will have a decent amount of locality anyway to improve vertex cache hits, this shouldn't be too much of a problem.

A second optimization, and much more challenging, would be to allow a quad to operate on pixels from neighboring triangles in the mesh. There are definitely some significant obstacles to this approach, but it seems that this is a problem that will need to be tackled at some point.

 

[JohnH]

It should be no different than any other memory fetch in terms of latency. In fact, I would tend to think that a framebuffer read for blending would get priority, as if you minimize the latency of the blending read, you'll minimize the chance you'll have to stall the pipeline due to overwriting.

I haven't said its any different to any other memory fetch, all memory fetches have a large range of potentual latencies ranging from 10's of clocks up to a few 100's. This means you need buffering in there somewhere, there's no way around it. As you say you could give FB reads a higher priority but you still have to service other things sooner or later, and as they've been held of for longer they will need more data so you're back to needing more buffering, there's just no way around this.

John.

 

[JohnH]

If, OTOH, a triangle has a small area compared to its length, then it is far less efficient, but you should ask yourself (or better still, measure) "what happens on an IMR in this case?".

Well, on an IMR this should be no different than small triangles, which are a case that will need to be optimized for with IMR's. One case of small triangles that may be able to be optimized efficiently in IMR's is a skinned mesh. A first optimization would be to queue up enough triangles so that you can render the pixels in memory-friendly order. Given that an optimized mesh will have a decent amount of locality anyway to improve vertex cache hits, this shouldn't be too much of a problem.

You're ignoring memory bus efficiency, a small or long thin triangle will acheive very poor utilisation of this given the burst orientated nature of high speed memory interfaces.

A second optimization, and much more challenging, would be to allow a quad to operate on pixels from neighboring triangles in the mesh. There are definitely some significant obstacles to this approach, but it seems that this is a problem that will need to be tackled at some point.

This is relatively easy on a TBDR.

John.

 

[Dave B(TotalVR)]

Well, on an IMR this should be no different than small triangles, which are a case that will need to be optimized for with IMR's. One case of small triangles that may be able to be optimized efficiently in IMR's is a skinned mesh. A first optimization would be to queue up enough triangles so that you can render the pixels in memory-friendly order. Given that an optimized mesh will have a decent amount of locality anyway to improve vertex cache hits, this shouldn't be too much of a problem.

No, a single small triangle only writes to one single memory page. A long thin one will be spread across many pages. There is precisely zero that any IMR can do about this except have memory pages the size of your framebuffer and z-buffer combined.

The neccesity to write to multiple memory pages for a single pixel wide very tall polygon turds on your memory efficiency like a hungover football hooligan the morning after a boozed up vindaloo.

That said, the only time polygons like this are gonna turn up are on cylindrical pillars and oddly shaped entities - in short not very often. The fact that they may increase a TBDR's binning work and decrease an IMR's memory efficiency is rather moot IMO.

 

[Ailuros]

...like a hungover football hooligan the morning after a boozed up vindaloo.

OT: scratch the hooligan part (or on second thought maybe don't) and the description fits me rather well these days *hick*

 

[3dcgi]

That said, the only time polygons like this are gonna turn up are on cylindrical pillars and oddly shaped entities - in short not very often. The fact that they may increase a TBDR's binning work and decrease an IMR's memory efficiency is rather moot IMO.

Shadow volumes are full of long skinny triangles. These triangles are not only inefficient with memory, but they can pose problems for rasterization algorithms as well.

 

[Dave B(TotalVR)]

Hrm, yes....

They are also rendered blazingly fast on a TBDR... 8)

 

[KimB]

Hrm. And one might now wonder why Fablemark seems to avoid the situation where the shadow volumes are long and thin....

 

[Simon F]

Hrm. And one might now wonder why Fablemark seems to avoid the situation where the shadow volumes are long and thin....

If you're so paranoid, run the PowerVR "paper storm" demo. IIRC, there are plenty of thin stencil polys in that.