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. > Meanwhile we seem to have a problem identifying the cases when the standard- > form fastpaths *can* be used. That's just bug, partially caused by having somewhat more complicated than necessary legacy code inherited from xserver. The flags system is not at fault. I think the problem is going to be fixed and everyone will be happy again :) > Oddly enough, I have to solve much the same problem when writing EXA > drivers, since EXA presents information about the operation in a similar > way as to Pixman. I do so in a much simpler manner: > > - I go through each of the features that I know the hardware doesn't > support, such as unusual image formats, alpha maps or component-alpha. > If any of these are set, I tell EXA to fall back to software > immediately. > > In Pixman itself, this could simply be setting an ON_CRACK flag (at > least for alpha maps and custom accessors) which forces use of the > general path. > > - Next, I examine the transform, filter and repeat state, and use that > to construct a "fetchmode" index. This has distinct values for "solid" > and "untransformed and covers clip" which are easily tested for later. > The fetchmode fits in 8 bits per source, so 16 bits are enough for a > masked operation. This is small enough to make a direct lookup table > feasible if necessary. > > A big feature of this is that the definitions of the "covers clip" and > "solid" modes are mutually exclusive, and the "solid" mode doesn't care > what repeat mode is used to trigger it as long as it's not "normal". If > an image is solid, I don't even need to check whether a transform is set > on it - I only need the dimensions and the repeat mode. Thanks for sharing the details about your implementation. For this particular "covers clip" vs. "solid" case, I think it's not like we don't know what to do to fix it. It's quite the opposite, we actually have multiple alternatives to select from ;) > Some fetchmodes may not be supported by the hardware, so I make these > fall back to software at this point too. This is equivalent to > searching the fastpath list in Pixman. > > The common cases are as follows: > > - Source covers clip without transform, no mask, no crack. > - Source is solid, mask covers clip without transform, no crack. > - Source is transformed (typically in a less-than-general manner) and > may or may not cover clip, no mask, no crack. > > Surely it's worth optimising the flags generation for these common > cases? I think pixman still does not have all the needed hooks for plugging different types of optimizations yet, so it's a bit too early to "tighten" this code and add shortcuts based on some assumptions. Currently I need to somehow introduce ARM NEON optimized over_0565_8_0565 operation when the source image is scaled (using nearest filer so far) and actively uses PAD repeat. Mask image fortunately does not use any kind of transformation and "covers clip". This case is a little bit more complex than the ones you described above. And I guess, more complex compositing optimizations may need to be added later. That said, I think that having a new microbenchmark program for measuring pixman function call and fast path selection overhead could be very useful. Just in order to be able to easily spot obvious (and easily fixable) performance problems/regressions when tweaking this flags setting and fast path selection code. -- 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
