Jerome Glisse wrote: > On Fri, 2009-04-10 at 10:14 +0200, Thomas Hellström wrote: > >> Jerome Glisse wrote: >> >>> On Wed, 2009-04-08 at 16:47 +0200, Thomas Hellstrom wrote: >>> >>> >>>> Jerome Glisse wrote: >>>> >>>> >>>>> Hi Thomas, >>>>> >>>>> I think we should not ttm_bo_unreserve the bo in >>>>> ttm_bo_move_accel_cleanup i am seeing double unreserve >>>>> which likely lead to kernel list corruption and i >>>>> think it's due to that one (i am checking through >>>>> printk but the log is enormous and my script is not >>>>> yet done with parsing it) >>>>> >>>>> I checked code path in via using ttm_bo_move_accel_cleanup >>>>> and none seems to reserve the buffer before calling >>>>> ttm_bo_move_accel_cleanup. >>>>> >>>>> >>>>> >>>>> >>>> Jerome, >>>> >>>> All buffers that are touched by the move code need to be reserved. >>>> What happens in the above case is that the buffer is copied in its >>>> reserved state, >>>> and thus there will be an unreserve for each copy. >>>> >>>> Please make sure, however, that you got all of the >>>> buffer_object_transfer fixes from the newttm branch, >>>> in particular the one where we clear the fbo->swap list head. >>>> >>>> /Thomas >>>> >>>> >>> There is a bug in cleanup: >>> if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED)) >>> ghost_obj->ttm = NULL; >>> else >>> ghost_obj = NULL; >>> Used to be >>> if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED)) >>> ghost_obj->ttm = NULL; >>> else >>> bo->ttm = NULL; >>> >>> And i think it's the correct one. Note that current one lead >>> to oups because then you unreserve a NULL ptr. >>> >>> >>> >> Jerome, >> You're right. Does that fix your list corruption? >> >> /Thomas >> > > Hi, Jerome. > I have no more list corruption but my tree have few other fixes > it would be nice if you could check if my not missunderstanding > vm code (patch attached). > >
I'll try to have a lock early next week. > Also i was reviewing the bo move code and i think we should only > call ttm_tt_bind if mem_type is TTM_TT, right now you call bind > if mem_type != SYSTEM, so far i never saw somethings else than > TTM_TT being bind but better be safe than sorry. > Strictly, all mem types except those with TTM_MEMTYPE_FLAG_FIXED are assumed to be dynamic, not only TTM_PL_TT, so the code you're referring to is only called if it's a dynamic memory type, and then we need to bind if it's not SYSTEM placement, so it should be correct. A usage example would be a system with a distinct memory type for a particular aperture range. (Poulsbo for example). > A related question is what does ttm do when moving a bo from > vram to system ? My understanding is that it creates a tt object > and bind it but can the driver move callback ever get > old_memtype = VRAM & new_memtype=SYSTEM ? > Yes. TTM should hit the driver move hook, and if there is non fall back to move_memcpy. Openchrome uses its PCI DMA engines to move from VRAM in this way (via_move_dmablit()). However, Openchrome is probably different than the Radeon's in this respect since the PCI DMA engines are not programmed using the 3D fifo, so DRM has to synchronize the engines using fences. We're currently not using these engines for moves from SYSTEM to VRAM since it's limited to about 133MB/s and also completely saturates the PCI bus, (even if the processor is off-loaded). > Btw i try to isolate all my ttm stuff in my drm-next-ttm branch > on fdo: > http://cgit.freedesktop.org/~glisse/drm-next/ > > > Cheers, > Jerome > Thanks, Thomas ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
