[Papervision3D] Optimizing performance: anything else I can do?

[Alan Pinstein]

You're right about your approach:

> On a 32 bit data bus, imagine having to write a 33 by 1024 pixel  
> bitmap into graphics memory.
> Now we want to write 33 bits, so you write one 32 bit (4 byte)  
> integer ('int') followed by 1 more bit because it's 33 bits wide.  
> You have to do this 1024 times because of the depth.

Except for that it's completely inapplicable for our bitmap data.

We are dealing with 32-bit image data (RGBA) so a single pixel is  
exactly 32 bits wide...

Alan

On May 10, 2009, at 6:40 AM, John McCormack wrote:

> It's probably to do with the underlying nature of the electronics:
>
> The early PCs were 8 bit computers, so you had 8 bits of wire on the  
> data bus (1 byte) and you could send 8 bits at a time from cpu to  
> memory.
> 16 bit Windows 3.1 worked with 16 bits of wire on the data bus (2  
> bytes)
> Now we have 64 bits.
>
> On a 32 bit data bus, imagine having to write a 33 by 1024 pixel  
> bitmap into graphics memory.
> Now we want to write 33 bits, so you write one 32 bit (4 byte)  
> integer ('int') followed by 1 more bit because it's 33 bits wide.  
> You have to do this 1024 times because of the depth.
>
> What makes it worse is that you want to leave alone the other 31  
> bits of the destination 4 byte integer, so you get the destination  
> integer, mask off the 31 bits, write the single bit into the zero  
> position of the 0 to 31 bit integer and then send it back.
> Of course much of this is done automatically, now, in the hardware.
>
> But even a 32 bit integer may be inefficiently written:
> Consider memory starting from the 4 byte, 32 bit, memory address
> 0000 0000 0000 0000 0000 0000 0000 0000, the place for the next 32  
> bits would be
> 0000 0000 0000 0000 0000 0000 0000 0001
>
> Let's say you want some of these 32 bit at the first address address  
> and some at the second. So now one memory access is not enough.
> If things were lined up for efficiency you would make sure your  
> block of data (our integer) did not straddle two addresses.
> C and C++ allow you to set the alignment.
>
> Now imagine writing a 34 bit integer that straddles 3 addresses:
> 1 bit at the 31st position of some address
> 32 bits at the next address
> 1 bit at the next address
>
> That's a lot of work, mainly due to the nature of the underlying  
> electronics.
> There may be other issues and some of the ones above may no longer  
> be relevant.
>
> John
>
> Alan Pinstein wrote:
>>> I believe it's good practice to keep bitmap dimensions to x2  
>>> (64,512,etc) - not sure how much performance boost you'll get from  
>>> that one tweak tho.
>>
>> Why? From everything I've read the point of this is simply to  
>> benefit from Flash built-in mipmapping. Outside of that I know of  
>> no reason why this matters (yet).
>>
>> If it's just mipmapping, then this can't possibly have an effect at  
>> full-screen for my application since none of my textures ever get  
>> "shrunk" in the viewport.
>>
>> Alan
>>
>> _______________________________________________
>> Papervision3D mailing list
>> Papervision3D at osflash.org
>> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>>
>>
>
>
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org