qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pixman_blt on aarch64


From: BALATON Zoltan
Subject: Re: pixman_blt on aarch64
Date: Sat, 4 Feb 2023 17:57:27 +0100 (CET)

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?

On Sat, 4 Feb 2023, BALATON Zoltan wrote:
Hello,

I'm trying to involve the pixman list in this thread on qemu-devel list started with subject "Display update issue on M1 Macs". See here:

https://lists.nongnu.org/archive/html/qemu-devel/2023-02/msg01033.html

We have found that on aarch64 Macs running macOS the pixman_blt and pixman_fill functions are disabled without fallback due to not being able to compile the needed assembly code. See detailed discussion below.

Is there a way to fix this in pixman in the near future or provide a fallback for this in pixman? Or do I need to add a fallback in QEMU or try using something else instead of pixman for these functions?

Thank you,
BALATON Zoltan

On Sat, 4 Feb 2023, Akihiko Odaki wrote:
On 2023/02/03 22:45, BALATON Zoltan wrote:
On Fri, 3 Feb 2023, Akihiko Odaki wrote:
I finally reproduced the issue with MorphOS and ati-vga and figured out its cause.

The problem is that pixman_blt() is disabled because its backend is written in GNU assembly, and GNU assembler is not available on macOS. There is no fallback written in C, unfortunately. The issue is tracked by the upstream at:
https://gitlab.freedesktop.org/pixman/pixman/-/issues/59

Hm, OK but that ticket is just about compile error and suggests to disable it and does not say it won't work then. Are they aware this is a problem? Maybe we should write to their mailing list after we're sure what's happening.

That's a good idea. They may prioritize the issue if they realize that disables pixman_blt().

I hit the same problem on Asahi Linux, which is based on Arch Linux ARM. It is because Arch Linux copied PKGBUILD from x86 Arch Linux, which disables Arm backends. It is easy to enable the backend for the platform so I proposed a change at:
https://github.com/archlinuxarm/PKGBUILDs/pull/1985

On macOS one source of pixman most people use is brew.sh where this seems to be disabled:

https://github.com/Homebrew/homebrew-core/blob/master/Formula/pixman.rb

another source is macports which has an older version and no such options:

https://github.com/macports/macports-ports/blob/master/graphics/libpixman-devel/Portfile

I wonder if it compiles from macports on aarch64 then.

It's more likely that it is just outdated. It does not carry a patch to fix the issue.

I wait if I can get some more test results and try to check pixman but its source is not too clear to me and there are no docs either so maybe the best way is to ask on their list. If this is a pixman issue I hope it can be fixed there and we don't need to implement a fallback in QEMU.

This is certainly a pixman issue.

If you read the source, you can see pixman_blt() calls _pixman_implementation_blt(). _pixman_implementation_blt() calls blt member of pixman_implementation_t in turn. Grepping for "blt =" tells it is only assigned in:
pixman/pixman-arm-neon.c
pixman/pixman-arm-simd.c
pixman/pixman-mips-dspr2.c
pixman/pixman-mmx.c
pixman/pixman-sse2.c

For AArch64, only pixman/pixman-arm-neon.c is relevant, and it needs to be disabled to build the library on macOS.

Regards,
Akihiko Odaki


Regards,
BALATON Zoltan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]