Gem and texture size

[Mark Danks]

  Here is how textures are dealt with under OpenGL and hardware
accelerators.  This can obviously change in the future, but right now, I am
fairly certain that the info is correct (I make games in my day job, so I
have vested interest in this :-)

  The amount of memory (VRAM) on the card (12mb for Voodoo2, 16mb for TNT,
64mb for GeForce2, etc) is used for both textures (TRAM) and frame buffer
space.  If you have a large rendering window, like 1600x1200, it will take
up 1600x1200x4x3 in 32-bit mode with double buffering and a Z buffer (or
23mb).  Most people run at TV resolution, like NTSC, so it takes 640x480x4x3
= 3.7mb   All of the space left is for textures onboard the card (FYI, if
you have heard that people are having problems with the PlayStation2, notice
that it only has 4mb of VRAM...not much onboard texture space, huh? :-)

  Sooo, when GEM "creates" a texture, it immediately tries to send the
texture to the card, which uses some of the left over space in the VRAM.  If
you had a 640x480 window on a Voodoo2, you have ~8mb of texture space left
over.  On a GeForce2, ~60mb.  The problem is what happens if you want more
textures than can fit into TRAM.  OpenGL requires that the video drivers
deal with the problem, so GEM doesn't care too much (more about this later).
In most cases, the drivers cache the textures in main memory and if a
texture is requested for rendering and it isn't resident on the card, it
will download it.  If you have AGP, then this is pretty quick, although none
of 3dfx cards really take advantage of this (ie, those cards are about the
same speed as the PCI bus).  So depending on the number of textures, and how
complex the scene is, you might be able to display more textures than you
have TRAM.

  One slowdown that can happen with GEM is that it makes a copy of the image
before sending it down the chain of objects.  If you are constantly changing
images with a pix_multiimage, this can be a performance hit, but you can
modify the actual pixel data with the pix objects.  The pixels aren't sent
to the graphics card until the pix_texture object is reached.

  GEM tries to help with this with a few objects.  pix_imageInPlace acts
much the same as pix_multiimage, but it downloads _every_ image in the
sequence to the card when a download message is recieved.  It also
immediately turns on texturing, instead of making a copy (ie, you don't need
a pix_texture object).  Much faster, but not as flexible.  pix_movie does
much the same thing.  It sends the pixel data without copying it if there is
a new frame to display.

  The entire pix system uses a caching system so that the copying and
processing only occurs if something actually changes.  For example, if you
had a pix_threshold object, it would only process when rendering
started...and every time that the values actually changed.  You can use
pix_buf to isolate parts which don't change from those that do, but it
involves another copy.

  On the Voodoo2, the hardware itself limits textures to 256x256...this will
never change.  The newest Voodoo5 boards have a higher texture size.

  Hope this helps...this message was a lot longer than I had expected.

Later, Mark

============================
= mdanks at stormfront.com
= Lead Programmer PS2
= http://www.danks.org/mark
============================
 

> -----Original Message-----
> From: Linium [mailto:intent at club-internet.fr]
> Sent: Wednesday, August 16, 2000 3:24 AM
> To: pd-list at iem.mhsg.ac.at
> Subject: Re: Gem and texture size
> 
> 
> Mark Danks a écrit :
> > 
> >   If you are using a 3dfx Voodoo based card, it has a 
> maximum texture size
> > of 256x256.
> > 
> >   For everyone on the list, I _highly_ recommend using 
> nVidia's products.
> > Their OpenGL support is great.
> > 
> > Later, Mark
> 
> Yes, I have a Voodoo2.
> 
> Are the textures stored in the onboard memory (12mb here) ? And does
> this limit the number of textures that can be displayed at 
> the same time
> ?
> 
> Thx for your attention,
> 
> Linium
>