Re: locking&resource refcounting for ttm_bo_kmap/dma_buf_vmap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 21, 2019 at 8:59 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
>
> Hi
>
> Am 20.11.19 um 12:47 schrieb Daniel Vetter:
> > Hi all,
> >
> > I've been looking at dma_buf_v(un)map, with a goal to standardize
> > locking for at least dynamic dma-buf exporters/importers, most likely
> > by requiring dma_resv_lock. And I got questions around how this is
> > supposed to work, since a big chunk of drivers seem to entirely lack
> > locking around ttm_bo_kmap. Two big ones:
> >
> > - ttm_bo_kmap looks at bo->mem to figure out what/where to kmap to get
> > at that buffer. bo->mem is supposed to be protected with
> > dma_resv_lock, but at least amgpu/nouveau/radeon/qxl don't grab that
> > in their prime vmap function.
> >
> > - between the vmap and vunmap something needs to make sure the backing
> > storage doesn't move around. I didn't find that either anywhere,
> > ttm_bo_kmap simply seems to set up the mapping, leaving locking and
> > refcounting to callers.
>
> You have to pin and unpin storage before and after mapping.

Yeah, but you = the exporter, not the importer. I.e. the vmap callback
should pin and vunmap should unpin. It's not a huge deal since
currently all users of dma_buf_vmap I've found do a dma_buf_attach
(even if they never use the attachment directly), and with drm prime
helpers the attach results in a pin. Or that's at least the story I
told myself to believe this is all not a totally fireworks show right
now :-)

> > - vram helpers have at least locking, but I'm still missing the
> > refcounting. vmwgfx doesn't bother with vmap.
>
> There's a ref counter for pinning [1] and there's a counter for mapping.
> [2] Are you looking for something else?

vram helpers actually looked pretty good in this regard. If you look
at other callers of ttm_bo_kmap, they're a lot more fast&loose here.
-Daniel

>
> Best regards
> Thomas
>
> [1]
> https://cgit.freedesktop.org/drm/drm-tip/tree/include/drm/drm_gem_vram_helper.h?id=8d3996ceedcd5c64f5a354e9dcc64db4a1f72dd6#n69
> [2]
> https://cgit.freedesktop.org/drm/drm-tip/tree/include/drm/drm_gem_vram_helper.h?id=8d3996ceedcd5c64f5a354e9dcc64db4a1f72dd6#n63
>
> >
> > What am I missing?
> >
> > Thanks, Daniel
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux