[cairo] [PATCH/RFC][pixman] More ARM NEON performance updates

[Soeren Sandmann]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> This all seems way too complex to me and implies that there would be an extra
> overhead introduced on every image creation.
> 
> The branch 'fetch-r5g6b5-arm-neon' has much more simple solution and an extra
> overhead happens just once at setup time. It is not like CPU features are
> going to change at runtime 

The main problem I have with it is that it causes ARM stuff to 'leak'
out outside of the ARM implementations. It introduces an undocumented
inter-dependency between implementations: they now have to be created
in a specific order, or they will overwrite each other's fetchers. 

> (hmm, some weird experiment like "hibernate ->
> change cpu -> attempt to resume working" could try it, but I don't think
> anything can be guaranteed in this case :) ).

Let's not give the virtualization people ideas :-)

> Also somewhat unrelated notice. Setting up accessors currently involves linear
> search in 'accessors' array. Data for a8r8g8b8 and x8r8g8b8 formats is
> available as the first entries in it, but looking r5g6b5 or a8 formats takes
> longer. Maybe sorting the entries based on importance would be a good idea? Or
> another cache for accessors is a better solution?

If it really matters, sure, they could be reordered.




Soren