[Bf-committers] Post-2.40 release AMD64 question (re: shadbuf.c)

[Ton Roosendaal]

Hi,

The shadow buffer uses a lossless tile-based compression. The tiles are  
each 16x16 pixels in size, hence the allocation of a (size*size/256)  
lookup table in shb->zbuf.

This lookup table is an unsigned long, so it can also store an optional  
pointer. The parallel buffer shb->cbuf (char) stores codes which  
indicates whether this tile is compressed value or a full rect  
(pointer) with zbuffer values. The tiles themselves are allocated per  
byte OK, same size for 32 or for 64 bits.

For a 2k pixel square shadowbuffer, the zbuf lookup table size is:
32 bits: 62 KB
64 bits: 124 KB

Just two times larger, and very acceptable still. Any 64 bits OS user  
should be aware that average memory consumption for applications rises  
significantly anyway. :)

-Ton-

On 30 Nov, 2005, at 1:56, Ken Hughes wrote:

> Thought I'd ask while it was still fresh in my mind:
>
> While going through the code looking for 64-bit issues, I came across  
> this code in RE_initshadowbuf():
>
> shb->zbuf= (unsigned long *) MEM_mallocN(
> 	sizeof(unsigned long)*
> 	(shb->size*shb->size)/256, "initshadbuf2");
>
> The code seems to work fine on 64-bit platforms.  However, it also  
> means the shadow buffer is 4 times larger than on 32-bit systems.
>
> Since the each entry in the buffer is either a pointer to  
> MEM_mallocN()'d memory or a 32-bit int (an RGBA color), seems like  
> this would be a good candidate for Ton's POINTER_TO_INT  
> /INT_TO_POINTER macros (and declaring the buffer unsigned int).
>
> Nod if you agree :-)
>
> Ken
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org