[cairo] [Pixman] Floating point API in Pixman
spitzak at gmail.com
Mon Aug 23 10:39:21 PDT 2010
Since you are showing that even *pixel operations* can be faster in
floating point, I think this is a pretty good proof that doing the
*coordinates* in floating point will be a huge win.
Jonathan Morton wrote:
>>>> I suspect using floats would be *much* better than the existing fixeds
>>>> on modern x86_64 systems. But fixed will remain important on smaller,
>>>> lighter systems for some time to come.
>>> I believe so too, and I have some actual numbers to back it up.
>> You forgot to attach the numbers. :)
> Well, here is a very brief but representative example:
> (float) src_8888_8_0565 = L1: 111.99 L2: 113.84 M:105.89 ( 20.72%) HT: 64.94 VT: 78.99 R: 55.08 RT: 23.74 ( 329Kops/s)
> (fixed) src_8888_8_0565 = L1: 62.29 L2: 63.66 M: 63.02 ( 12.64%) HT: 59.05 VT: 57.64 R: 52.52 RT: 32.20 ( 446Kops/s)
> Most of the numbers are Mpix/s, the %-age numbers in the middle are of
> estimated available memory bandwidth. The floating-point path has a
> large (50%+) advantage in throughput, while the fixed-point path seems
> to have less setup overhead which shows up on tiny (8x8) operations.
> And that's not exactly the most complex operation on the table. In
> fixed-point, it's a multiply by the unified mask followed by a 3-channel
> format conversion. Much more trivial than that and you get memcpy().
> This is all achieved by using lookup tables to accelerate the
> fixed-to-float conversions (tables are pre-generated up to 16bpc),
> leaving only the store operations to be run through a real
> float-to-fixed converter.
Such tables also allow conversion from sRGB to linear to be done as
well, producing much nicer composites. I have had pretty good luck using
the top 16 bits of floating point to do a reverse lookup back to the
integer values, again this allows conversion from linear to sRGB.
More information about the cairo