On Thu, 27 Aug 2015 17:20:26 +0100 "Ben Avison" <bavi...@riscosopen.org> wrote:
> On Thu, 27 Aug 2015 10:59:52 +0100, Pekka Paalanen <ppaala...@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
pgp_M1P6CfiEo.pgp
Description: OpenPGP digital signature
_______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman