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.
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.
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.
--
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
