Hi Thomas,

Dave find out the root of a strange oops we did encouter.
I spend sometimes today trying to hack ttm around but
in the end my solution is wrong.

So when we move an object a ttm ghost object is created.
If GPU takes time to evict the bo the ghost object endup
on the destroy list & stay on the lru list (unless i have
missunderstood the code the whole day). No if ghost is
in GTT (similar issue can happen in different configuration,
bottom line is evicting a ghost object) it can get evicted
and that's when trouble start. The driver callback get
call with the ghost object but ghost object haven't been
created by the driver and thus driver will more than
likely endup oupsing trying to access its private bo
structure (ttm_bo structure is embeded in radeon_bo
structure and any driver relying on accessing the
driver structure will hit this issue).

I see 2 solutions :
  - Don't put ghost on lru list
  - Add a flag so we know if we can call driver
    callback on object or not.

I will send the first solution patch but i haven't yet
found an easy way to exercise this path. My concern is
that when in ttm_bo_mem_force_space we might fail because
we don't wait for the ghost object to actualy die and
free space (issue only if no_wait=false).

Also i wonder if letting a ghost bo object on lru might
not lead to infinite eviction loop. Case i am thinking
of :
  - VRAM is full only 1 object we can evict, we evict
    it and create a ghost object holding the vram space
    the eviction is long enough that we put the ghost
    on lru. ttm_bo_mem_force_space evict the ghost_object
    and we loop on this.

Anyway, what is your thought on this.

Cheers,
Jerome













on the lru and just let it stay on the destroy list,
but that doesn't endup that well.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to