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, maybe try 1x as well if you aren't already in it. > > 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. > 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. Dave. ------------------------------------------------------------------------------ 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
