Callum Lerwick wrote:
For a while now, in XFree86/Xorg, setting depth 24 refers to the
color depth, not padding. The driver is to set the actual framebuffer
depth to 24 or 32 bits as is appropriate for the hardware. AFAIK on most
hardware, padding 24bit out to 32 bit performs faster.
Correct. And you mean all hardware, at least on PCI systems, since the
bus is 32 bits wide and if you do 24bpp packed pixels then most of your
pixel accesses will be unaligned and will need two bus cycles. Similar
caveats apply to internal memory accesses triggered from the GPU to
VRAM, the address calculation and pixel unpacking are significantly more
We will occasionally prefer 24bpp packed pixels, but that's mostly just
for vesa(4), which is unaccelerated anyway, and where the memory savings
translates to possibly higher resolutions fitting in memory.
For the cards that support 30 bit color you're typically still doing 32
bit words, with the extra two either unused or used for alpha. Most of
the newer desktop-class cards support this in silicon, but X still has
one or two issues that prevent us from supporting it (mostly just bugs
as opposed to design flaws).
No idea how Xorg plans to handle this new fangled HDR thing...
HDR typically refers to using floating point color buffers; X as
currently written just doesn't support that at all. There are various
GL extensions (in various states of patent coverage, rrgh) to enable
floating point color buffers for either texturing, rendering output, or
Which we don't support yet, of course. I'm of the opinion that
requiring apps to use GL or some pleasant frontend to it in order to get
HDR is perfectly okay.