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.
_______________________________________________
Pixman mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pixman
