[cairo] Transform optimization

[André Tupinambá]

I created a test version of pixman thats logs all calls to the
transformation code. I use it to analyze this calls and find another
opportunities to optimize the code.

Running the cairo-perf, with this log, I saw thats many operations
uses the mask parameter. So, I changed the fast-path to work with this
parameter too. And the good news are that the performance is as good
as the old fast-path in calls with no mask, and works great with the
calls that use it.

Please check the new patch attached.

BTW, I installed a 32bits linux (in my old mobile P4) and ran the the
cairo-perf with bilinearInterpolation optimized with uint64_t
variables. And my worries was confirmed, this version is slower than
the 32bits one. I don't know if keep this two versions is a problem,
looks good for me.

Happy New Year

André Tupinambá

On Tue, Dec 30, 2008 at 12:33 AM, André Tupinambá <andrelrt at gmail.com> wrote:
> Hi Soeren,
>
> I'm still working in optimizing the transformation code (er... I ran a
> little busy :). But I just built a pixman version following your
> approach and created a fast-path to this special case.
>
> The good news are, this new code is 3.5x faster in my Turion in some
> cases (with Ubuntu 8.10 x64) and only with C code optimization (no MMX
> or SSE2). The bad news are, I used some uint64_t variables to optimize
> the calculations and I don't know if they perform good with 32bits
> code (I have no 32bits Linux), so I implement a optimized version of
> bilinear interpolation with 32bits (I choose each one with #ifdef).
>
> If anyone test it for me, I will be very glad (it's just adjust the
> #ifdef, compile and run the cairo-perf :).
>
> I didn't tried to ran this code with VTune analyzer yet, and I expect
> that is possible to optimize this code a little more, but not too
> much. So I'm thinking if the best approach is to find another special
> case and create another fast-path to them, instead to try to work with
> VTune now.
>
> Happy New Year
>
> André Tupinambá
>
>> The better fix here is to write a bilinear fetcher that special cases
>> for the common case of
>>
>>        - image has format x8r8g8b8 or a8r8g8b8
>>        - the transformation is affine
>>        - there is no source clip
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transform_fast-path.patch.bz2
Type: application/x-bzip2
Size: 3118 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20090101/4ad25298/attachment.bin