[Pixman] [PATCH] Don't discriminate PAD and REFLECT repeat in standard fast paths

[Siarhei Siamashka]

On Tuesday 28 September 2010 14:55:41 Siarhei Siamashka wrote:
> On Monday 27 September 2010 17:51:32 Jonathan Morton wrote:
> > If I may inject an alternative point of view into this lively
> > discussion...
> > 
> > I think the current flags system is overcomplicated for the common case.
> > If any one of a wide variety of flags is set for an operation, this
> > excludes a huge number of potential fastpaths.
> 
> That's not quite true. Adding new flags has no effect on the selection of
> the existing fast paths. New flags provide a possibility to add more
> special fast paths which require these flags.

I think a bit more detailed explanation might be useful.

The flags in pixman are implemented in such a way that they all have some kind
of "positive" meaning, indicating that the operation is going to be more simple
than the general case in one way or another. Having more flags set on the 
initial analysis stage is always good. Forgetting to set some of the flags is
safe in the sense that it will not make pixman misbehave, pixman will just run
slower because of not taking some fast paths.

Each fast path function has a mask with flags (provided separately for source,
mask and destination), with each bit set there telling something like "I can't
handle case X" (or with alternative interpretation "I can't handle cases other
than Y"). Fast path functions with many flags set in their description are
allowed to cut more corners and run a lot faster because of this.

When asked to do something via pixman_image_composite() function call, pixman
first calculates the flags for the current operation (again, separately for the
source, mask and destination images). Setting each bit is kind of like telling
to the the rest of the code: "You are allowed not to care about case X". 

With all the flags for the current operation available, fast path selection
code just walks over the list of available fast path functions and selects the
first one with matching flags. It is possible to have multiple functions in the
list with the flags matching to the current operation, so the list should be
just ordered so that the better fast path functions are checked first. Platform
specific SIMD optimizations naturally come first in the list, then followed by
fast path functions implemented in C, and finally falling back to a very slow
general implementation (which is capable of handling any operation).

There may be also some overlap in fast path functions functionality, providing
multiple alternatives to do the same operation in some corner cases. For
example, when having nearest neighbor scaling for a8r8g8b8 images with NORMAL
repeat but not trying to access any pixels outside image boundaries, either 
'fast_composite_scaled_nearest_8888_8888_cover_SRC()' or alternatively 
'fast_composite_scaled_nearest_8888_8888_normal_SRC()' can be selected.
The former fast path function works faster, so it is better to be put in the
list first.

Walking over the list of fast path functions can be relatively slow. That's why
whenever some fast path function is found in the list, it is put into fast path
cache. This improves performance when similar operations are repeatedly used.


Regarding possible optimization when pixman flag types become more settled
less likely to change. Evaluating all the possible flags in the initial
analysis stage may be somewhat slow. Theoretically, if we know that we have
some extremely fast function which only needs flag A, then we can cut some
corners skipping calculation of the rest of flags B, C, D, E and move to fast
path selection code immediately. One of the examples could be (yet to be
introduced?) SOLID flag. If we already have it set, then we don't care much
whether we also have any transformation, its type, filter, repeat, etc. But
this kind of optimization may make code less readable/maintainable, so IMHO can
be only used when really justified by a significant performance increase.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20100928/2e73f44f/attachment.pgp>