(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_USERPTRI 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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
