[cairo] Pixman refactoring, ARM and Altivec implementations needed

[Siarhei Siamashka]

On Thursday 28 May 2009 12:29:01 ext Jonathan Morton wrote:
> > I have merged this branch to master now. A "make perf" in cairo's
> > performance test suite doesn't report any real differences in
> > performance.
> >
> > With this change, the general C implementations lives in
> > pixman-general.c and is fairly readable, but there are some remaining
> > traces of architecture specific code. Fixing this should be
> > straightforward:
> >
> >         - A pixman_implementation_create_{simd,neon,vmx} function
> >           needs to be written, similar to the one for sse2.
> >
> >         - The pixman_choose_implementation() code in pixman-cpu.c
> >           should be updated to call this.
> >
> >         - For arm-simd and arm-neon, the implementation should get a
> >           'composite' virtual function, which calls
> >           pixman_run_fast_path on the fast_path array, and falls back
> >           if that returns FALSE.
>
> Sigh.  I had to edit quite a lot of crap to make things simply work
> again on ARM, mostly updating the prototype of every single compositing
> blitter in the ARM-SIMD and NEON implementations.
>
> The resulting patch won't apply cleanly against master, because of all
> the extra blitters I'm staging, for which I also had to edit the
> prototypes.  If it did apply cleanly, I'd attach it here.
>
> That's without actually making use of the new architecture, just
> minimally fixing the compile breakage.
>
> I plan to send these blitters upstream very soon, but this kind of
> lossage is *exactly* what I was hoping to avoid.  :-(

I understand and share your pain. But I guess upstream is just happy that
someone who can fix those issues is around, and takes it as a chance for
introducing some long planned changes :-)

I personally would prefer to get all the high level optimizations integrated
into pixman first. Those are quite problematic to keep in sync with upstream
when upstream code is undergoing refactoring. On the other hand, assembly
optimized blitters are quite isolated and it is much harder to break them on
refactoring, so those are relatively safe.

I'm also a bit worried about the stability of code. It would be not very good
if a lot of new bugs get introduced during this refactoring process.

But an alternative, which I would prefer to avoid myself, is to take some
current stable pixman snapshot, apply all the performance patches, fixes and
improvement on top of it and ship with the product. That's would essentially
end up as a dead branch, like what happened with Xomap.

-- 
Best regards,
Siarhei Siamashka