> From: Adam Jackson <[email protected]> > 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
