ATI Radeon R100 QD (7200) refuses to work with Compiz (Kernel 2.6.34-rc4)

[Michel Dänzer]

On Die, 2010-04-27 at 08:19 +1000, Dave Airlie wrote: 
> 2010/4/26 Michel Dänzer <michel at daenzer.net>:
> > On Son, 2010-04-25 at 20:31 +1000, Dave Airlie wrote:
> >>
> >> I'm just going to separate the pinning code from the validate code wrt
> >> domain->placement translation.
> >
> > That's a start, but IME validation using the new scheme degrades
> > performance on setups which work with the old scheme. Maybe the old
> > scheme can be tried first and the new one as a fallback, at least as an
> > interim solution. But I think the new scheme really shouldn't be
> > necessary if we didn't over-report the amount of VRAM available to
> > userspace and prevented fragmentation due to pinned BOs, which should be
> > feasible.
> 
> I can't see why it would degrade anything,

Not 100% sure but most likely because it disables the only mechanism we
have to move BOs back into VRAM after having been evicted.

Try running a session with compiz or so and slightly more BOs in total
than can fit in VRAM.

> currently it fails to work, I can't see us making fails to work into
> something worse. If you think its working I can generate a non-working
> workload quite trivally, its just luck it works at present.

*I* am perfectly aware of the problem *you* are trying to fix, but I
don't agree it justifies or requires any impact on working setups to
solve.


> The problem is its easy to say the words "prevent fragmentation due to
> pinned BOs" its a lot messier to actually implement,
> Look at fast user switch or front resize, in all cases we require both
> the old pin and the new pin in VRAM at the same time, in order to make
> a smooth transistion, we can't pin both of them at the sweet spots, so
> one will always end up in the bad place. Now X makes this worse since
> with an external monitor for some reason we create a front bo for a
> cloned output and it gets resized later, so we always end up with a bo
> pinned in the wrong place when a VGA monitor is plugged in. The option
> of moving the BO in vblank might be possible, but it it happens more
> than once it'll get really messy, and again fast user switch is going
> to be a pain no matter what.

Doing it in vblank shouldn't even be necessary as long as an overlap of
the old and new BO location can be prevented.

Anyway, I realize this will be non-trivial, which is why I suggested an
interim solution.


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