Re: Multi-pass rendering

New Message Reply Date view Thread view Subject view Author view

Javier Castellar (javier++at++sixty.asd.sgi.com)
Tue, 11 Mar 1997 19:06:03 -0800


You are more or less right about that paging after the rendering does not
 overlaps 100% sure with the rasterization stages in all cases, however the
ONLY chance of getting a percent of overlapping is requesting the paging after
the rendering.

If you request paging before the rendering, the overlapping will be less that
if you try the reverse order.

This is also true if you interleave paging operations, but sometimes is worst,
therefore the best choice is paging after the fill limited operations, becasue
the portion of paging involving GEs will be done and it will be buffered on the
internal fifos, waiting for the RMs to give them a chance (i.e. bubbles in the
fill rate)

-Javier

On Mar 11, 6:14pm, Orad Hi-Tec Systems wrote:
> Subject: Re: Multi-pass rendering
> Javier Castellar wrote:
> >
> > The only parallel texture paging will happen if you request texture paging
> > right after a fill limited operation. Then in this case you will obtain
free
> > GEs time while the RMs are draining the internal buffers.
> >
> > 1) fill limited operation
> > 2) texture paging
> >
> > -Javier
>
> This is not a sufficient condition.
> The GE may run parallel to the RMs, but, the texture memory
> update inside the RMs will "fight" with texture memory access
> by normal textured rasterization. In other words, the texture
> memory is NOT dual-port. Parallelism at this stage depends on
> the texture memory read access bandwidth. Thisd epends on
> many things: the pixel area of textured polygons (vs. un-textured
> polygons), the type of texture
> filters used, the bits-per-texel in the textures.
> (trilinear mipmap, for example, requires 8 texels
> for each rasterized pixel). Moreover, I guess it also depends
> on the locality of subsequent texture memory read accesses --
> a high-res texture rasterized into a small polygon (with
> non-mipmap filter), will increase the bandwidth.
>
> It sums up to: pretty unpredictable.
>
> Moshe Nissim
> Orad Hi-Tec Systems
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Orad Hi-Tec Systems

-- 
*************************************************************************
* Javier Castellar Arribas          * Email:         javier++at++asd.sgi.com *                 
*                                   * Vmail:            	 3-1589 *            
* Member of Technical Staff         * Phone:  415-933-1589 / 2108 (lab) *
* Core Design - Applied Engineering * Fax:                 415-964-8671 *     
* Advanced Systems Division         * MailStop:                  8L-800 *
************************************************************************* 
* Silicon Graphics Inc.                                                 *
* 2011 N. Shoreline Boulevard,                                          *                        
* Mountain View, California 94043-1386, USA                             *
*************************************************************************
"Violence is the last refuge of the incompetent"
						Hardin Seldon
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:53 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.