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

[Dave Airlie]

2010/4/26 Michel Dänzer <michel at daenzer.net>:
> On Son, 2010-04-25 at 20:31 +1000, Dave Airlie wrote:
>> 2010/4/25 Michel Dänzer <michel at daenzer.net>:
>> > On Son, 2010-04-25 at 11:35 +0200, Uwe Bugla wrote:
>> >> Am Samstag, den 24.04.2010, 12:31 -0400 schrieb Alex Deucher:
>> >> > On Sat, Apr 24, 2010 at 11:48 AM, Chicken Shack <chicken.shack at gmx.de> wrote:
>> >> > >
>> >> > > 1. The real issue of that Compiz problem IS NOT what dmesg says.
>> >> > >
>> >> > > The real issue of my problem is that the FIRST patch Dave Airlie
>> >> > > attached for resolving this Compiz issue NEVER reached kernel mainline
>> >> > > while the second one did obviously.
>> >> > >
>> >> > > So PLEASE do push up Dave's FIRST patch titled "fallback on VRAM memory
>> >> > > placement" as fast as possible so that it becomes part of the kernel
>> >> > > mainline!
>> >> >
>> >> > The first patch caused problems on some AGP systems due to the
>> >> > unreliability of AGP so it wasn't pushed to mainline.  It should be
>> >> > safe to push once this patch hits mainline:
>> >> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=61cf059325a30995a78c5001db2ed2a8ab1d4c36
>> >
>> > No, there were more issues with the patch[0] and it can't be pushed
>> > again as is. A different approach will be needed to make things work
>> > better on VRAM-limited systems.
>> >
>> >
>> > [0] At least making pinning of BOs to VRAM unreliable, potentially
>> > causing problems with BOs used by the display hardware (e.g. trying to
>> > start a second X server when VRAM is full of BOs), and degrading
>> > performance on systems where things work without the patch.
>>
>> Yeah I'm going to try and fix that up this week now we fixed the AGP.
>>
>> 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, 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.

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.

The thing is with the busy placement in theory it should be the
fallback, and we shouldn't need two schemes, or maybe it works
different than it obviously should.

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