[cairo] [PATCH/RFC] ARM NEON fixes for pixman

[Siarhei Siamashka]

On Mon, Jul 13, 2009 at 2:28 PM, Koen Kooi wrote:
> On 13-07-09 04:37, Siarhei Siamashka wrote:
>> Hi,
>>
>> The attached patches make pixman usable again on ARM with NEON.
>>
>> The first two patches address serious bugs (by just disabling/reverting
>> problematic code). The other two fix mostly minor/theoretical problems, but
>> would be also nice to have.
>
> Since the current pixman is unusable (pretty much every cairo using app
> crashes and Xorg triggers glibc errors), it can't get much worse, so
> please apply this patch.

It should actually get as good (or as bad) as C code with these
changes applied. Pixman passes all my tests and works without any
visible glitches on the device.

RFC status is because these patches do not follow new naming
conventions yet. I'm just not sure if the dust has settled down
already or some new renaming/reformatting changes are coming, so cared
only about functional changes for now.

Additionally I propose to remove all the parts with RVCT intrinsics
and would like to get some feedback. Currently they just clutter the
code with ifdefs, increase source file size and (as far as I know)
nobody stands behind them at the moment to provide testing and fixes.
It probably would be a good idea to have RVCT style intrinsics in a
separate source file if they are to be used in some configurations
after all.

I have no idea if Jonathan has any immediate plans to work on fixing
bugs in his code. I'm not trying to sound negative, not all of it is
broken, some of the functions work just fine. But the right way to
proceed would be to keep buggy functions disabled or even completely
purged in pixman master. And when/if the fixes become available, test
them using all the available automated tests and properly review code
before committing. If precision can be relaxed (or even improved) in
some applications in order to get more performance, special tests are
needed to ensure that the differences between the output of optimized
code and the output of generic C code are reasonable. I will provide
some YUV optimizations shortly and will demonstrate how this can be
done.

Seems like the reliability is getting more or less under control now
and it will be possible to focus on performance from now on.

-- 
Best regards,
Siarhei Siamashka