On Fri, 2010-03-26 at 19:56 +0000, Matthew Garrett wrote: > > As far as the lockups go, I think this is due to memory access during > reclock. Nothing should be coming from the cp, but we may be getting > accesses from the crtc if we miss vblank (there's a bit in the crtc > control that can deal with this), but more importantly we're doing > nothing to prevent unaccelerated fallbacks touching vram during reclock. > I can provoke lockups more easily using x11perf which probably triggers > several of those, so I lean towards that being something we need to fix > before looking for other potential issues.
Have you tried making RADEONPrepareAccess_CS() in the X driver always return FALSE (you may also need to prevent RADEONUploadToScreenCS() from returning FALSE if the BO isn't busy) to confirm this? That should prevent any direct CPU access to VRAM, at least as long as you don't hit any software fallbacks in the 3D driver. -- 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
