Re: [PATCH v4 1/3] drm/shmem-helper: Import dmabuf without mapping its sg_table

["Christian König" <christian.koenig@amd.com>]

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.