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

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> 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.

Yeah, that's not hard to believe, although of course the 64-bit paths
should only be executed when writing more than one pixel at a time.

64 bits was a huge win for 16bpp screens when drawing the root weave;
otherwise, it's really not very interesting.

> Given that X11 fundamentally can't
> cope with >32 bit pixels, it might make sense to just drop the 64-bit path
> entirely.

Having two paths is crazy; if 64 bits is actually slower even on 64 bit
machines, we should just pitch it. The original fb goal was to only
support 64 bit reads/writes, but that's just not practical given X
image formats.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140310/9e829a3d/attachment.pgp>