EXA and migration [was: shrink xrender featureset]

[Dave Airlie]

On Wed, Nov 26, 2008 at 5:38 AM, Clemens Eisserer <linuxhippy at gmail.com> wrote:
>> That's not 'strong vocabulary' but simply baseless flamebait.
>
> Would it make sence to implement some fallback-optimizations like:
> - Copy pictures without drawables (gradients) to a temporary surface,
> if the driver supports composition?
> - Support solid write-only operations (X11 core drawing) for which EXA
> does not provide hooks (e.g. diagonal lines) through a temporal mask,
> if the driver supports composition?
>
> For both cases I saw ping-pong migration killing performance, and I
> had to implement work-arrounds in my application myself which are
> built on assumptions about the accaleration architecture's behaviour
> and sometimes cause degraded performance.
>
> By the way thanks a lot for the EXA improvements in 1.5/1.6 :)

Yeah I'm with this, EXA really needs optimisations that know you have composite,
and just to render the stuff with the CPU and composite it on. Generally it does
stupid things like fill on the GPU, then render with CPU then composite.

When you have kernel managed pixmaps and they are uncached CPU side
for the GPU to use them
EXA isn't currently the acceleration architecture you are looking for.
I'm starting to think a bit more
about the requirements on the XA for sw fallbacks in this case.

another things that would be nice, would be instead of the current
prepare/op/op/op/done, we could
possibly tell prepare how many ops are coming so it can more
efficiently batch things.

Dave.