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~
