[Pixman] 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~
>
>