[cairo] [PATCH] Fixes for ARM features runtime autodetection support
siarhei.siamashka at gmail.com
Mon Jun 29 01:25:06 PDT 2009
On Monday 29 June 2009, Jonathan Morton wrote:
> > More serious is a problem with the newly added functions
> > fbCompositeSolid_nx0565neon and fbCompositeOver_8888x0565neon.
> > They are quite broken. And (not a) surprise - this breakage
> > can be easily spotted by all the same 'scaling-test' program.
> Okay, I'll try to reproduce that and see what I can do about it.
Just running 'test/scaling-test' should survive and produce the same crc32
value as on x86 (or as with neon optimizations disabled). To catch memory
errors easier in gdb, malloc can be replaced by allocations using mmap,
allocating buffers on the right "edge", so that accessing any data outside
buffer would immediately crash.
Problems seem to be related to wrongly assuming that moving to the next pixel
line would not change 16 byte alignment, but destination stride is only
required to be 4 bytes aligned.
Is there really a strong need to copy data to the temporary buffer on stack?
There are plenty of NEON registers still unused and they could serve as a
temporary storage just fine.
More information about the cairo