Optimising xserver (Xft text rendering improvements)

[Keith Packard]

Around 9 o'clock on Mar 27, Lars Knoll wrote:

> I had the same thought, but I think working on a whole line of the
> destination might give you better cache performance in most cases (ie. all
> cases where you don't have a transformation on the destination). 

Right, but I'm thinking that the general case code is much more likely to 
be hit when a filter or transformation is involved, both of which require 
non-linear access to the pixel data.  For that, and because I suspect 
using fixed size patches (8x8, or perhaps 16x16) will reduce register 
pressure, I'd like to try this approach.

Using relatively small patches of 8 lines should ensure that the
consecutive lines of source needed should all fit in the second level cache 
while the patches themselves remain in first level cache.

Furthermore, I envision building a patch cache mechanism so that filters 
and scaling algorithms can re-use old upstream patches without needing to 
recompute them.  I think a simple LRU replacement strategy with a 
pre-computed cache size will eliminate thrashing entirely (you can compute 
up-front the maximum number of patches needed in the cache).

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050327/7dcfaf7b/attachment.pgp>