Performance hit for BGR?

[Mezz]

Hi,

I am wondering about specifying image data to OpenGL in different ways during texture creation.

As you probably know, TGA files usually have a BGR byte order and I used to manually swap this round on the CPU and then send it to OpenGL as RGB, but with BGR support being practically universal I'm considering using this and omitting the manual swapping step.

What I'd like to know is if there would be any kind of performance drop in specifying data this way (I was thinking if the driver/card would convert the byte ordering itself then that might be the case).

Thanks,

-Mezz

[Nutty]

You shouldn't get any performance drop for specifying texture data as BGR. On some hardware creating the texture may even reduce in time. Although it will have no effect on rendering speed.

[zed]

with texture creation packed pixels will *can/maybe* give u the best speed
also BGR is generally quicker
but as always test yourself

[Mezz]

Packed pixels? Do you mean somekind of compression or just a stride of zero?

-Mezz

[FuNKySoULyBrO]

Hi, I have come across a nehe tutorial, and they provide an assembly code to do this flipping of BGR to RGB and vice-versa in a much faster way. Dun know is it of help to u.
Credit goes to Jeff Molofee's Lesson 36 http://nehe.gamedev.net

void flipIt(void* buffer)
// Flips The Red And Blue Bytes (256x256)
{
void* b = buffer
__asm {
mov ecx, 256*256
mov ebx, b label: mov al,[ebx+0] mov ah,[ebx+2] mov [ebx+2],al mov [ebx+0],ah add ebx,3 dec ecx jnz label }
}

[zed]

i can optimze that even more

// Flips The Red And Blue Bytes (256x256)
{
return;
void* b = buffer
__asm {
mov ecx, 256*256
mov ebx, b label: mov al,[ebx+0] mov ah,[ebx+2] mov [ebx+2],al mov [ebx+0],ah add ebx,3 dec ecx jnz label }
}

the fastest code is the stuff that aint called.

anyways packpixels is an extension (nearly all cards support it)