(cc: Thomas, Christian, intel-gfx)
Hi

Am 26.10.22 um 13:26 schrieb Jacek Lawrynowicz:
> Hi,
> 
> On 10/25/2022 2:41 PM, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz:
>>> Adds four types of GEM-based BOs for the VPU:
>>>     - shmem
>>>     - userptr
>>>     - internal
>>>     - prime
>>>
>>> All types are implemented as struct ivpu_bo, based on
>>> struct drm_gem_object. VPU address is allocated when buffer is created
>>> except for imported prime buffers that allocate it in BO_INFO IOCTL due
>>> to missing file_priv arg in gem_prime_import callback.
>>> Internal buffers are pinned on creation, the rest of buffers types
>>> can be pinned on demand (in SUBMIT IOCTL).
>>> Buffer VPU address, allocated pages and mappings are relased when the
>>> buffer is destroyed.
>>> Eviction mechism is planned for future versions.
>>>
>>> Add three new IOCTLs: BO_CREATE, BO_INFO, BO_USERPTR
>>
>> I feels like TTM already does all you need. (?) Why not build upon TTM?
> 
> Would TTM make sense for a device without dedicated memory?

It is at least possible. i915 has TTM code for discrete devices and 
maybe uses some of it for integrated chips a well.  I've cc'ed a number 
of people with expertise.

> It looks like struct drm_gem_shmem_object could be a better fit for us but it doesn't support userptr or internal buffers.

I don't find drm_gem_shmem_object in your current patch. (?) GEM SHMEM 
is a simple allocator for simple devices. It's best to keep it this way.
Stuff like eviction and userptr sounds like it's not for the shmem helpers.

The next best thing would be to write your own GEM allocator, which you 
did AFAICT. And that's absolutely ok. But TTM at least seems like a 
plausible framework.

Best regards
Thomas

> 
> Regards,
> Jacek

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev