3DWorld (11/13)

From:Thomas Frieden
Date:22 Sep 2001 at 21:34:14
Subject:Re: [3DWorld] Re: Textures.

Hi,

Michal Wozniak wrote:

>It required some thinking, but now its obwious to me too;))
>
Sorry, couldn't explain it better :/

>I thought it works like this:
> I load a texture
> pass it to the W3D
> W3D allocates a bitmap for it (is it only a struct, ar a whole new
>bitmap?)
> CGX allocates a piece of mem to store it in case there is not enough
> free mem on board. (1)
> At first use it tries to place it into GFX mem.
> If it needs to be flushed it is copied into this temp mem (1)
>
> In this case there would be no need for original image. But also
> every texture would need twice it's memory.
>

Yes. That's how OpenGL handles it... But you might need to retain the
original image, anyway, for example for hit tests, or modifications...
So I think it's sensible to keep the original image. If push comes to
shove, just dispose of the memory when you free the texture object...

Regarding the allocation on the graphics board: We allocate large
bitmaps, and use the memory of these bitmaps as "free memory pools" with
our own allocation scheme. Everything is allocated through this,
textures, zbuffer, even the Voodoo 3 fifo buffer.

>
> The way it's handled no is a bit better, but IMHO, with better
> cooperation with CGX/P96 the amount of needed memory could be
> limited a bit more. But it would require some changes in CGX.
>

Yes, what I always wanted to have is a function to allocate memory from
the graphics system, without the need to allocate (and lock) bitmaps.
This is always a bit kludgy..

>>Remember that the memory on the graphics board is rather limited, so
>>when new textures are uploaded, other textures are removed from the
>>graphics board. But if you need the old ones again, it has to be
>>uploaded again. This is done automatically by Warp3D, so the original
>>images must still be present.
>>
>
> So if texture is flushed from gfx board memory (by other texture)
> it's memory is also dealocated? If not it would be better to do it the
> way I thought it's done. At least I think so;)
>

The bitmaps are reused when a texture is swapped out of graphics memory.
Think of the graphics board memory as a giant cache: The textures on the
graphics board are, just like the entries in the CPU cache, just copies
of the original in main memory.
So when a texture is removed from the graphics board, the appropriate
memory handle is returned to Warp3D's internal memory list, and the new
texture is allocated. Warp3D also does free block "compression" (i.e.
adjacent free memory regions are merged back into one block), and free
blocks matching the size of an allocation are reused...

>>If the format is directly supported, there's only one copy in main memory.
>>
>
> Are you keeping converted texture also? On PPC texture conversion should
> be as fast as pure copying.
>
Currently, textures are converted when allocated, and a copy is kept in
main memory. But we want to change that in a future release so that the
conversion is done when the copy to the graphics board is made. You're
completely right, the PPC can do that fast enough. After all, reads from
system memory are much faster than writes to the graphics board, so the
speed of the conversion should be nearly the same as a plain copy...

Regards,



Thomas Frieden
Senior Developer, Hyperion Entertainment
ThomasF@hyperion-entertainment.com
http://www.hyperion-entertainment.com