Re: Multi-pass rendering again !

New Message Reply Date view Thread view Subject view Author view

Rémi Arnaud (remi++at++remi.asd.sgi.com)
Wed, 12 Mar 1997 08:22:03 -0800 (PST)


Space Magic Team wrote:
>
> Thank you to Javier Castellar and Moshe Nissim for all the performance
> details which aren't obvious for me in the hardware documentation...
> Another question that I have concerns the maximum performance I can expect
> from a framebuffer copy into the texture memory.
> At this time, I use an internal format PFTEX_RGB8 for my texture, and I
> obtain a time of 14ms for the transfer of a 1024x1024 texture with 2 RM6s.
> Is it logical ?
 Yes this is right.
> Does this time depend linearly of the number of RM ?
 No, in theory it should not matter how many RMs you have, in practice
 the result is a little faster with 4 RMs.
> How doest it vary in function of internal format of texels ?
 Using a 10 bits/texels should not change the performance as it is still
 a 32bit word per texel.
> If I take the hardware documentation, it precises that one RM6 has a 80Mb
> transfer rate between frame buffer and texture memory, so for 3 eight bits
> components texels and 2 RM6s, the practical time that I have corresponds to
> a transfer rate of 180 Mb and not 160 Mb ?
> Am I exploding the performances of the IR (I don't believe so) or am I
> making a mistake in my computations ?
 The Frame buffer to texture is 80M pixels/s theorical maximum. (not bytes)
 The # of rm do not change this speed as the texture is broadcasted
 in all RM's in a system. That's why adding RMs do not change the
 overall texture capacity of a system

 Salutations,

    _ / _ _
|_) _ ._ _ o /\ |_)|\ | /\ | || \
| \(/_| | || /--\| \| \|/--\|_||_/
                                           
=======================================================================
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.