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

[Dave Airlie]

2010/4/27 Dave Airlie <airlied at gmail.com>:
> 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.

I've posted the rework to dri-devel just so we know what it looks like.

Dave.