[PATCH 00/10] Clean up fb's 64-bit-wide path

[Mark Kettenis]

> From: Adam Jackson <ajax at redhat.com>
> Date: Mon, 10 Mar 2014 11:04:24 -0400
> 
> fb is somewhat independent of machine word size, in that the code is written
> in terms of abstract types.  There's code to handle FbBits of either 32 or
> 64 bits; the latter has bitrotted, and no longer compiles.  I was hoping to
> test whether the 64-bit path was any faster on current 64-bit machines, so
> this series (1 through 8 anyway) gets it back to the point of building.
> 
> The last two are more rough sketches of what you'd need to do to make it
> actually work; I don't intend for them to be merged as is.
> 
> In case you were wondering how it performs: slightly worse, I think?
> Which makes sense, if your pixels are smaller than your word size
> then you're going to be spending time masking pixels together that
> you wouldn't if they matched, and you're not really going to gain
> much write throughput since d$ writeback will combine adjacencies
> anyway.  Given that X11 fundamentally can't cope with >32 bit
> pixels, it might make sense to just drop the 64-bit path entirely.

I also suspect that that the 64-bit path might break cases where the
endian-ness of your framebuffer doesn't match the endian-ness of your
machine and you've mapped the framebuffer in a way that does
byte-twisting in hardware.