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

[John McCormack]

Right!
So RGBA uses 4 bits, at 2 pixels per 8 bit byte.
A 32 bit integer can hold 4 bytes = 8 pixels.
If you had a 9 pixel wide image it would require the awkward processing 
mentioned below.

Also, you might wonder why a multiple of 2 is important.
Why not a multiple of 4, aligned properly to the memory?

The cpu registers do all the operations and they are 32 bits wide on a 
32 bit system.
Some processor operations can use one half of a register or the other, 
this might explain the x2 factor.

Video cards have their own separate, wider, data bus and can address 
more than 32 bits and so the problem exists even more frequently for the 
extra bits on the end.
It's definitely the case that I can chose to align my data structures.
Have a read of the bit about packing:

http://en.wikipedia.org/wiki/Data_structure_alignment

In some of my C++ programs I work with DIBs. You can manipulate the 
bytes in these whereas you can't with a bitmap (it belongs on the 
hardware side of things).
These DIBs have to be a multiple of 4 bytes wide.

Have to dash!
I must read it myself.

John



Alan Pinstein wrote:
> 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
>
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>