On Thu, 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, maybe try 1x as well if you aren't already in it.
After various more tests, the gist of it seems to be that rendering to GTT with the 3D engine tends to lock up whereas the 2D and DMA engines work fine (otherwise I probably would have run into this a long time ago at BO eviction time). Maybe some kind of synchronization issue resulting in the 3D engine trying to access GTT memory which isn't bound yet / anymore? > > 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, [...] I actually saw this happen once for the scanout BO of a second X server, and it resulted in pretty spectacular cascaded failure. This confirmed my suspicion that it's a very bad idea for radeon_bo_pin(). In summary I'm afraid this isn't really a good solution for what you were trying to achieve, and it's actually breaking things that were working before, so I think it should be reverted. -- 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
