EXA EnableDisableFBAccess paths.

[Michel Dänzer]

On Thu, 2009-04-16 at 10:21 +0200, Michel Dänzer wrote:
> On Thu, 2009-04-16 at 11:03 +1000, Dave Airlie wrote:
> > I think we have a problem with the EnableDisableFBAccess paths,
> > but I'm not 100% sure how to fix it. However I don't believe the
> > swapped out flag should be hit for driver pixmaps at all.
> > 
> > The problem is on VT enter, the wrapped EDFBA function, does an 
> > if (set_disable) disable, call wrap, if (set_enabled) enable, however inside
> > the call wrap we get an exposure generation and we end up doing a bunch
> > of pointless sw rendering when clearly we could avoid it.
> > 
> > But I'm not sure what the logic behind the wrap calling sequence.
> 
> The logic you're referring to isn't in exaEnableDisableFBAccess(), is
> it?

I thought you were referring to something outside of EXA, but maybe you
mean exaXorgEnableDisableFBAccess()? Maybe it would be better in general
to switch the !enable and enable cases around the wrapped call?

> > I've attached a patch that avoids hitting swapped out flag for driver pixmaps
> > and this makes fast user switch on radeon/kms actually fast.
> 
> Makes sense, the swappedOut flag really only applies to the EXA
> offscreen allocator.

Another possibility might be not to hook up to DisableFBAccess in the
first place in this case.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer