Optimising xserver (Xft text rendering improvements)

[Adam Jackson]

On Friday 25 March 2005 15:47, Soeren Sandmann wrote:
> Adam Jackson <ajax at nwnk.net> writes:
> > > Passing 12 arguments to a function really is a performance killer and
> > > I'd like to think this could be kept in mind when further developing
> > > xserver (or any software in general!).
> >
> > Yes, definitely.  There are lots of places where we do things that are
> > stylistically fine but that don't generate good code at all.  The
> > software Render path is the egregious offender, but there are others.
>
> Before getting rid of those 12 arguments, I'd really like to see
> numbers. Usually almost all of the time in the fb layer is spent in
> loops in the leaf functions; almost none actually calling the
> functions.

The exception being fbcompose.c, where we call at least four functions per 
pixel in the untransformed case, each function being pretty close to trivial.  
This totally defeats any attempt the compiler might make at CPU pipelining.  
And you can't just mark the leaves inline, because we call them through a 
dispatch table.  Some judicious unrolling here would probably make software 
Render blow a lot less.

> > I've got a few ideas about ways to improve the fb layer, and the loadable
> > modules in general:
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=2749
> >
> > Like all good changes this has the possibility of breaking an ABI, so I'd
> > appreciate some more eyes on it.  Your changes are complementary to what
> > I've been thinking about so I'd like to merge them in eventually.
>
> These changes make a lot of sense to me. I can't really comment on
> whether they break ABI; in the absence of specific objections, the way
> to find out is to just go ahead and do it, and see if anything breaks.

Well those changes as they are, will break the pseudocolor emulation Egbert 
did because I missed xxScreenInit.  Oops.

I can easily define the de-facto ABI of the fb layer by finding the 
intersection of (exported symbols from libfb.so) and (undefined dynamic 
symbols from any other module).  This will provide a sufficient ABI for the 
world as it is now; I don't know that it provides the necessary ABI for the 
road ahead.

For example.  The glint driver wants fbBres for some reason, but basically no 
other actual drawing operation is required by any other module.  Is this 
okay?  Do we also want to expose fbBlt?  Probably, since the overlay code 
wants that.  What about fbArc?  And if fbArc is okay, do we expose the 
optimised versions for each depth?  Or do we try to find someone to fix the 
glint driver (hah!) ?

Where's the line, in other words.  I don't want to have to keep adding 
functions to the export list.  I want to get it right and move on.

Similar arguments will start applying to the dynamic symbol table of the 
server pretty soon.  My understanding is that elfloader requires SYMFUNC/
SYMVAR statements for every symbol that should be visible to the loaded 
modules.  libdl has no such requirement, it'll just snag the first matching 
dynamic symbol.  This means every function and variable in the server 
executable with greater than static scope is visible from the modules.  
That's a terrible way to design an API.

The danger there is that some third party will develop a module that relies on 
some bit of internal state that happens to get exported, and then we'll 
change the implementation, and the driver breaks.  No one wins in that 
situation.  We lose the flexibility to fix the implementation, vendors have 
to expend more effort to work around our changes, and users just get angry.  
Whereas we could have just enforced our ABI to begin with.

You could read that as an argument in favor of open drivers, I suppose.  
Unfortunately we don't live in that world yet.  Even if we did, it's still 
bad design.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050325/6f1506fd/attachment.pgp>