OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 11:56 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Multiboot2 spec for RGB colours.
PostPosted: Thu Jun 24, 2021 4:43 am 
Offline

Joined: Fri Jul 10, 2020 9:27 pm
Posts: 5
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


Top
 Profile  
 
 Post subject: Re: Multiboot2 spec for RGB colours.
PostPosted: Thu Jun 24, 2021 9:53 pm 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
They can't exceed framebuffer_bpp bits in total, and they can't overlap each other.


Top
 Profile  
 
 Post subject: Re: Multiboot2 spec for RGB colours.
PostPosted: Thu Jun 24, 2021 11:45 pm 
Offline

Joined: Fri Jul 10, 2020 9:27 pm
Posts: 5
Is there a limit on the framebuffer_bpp?


Top
 Profile  
 
 Post subject: Re: Multiboot2 spec for RGB colours.
PostPosted: Fri Jun 25, 2021 8:33 am 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
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.)


Top
 Profile  
 
 Post subject: Re: Multiboot2 spec for RGB colours.
PostPosted: Sat Jun 26, 2021 1:43 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
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


Top
 Profile  
 
 Post subject: Re: Multiboot2 spec for RGB colours.
PostPosted: Sun Jun 27, 2021 5:37 pm 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
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.


Top
 Profile  
 
 Post subject: Re: Multiboot2 spec for RGB colours.
PostPosted: Sun Jun 27, 2021 9:22 pm 
Offline

Joined: Fri Jul 10, 2020 9:27 pm
Posts: 5
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 ... ?


Top
 Profile  
 
 Post subject: Re: Multiboot2 spec for RGB colours.
PostPosted: Sun Jun 27, 2021 10:51 pm 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Amazonbot [bot], Bing [Bot], Google [Bot], Octocontrabass and 87 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group