Re: (was: Multi-pass rendering) now: texture paging

New Message Reply Date view Thread view Subject view Author view

Orad Hi-Tec Systems (orad_u++at++netvision.net.il)
Wed, 12 Mar 1997 10:56:19 +0200

Javier Castellar wrote:
>
> 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)
>
>

Is there a number (milliseconds) for the GE part of the operation?

I am mostly concerend with texture paging from video (video read source
for glCopyTexSubImage2DEXT()), for the various Sirius pixel packings
and their corresponding internal texture formats (and D1 transfer
sizes).

In the case of video, is this timing dependent only on the placement
of the glCopyTexSubImage2DEXT() token in the stream, or also
on the timing the Sirius chooses to transmit to the GE?
I think I know the answer, it dependes on the Sirius too, and
that is why the pipeline needs to be genlocked to video too.
But how can I control the timing of this transfer if it is not optimal?
I can put the glCopyTexSubImage2DEXT() wherever I want, but cannot
control the Sirius transfer delay relative to the vertical sync.

Bye,
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

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.