RE: [Algorithms] portal engines in outdoor environments

[Tom F. <to...@mu...>]

But _something_ still has to do the readback. The start of the chips'
pipeline still needs to know the results at the framebuffer end before it
can decide whether or not to start drawing the triangles. It doesn't matter
whether the CPU does it or some bit in the T&L section of the chip - it's
the same issue - something has to wait for pixels to go most of the way down
the rendering pipeline. And that's a performance lose.

Added to which, one of the growing bottlenecks is the AGP bus, and doing it
this way doesn't help that at all.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: jason watkins [mailto:jas...@po...]
> Sent: 18 August 2000 21:24
> To: gda...@li...
> Subject: Re: [Algorithms] portal engines in outdoor environments
> 
> 
> Better would be a pipeline that allows you to specify some 
> sort of simple
> bounding volume for each primative (ie, each index array, 
> display list,
> whatever). You could build these volumes with no overhead in 
> most games, and
> providing hardware with the hint would allow it to estimate 
> if the entire
> primative is obscured, in which case it simply skips the 
> entire primative.
> 
> This would require finer grained primatives.. which I guess 
> is sort of on
> the out in these geforce days... but I do imagine that for arrays of
> moderate size, in the 100's of trys, that the driver buffers 
> and is already
> looking at the next set. So, it's not exactly a perfect 
> solution, but it
> seems a relatively simple feature, and avoids the necessity 
> of a readback to
> application level.
[snip]