Pixman Accessors

[Soeren Sandmann]

Aaron Plattner <aplattner at nvidia.com> writes:

> On Tue, Jun 09, 2009 at 09:50:05AM -0700, Soeren Sandmann wrote:
> > Pixman has a feature where you can set accessor functions on an image
> > and all pixel access will then go through those functions. It's used
> > exclusively for wfb.
> > 
> > Until now this was implemented by compiling the pixel accessors twice,
> > with a READ macro defined in two different ways. This is annoying for
> > several reasons, so instead I want to just make a copy of the image
> > before compositing, and then copy back afterwards.
> > 
> > Does anyone see a problem with this?  Performance is not a concern at
> > all. It was slow before and it will be slow after.
> 
> I know performance is not a concern, but if you're going to copy the entire
> image to malloc memory, it would be faster to use GetImage/PutImage (or
> some new pair of similar hooks) and get the GPU to do it than to grab it
> directly through the low-level accessors.  Obviously that wouldn't work on
> implementations where GetImage falls back to pixman, but there could be a
> default fallback to the low-level accessors or something if
> necessary.

Having upload/download hooks in pixman and wfb does seem useful.

The general case of software rendering with data in video memory
probably can't be treated as "never happens". There will occasionally
be things that aren't accelerated, and once an application does
something that causes a fallback, it will probably do it multiple times.

This is the issue that EXA migration spectacularly failed at
addressing. I don't have any particularly bright ideas, but I don't
really think that wrapping low level pixel access is the way forward.

Some ideas:

        - Have the kernel driver expose a linear map even when the
          hardware isn't linear. It would be made unaccessible
          initially and pages would be downloaded on demand. A
          finish_access interface would upload the pages back.

        - Make pixman understand how to render to and from nonlinear
          layouts. Support for tiling is interesting in pixman in any
          case.

        - A combination of the first two, where the kernel exposes a
          simple tiling on top of a possibly complicated one, and
          pixman/fb would know how to deal with that.

        - Have upload/download hooks in pixman.

> Changing the libwfb interface to make it easier would probably help.  I've
> been meaning to free up some time to look into making the accessor
> interface a little more sane, but you know how that goes...  It would be
> nice if libwfb could know on a per-drawable basis whether it needs to use
> the wrappers or not.  Back in the day, that would have required a total
> rewrite of libfb, but maybe it's easier now with pixman.  If not, it might
> be worth doing the work anyway.

There is still substantial parts of fb that are not yet in pixman, so
rewriting may still be required. On the other hand, just adding
upload/download hooks to pixman might get a lot of the operations that
actually happen in practice.



Soren