On Don, 2010-03-25 at 19:56 +1000, Dave Airlie wrote: > 2010/3/25 Michel Dänzer <mic...@daenzer.net>: > > On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote: > >> From: Dave Airlie <airl...@redhat.com> > >> > >> On constrained r100 systems compiz would fail to start due to a lack > >> of memory, we can just fallback place the objects rather than completely > >> failing it works a lot better. > >> > >> Signed-off-by: Dave Airlie <airl...@redhat.com> > > > > This change seems to trigger or at least greatly expedite GPU lockups on > > my PowerBook. With the change applied, my normal X session locked up the > > GPU after just a few minutes several times. Now with it reverted it's > > back to the previous stability. > > Care to try in pci mode? see if helps, it might be just straining AGP > a bit more,
Ugh, k I'll try... but that incurs such a huge performance hit that the result might not be very meaningful I'm afraid. > maybe try 1x as well if you aren't already in it. I am, for some reason neither 2x nor 4x has ever worked reliably with KMS although 4x was rock solid with UMS. > > I don't know why that is - maybe something doesn't properly deal with > > BOs getting placed differently in some cases now - but anyway I suspect > > the implications of this change haven't been fully thought through: The > > log message sounds as though the change was mainly written with > > radeon_bo_create() / radeon_bo_list_validate() in mind, but > > radeon_ttm_placement_from_domain() is also called from other places: > > > > * radeon_bo_pin(): The change could lead to a BO being pinned to > > GTT instead of VRAM, which would probably be bad. > > * radeon_evict_flags(): The change might have undesirable > > consequences here as well, not sure. > > The first might be bad, but the second should be okay, I'll take a closer look > in the morning. What about that there are now usually no busy placements specified, couldn't that be a problem? > > I don't think the way we currently use the same arrays for normal and > > busy placement makes a lot of sense, but we probably need a better > > mechanism to specify which placements are desirable / acceptable in each > > case. > > Well its not really a huge matrix of choices, I'm guessing we need more > info from userspace, or use the info better. Though in theory everything > should work in GTT or VRAM equally well just slower. E.g. scanout from GTT could easily exceed the available bandwidth. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
