Re: ClipTexture

New Message Reply Date view Thread view Subject view Author view

Tom McReynolds (tomcat++at++proxima.asd.sgi.com)
Tue, 13 May 1997 10:43:51 -0700


> --- Forwarded mail from flysiml++at++public.bta.net.cn
>
> From: flysiml++at++public.bta.net.cn
> Date: Tue, 13 May 1997 14:36:15 +0900
> Reply-To: flysiml++at++public.bta.net.cn
> X-Mailer: Mozilla 3.01Gold (WinNT; I)
> To: info-performer++at++sgi.com
> Subject: ClipTexture
>
> Hello friends,
>
> I'm doing clip texture on my iR machine. Can you tell me
> if my hardware is enough to run cliptexture?
>
> Thanks
>
> Cao Zhigang
>
> ===================================
> E-Mail: flysiml++at++public.bta.net.cn
> Tel: (8610)68428861-340
> Fax: (8610)68424844
> ===================================
>
> **********************************************************
> IR_No1 20% gfxinfo
> Graphics board 0 is "KONAS" graphics.
> Managed (":0.0") 1280x1024
> Display has 8 channels
> 4 GEs (of 4), occmask = 0x0f
> 4MB external BEF ram, 32bit path
> 2 RM6 boards (of 2) 1/1/0/0
> Texture Memory: 16MB/16MB/-/-
> Medium pixel depth
> 32K cmap
>
> IR_No1 21% hinv
> 2 196 MHZ IP25 Processors
> CPU: MIPS R10000 Processor Chip Revision: 2.5
> FPU: MIPS R10010 Floating Point Chip Revision: 0.0
> Secondary unified instruction/data cache size: 1 Mbyte
> Data cache size: 32 Kbytes
> Instruction cache size: 32 Kbytes
> Main memory size: 128 Mbytes, 2-way interleaved
> I/O board, Ebus slot 3: IO4 revision 1
> Integral EPC serial ports: 4
> Graphics board: InfiniteReality
> Integral Ethernet controller: et0, Ebus slot 3
> EPC external interrupts
> Integral SCSI controller 1: Version WD33C95A, differential, revision 0
> Disk drive: unit 2 on SCSI controller 1
> Disk drive: unit 1 on SCSI controller 1
> Integral SCSI controller 0: Version WD33C95A, single ended, revision 0
> CC synchronization join counter
> Integral EPC parallel port: Ebus slot 3
> VME bus: adapter 0 mapped to adapter 13
> VME bus: adapter 13
> ************************************************************************
> =======================================================================
> 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 forwarded mail from flysiml++at++public.bta.net.cn
>
> --
> -----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
> Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev.
> src++at++sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590
> -----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
>-- End of excerpt from Sharon Clay

Yes it's big enough. The main limitation for you is the amount of
texture memory you have available for clipmaps. Here is the
clipmem.txt file, which is part of the 201 beta (in performer.dev.src.sample).
Look in /usr/share/Performer/src/sample/C/clipfly/doc:

        Clipmap Memory (System and Texture) Usage Estimation

        System Memory Estimation

        Given:

        Size of clipmap level 0
        Clipsize (in texels)
        Tilesize (in texels; assuming tile size is the same for all levels)
        Texel size in bytes
        Whether the tiles have high disk latency

        1. round up clipsize to even multiple of tile size in each dimension
        2. divide each dimension by tilesize in that dimension
        3. add 2 tiles to each dimension for a tile boundary of 1.
        3a. if there is high latency downloading, such as reading tiles
            over the network, or decompressing tiles, add 4 tiles per
            dimension, giving a tile boundary of 2.

        You now have the number of tiles in each dimension per clipped level*

        4. multipy each tile number in each dimension by the corresponding
           tilesize in that dimension.

        You now have the number of texels in each dimension

        5. Multiply the texel dimensions together
        6. Scale by the size of each texel

        7. (extra credit) add in the fixed cost of imagecache structs, etc.

        You now have the system memory cost in bytes for each clipped level

        8. Treat each level bigger than clipsize as clipped(**).
           Add 4/3rds the clipsize scaled by the texel size for the pyramid
           levels.

        9. Scale the clipped level size by the number of clipped levels

**This estimate is a bit too conservative, since the lowest clipped levels
  may exceed the entire level size with a border of 2 tiles. It is a function
  of tilesize and clipsize.

        Example: 2M top level, 1K clipsize, 512 Tile Size (everything square)
                 1 byte texel size (LMV example)

        1. no-op: 1K, 1K (for both s and t)
        2. 1K/512 = 2, 2 (for both s and t)
        3. 2+4 = 6, 6 (for both s and t; high latency on tile download)
        4. 6 * 512 = 3K, 3K (for both s and t)
        5. 3K * 3K = 9M
        6. 9M * 1 = 9M
        7. We haven't figured out this constant yet, and we haven't proved it's
           a constant.
        8. 9M * 10 = 90M (for 2M -> 4K levels) + 2M (for 2K level) = 92M
        9. 4/3 * 1K * 1K= 1.3M
       10. Total Size 92M + 1.3M = 93.3M

        Texture Memory Usage

        Given:

        Clipsize (in texels)
        Whether clipmap is virtual or non-virtual
        Number of levels in use (if less than 16)

        1a. if virtual, multiply number of levels by square of clipsize

        1b. if non-virtual, multiply number of levels bigger than clipsize
           by square clipsize. Add in 4/3 times clipsize squared (to
           account for the pyramid.

=======================================================================
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:55:13 PDT

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