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