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

[Siarhei Siamashka]

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
-------------- 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/a86b8cbe/attachment.pgp>