[PATCH v4 1/3] drm/shmem-helper: Import dmabuf without mapping its sg_table
Christian König
christian.koenig at amd.com
Fri May 9 11:13:37 UTC 2025
On 5/9/25 08:51, Thomas Zimmermann wrote:
>>> +struct drm_gem_object *drm_gem_shmem_prime_import_no_sgt(struct drm_device *dev,
>>> + struct dma_buf *dma_buf)
>>
>> Please don't mention "no sgt" in the name, that we use sgtable is an implementation detail.
>>
>> Maybe use something like "no map" or similar.
>
> To be fair, I asked to not named it something like _vmap(), but rather _no_sgt(). These vmap-only names purely describe a use case. I'd be OK with any name that refers to the difference between the various functions; not just their effect.
Yeah, but "no sgt" is as equally bad as vmap. I don't know a good naming of hand either.
>
> Unrelated to this series, we might reconsider drm_driver.gem_prime_import_sg_table. If we move the call to dma_buf_map_attachment_unlocked() into the callback and rename it to gem_prime_import_attachment, using sg tables would become optional for all drivers. SHMEM would be able to create the object without SG table without having to reimplement the prime boiler-plate code. Thoughts?
I'm not sure if that would actually be better, but calling dma_buf_map_attachment() should indeed only be done when necessary.
For amdgpu we put that into the TTM TT backend (see function amdgpu_ttm_backend_bind) and I considered switching over radeon and nouveau as well but then just abandoned the plan as to much work.
Regards,
Christian.
More information about the dri-devel
mailing list