2010/4/27 Dave Airlie <[email protected]>: > 2010/4/26 Michel Dänzer <[email protected]>: >> On Son, 2010-04-25 at 20:31 +1000, Dave Airlie wrote: >>> 2010/4/25 Michel Dänzer <[email protected]>: >>> > 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 <[email protected]> >>> >> > 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. _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
