Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.

[Michel D. <mi...@da...>]

On Don, 2010-03-25 at 19:56 +1000, Dave Airlie wrote: 
> 2010/3/25 Michel Dänzer <mi...@da...>:
> > On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote:
> >> From: Dave Airlie <ai...@re...>
> >>
> >> 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 <ai...@re...>
> >
> > 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