Page 1 of 1

Multiboot2 spec for RGB colours.

Posted: Thu Jun 24, 2021 4:43 am
by 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

Re: Multiboot2 spec for RGB colours.

Posted: Thu Jun 24, 2021 9:53 pm
by Octocontrabass
They can't exceed framebuffer_bpp bits in total, and they can't overlap each other.

Re: Multiboot2 spec for RGB colours.

Posted: Thu Jun 24, 2021 11:45 pm
by vinnie
Is there a limit on the framebuffer_bpp?

Re: Multiboot2 spec for RGB colours.

Posted: Fri Jun 25, 2021 8:33 am
by 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.)

Re: Multiboot2 spec for RGB colours.

Posted: Sat Jun 26, 2021 1:43 am
by bzt
Octocontrabass wrote: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

Re: Multiboot2 spec for RGB colours.

Posted: Sun Jun 27, 2021 5:37 pm
by Octocontrabass
bzt wrote: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.

Re: Multiboot2 spec for RGB colours.

Posted: Sun Jun 27, 2021 9:22 pm
by 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:
Octocontrabass wrote: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.
bzt wrote: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 ... ?

Re: Multiboot2 spec for RGB colours.

Posted: Sun Jun 27, 2021 10:51 pm
by Octocontrabass
vinnie wrote: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.