Re: pixman_blt on aarch64

[Richard Henderson]

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.
>
> 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.

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~