[PATCH renderproto] Add floating point transforms

[Siarhei Siamashka]

On Sun, 17 Aug 2014 14:26:13 -0700
Keith Packard <keithp at keithp.com> wrote:

> walter harms <wharms at bfs.de> writes:
> 
> > Would it make sense to use double for internal calculation ?
> > Most systems provide 64bit (or more) fpu-registers these days.
> 
> In fact, pixman exposes only double matrices at this point, so the
> server implementation stores both fixed point and floating point
> variants in that format.

Double precision floating point matrices and operations with them
(pixman_f_transform_*) are not really used as a part of the pixman
rendering pipeline. They are more like just the extra bundled
convenience utility functions. When pixman needs a transformation
matrix, this matrix is provided to it using the
'pixman_image_set_transform()' function:
    http://cgit.freedesktop.org/pixman/tree/pixman/pixman.h?id=pixman-0.32.6#n806
Which uses the 16.16 fixed point format.

There are also some useless (and even harmful) utility functions, which
are implementing operations on 16.16 fixed point matrices. If anyone
tries to use them, a lot of accuracy gets lost in the intermediate
calculations. A reasonable workflow is to do all the intermediate
calculations with double precision matrices and only convert to the
16.16 fixed point format as the final step before passing them to
pixman. Of course, if somebody knows what he is doing, then it is
possible to prepare a 16.16 fixed point matrix without resorting to
floating point calculations. But special care needs to be taken to
ensure that there is no unnecessary accuracy loss.

> However, a GPU will likely want to stick with 32 bit values, which is
> why I expressed the protocol using 32 bit floats; 64-bit computation in
> the GPU is generally much slower than 32-bit.

This does not necessarily mean that the 32-bit floats should be exposed
by the protocol or the public API. If we really need improved accuracy
(do we?), then 64-bit floats are the way to go.

IMHO it is up to the implementation to decide if the 32-bit floating
point format is accurate enough for the requested operation and take
a fast path.

-- 
Best regards,
Siarhei Siamashka