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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
