I landed some improvements and small optimizations to #pixman's AltiVec code. See https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/136

It was fun working with a new (to me) instruction set and trying to figure out how to puzzle together the pieces into something that improved the `pix_multiply()` function (which is kind of the core primitive of most fast paths).

I couldn't figure out a way to use the `vec_mradds`/`vmhraddshs` instruction. Maybe you can? (see https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/136#note_2699795)

#altivec #powerpc #simd

I fixed an issue in pixman's Altivec code the other day -- https://cgit.freedesktop.org/pixman/commit/?id=207626180d0282bb14a50f2e494174f54ac8a6ce

And in the process, I read through the Altivec docs and discovered that there are vector instructions that pack and unpack between a8r8g8b8 and a1r5g5b5 formats (but nothing fo r5g6b5).

Any clues why? Was a1r5g5b5 really common on Mac OS or something? I don't think I've seen a1r5g5b5 used anywhere.

#powerpc #altivec #simd #macos9 #pixman

Today's bug is a tiny `pixman` `riscv64` compiler feature detection bug: https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/128

There `pixman` failed to build on `gcc-13`. Of two required `vfloat32m1_t` and `vfloat32m1x4_t` intrinsic types `gcc-13` defines only `vfloat32m1_t`. While `gcc-14` and later define both.

#pixman #bug

I'm trying to fix a patch to allow #pixman's #ARM #NEON #assembly code to build with clang. They perform a lot of mechanical changes to switch to the "unified" ARM assembly syntax (`.syntax unified`), supported by both #gcc and #clang.

With clang the code builds but fails 3 of the tests in the test suite with what appear to be unaligned accesses. With gcc, the test suite passes before and after the patches.

I've muddled through as much debugging as I can. Any ideas? https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/78#note_2078065