[Pixman] Selectively disabling fast paths

[Pekka Paalanen]

On Thu, 27 Aug 2015 17:20:26 +0100
"Ben Avison" <bavison at riscosopen.org> wrote:

> On Thu, 27 Aug 2015 10:59:52 +0100, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > It would be *really* nice if we could somehow use a benchmark mode
> > where we could run an operation with every possible implementation and
> > compare them. I wonder, can we already do that with PIXMAN_DISABLE?
> 
> That would certainly help detect some issues, where we get worse
> performance at supposedly more advanced implementation levels. Obviously
> it wouldn't make any sense to bother with certain combinations, such as
> PIXMAN_DISABLE=arm-neon when testing on an x86.
> 
> One thing it wouldn't be able to detect, though, would be where the fetch/
> combine/writeback iterators are faster than fast paths for the *same*
> implementation level - such as with the ARMv6 nearest-scaled patches I
> was revisiting recently. In that specific case, it turned out that my
> original solution of bespoke C wrappers for the fetchers turned out to be
> even faster - but we don't have any way at present of detecting if there
> are other cases where we would be better off deleting the fast paths and
> letting the iterators do the work instead.

Sorry, but I'm a bit hazy on the details here. Based on the
discussions, I have developed the following mental model:

1. asm fast paths (whole operation)
2. C fast paths (whole operation)
3. _general_composite_rect (fetch/combine/writeback; iterators)
   - asm implementation or
   - C implementation for each

So, 1. is the highest priority, then 2. and finally 3. Between these we
can choose with PIXMAN_DISABLE. "fast" disables the C fast paths, and
the others disable the asm fast paths implemented with those particular
CPU features.

Do I understand that right?

And your point is, if we disable some asm fast paths, it will also
disable the asm implementations of the fetch/combine/writeback
iterators?

What you refer to as "implementation level" is really the CPU feature
set we can disable with PIXMAN_DISABLE?

Maybe we could fix that by introducing a PIXMAN_DISABLE=wholeop or
similar, that would disable all whole operation fast paths, but leave
the iterator paths untouched?

Should I do that, would it be worth it?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20150828/dd250174/attachment-0001.sig>