Re: pixman_blt on aarch64

[BALATON Zoltan]

Maybe we should include pixman list in this. In case you're not subscribed 
I'm forwarding it to that list now.

On Tue, 7 Feb 2023, Akihiko Odaki wrote:
> On 2023/02/06 4:16, Richard Henderson wrote:
> > On 2/5/23 08:44, BALATON Zoltan wrote:
> > > On Sun, 5 Feb 2023, Richard Henderson wrote:
> > > > On 2/4/23 06:57, BALATON Zoltan wrote:
> > > > > This has just bounced, I hoped to still be able to post after moderation 
> > > > > but now I'm resending it after subscribing to the pixman list. Meanwhile 
> > > > > I've found this ticket as well: 
> > > > > https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/71
> > > > > See the rest of the message below. Looks like this is being worked on 
> > > > > but I'm not sure how far is it from getting resolved. Any info on that?
> > > >
> > > > Please try this:
> > > >
> > > > https://gitlab.freedesktop.org/rth7680/pixman/-/tree/general
> > > >
> > > > It provides a pure C version for ultimate fallback.
> > > > Unfortunately, there are no test cases for this, nor documentation.
>
> It can share the implementation with fast_composite_src_memcpy(). 
> fast_composite_src_memcpy() should be well-tested with the tests for 
> pixman_image_composite(). arm-neon does similar so we can trust 
> fast_composite_src_memcpy() functions as blt.
>
> > > Thanks, I don't have hardware to test this but maybe Akihiko or somebody 
> > > else here cam try. Do you think pixman_fill won't have the same problem? 
> > > It seems to have at least a fast_path implementation but I'm not sure how 
> > > pixman selects these.
> >
> > For fill, I think the fast_path implementation should work, so long as it 
> > isn't disabled via environment variable.  I'm not sure why that is, and why 
> > _fast_path isn't part of _general.
>
> The implementation of fill should be moved to pixman-general.c but the other 
> part of pixman-fast-path.c shouldn't be.
>
> By isolating the non-essential fast-path code to pixman-fast-path.c, you can 
> disable it with the environment variable when you are not confident with the 
> implementation, and that may help debugging. However, if pixman-fast-path.c 
> has some essential code like the implementation of fill, the utility of the 
> environment variable will be impaired as setting the environment variable may 
> break things.
>
> > Indeed, the fast_path implementation of fill should be easily vectorized by 
> > the compiler. I would expect it to be competitive with an assembly 
> > implementation.  I would expect the implementation chain design to only be 
> > useful when multiple vector implementations are supported and selected at 
> > runtime -- e.g. the x86 SSE2 vs SSSE3 stuff.
> >
> >
> > r~