Multiboot2 spec for RGB colours.

[vinnie]

Hi Guys

I can't seem to find any limits on the RGB colour sizes for Multiboot2 Frame Buffers. I.e. framebuffer_red_mask_size, framebuffer_red_field_position, etc.

Being defined as a u8, it can obviously not be larger than 255 bits, but that seems rather impractical to implement as worst case guarantee. The example code uses a u32 to compute the colour, but I'm not sure this is a guaranteed limit either.

Are there any bounds defined for these properties? How do you guys write your unit tests?

Cheers
-Vinnie

[Octocontrabass]

They can't exceed framebuffer_bpp bits in total, and they can't overlap each other.

[vinnie]

Is there a limit on the framebuffer_bpp?

[Octocontrabass]

It's unlikely to ever exceed 64. (There's no practical use for more than 16 bits per channel or more than 3 channels. Pixel data is often padded to power-of-2 boundaries in memory.)

[bzt]

It's unlikely to ever exceed 64. (There's no practical use for more than 16 bits per channel or more than 3 channels. Pixel data is often padded to power-of-2 boundaries in memory.)

I would say 32 bit is more reasonable (3 * 8 bit channels plus a padding for dword access). I've once seen a very old video card that used 96 bits (3 * 32 bit channels, using float), but that's very uncommon, and it was before 32 bit true-color framebuffers and VESA 2.0 got widespread. Today all float color channels are solely used by the GPU, and not on framebuffers which are shared with the CPU (however I believe on some cards you can set up a fragment shader to use float channels not only on the textures, but on the output framebuffer too. Anyway, nobody does that, even if it's possible because it quadriples the buffer's size without real benefit).

Cheers,
bzt

[Octocontrabass]

I would say 32 bit is more reasonable (3 * 8 bit channels plus a padding for dword access).

There are displays that support 10 bits per channel. You might end up with each channel padded to 16 bits and the entire pixel padded to 64 bits.

[vinnie]

Cheers. For performance sake, I ended up writing three versions, 32, 64 and generic that can support up to 256bit. I also applied the rules:

They can't exceed framebuffer_bpp bits in total, and they can't overlap each other.

I think that address all the buffer size cases.

Today all float color channels are solely used by the GPU, and not on framebuffers which are shared with the CPU...

I did not even think about float colours, though multiboot does not seem to even mention it in passing. It should not result in a buffer overflow / underflow if it's the wrong type of the same size, so I think that can be parked as a zero risk ... ?

[Octocontrabass]

It should not result in a buffer overflow / underflow if it's the wrong type of the same size, so I think that can be parked as a zero risk ... ?

Correct. If the type is wrong, you'll get very strange colors, but no overflow/underflow.