A lot of Metal examples, including ones from Apple, use MTLPixelFormat.bgra8Unorm as the pixelFormat in the pipeline state. I was wondering if you had any insight as to whether or not this might be preferred over, say, MTLPixelFormat.rgba8Unorm, which has a more familiar RGBA ordering or even something like MTLPixelFormat.rgba8Unorm_srgb.
I remember some old graphics cards/OpenGL drivers preferred BGRA, which made it a faster choice in some cases. I had thought that was lost in the past though.
Perhaps there is a later section of the book that discusses when and why to choose one of the other many formats. I haven’t looked ahead yet.
Thanks,
~chuck
I’m not sure why Apple chose BRGA rather than RGBA - it’s probably for historical reasons, and it may be faster on the GPU because of that.
But the real reason for using BGRA here is because MTKView only allows a few pixel formats: Apple Developer Documentation
You wouldn’t use a float texture here because you only need 0 to 255. Later on, in deferred rendering, you’ll use a float texture when you need more accuracy.
You can use RGB for textures, as long as it’s not going to a view’s drawable texture. I probably do use RGB in places.
1 Like
Reviving an old topic for people googling an answer:
There’s no technical reason. Hardware could deal with the bytes in any order.
The reason is one of convenience for programmers. The X86 and the ARM are little endian processors. So when writing an unsigned integer as a literal in code they are the reverse order to how they appear in actual memory.
uint32 pixel = 0xAARRGGBB;
So the Red, Green and Blue appear in the expected order.
The Alpha comes first, because for situations where you don’t care about the alpha, you can just leave it out.
uint32 pixel = 0xRRGGBB
5 Likes