From: Thomas Zimmermann <tzimmermann@suse.de> To: "Jacek Lawrynowicz" <jacek.lawrynowicz@linux.intel.com>, dri-devel@lists.freedesktop.org, airlied@gmail.com, daniel@ffwll.ch, "thellstrom@vmware.com" <thellstrom@vmware.com>, "Christian König" <christian.koenig@amd.com> Cc: andrzej.kacprowski@linux.intel.com, Intel Graphics Development <intel-gfx@lists.freedesktop.org>, stanislaw.gruszka@linux.intel.com Subject: Re: [PATCH v3 3/7] drm/ivpu: Add GEM buffer object management Date: Wed, 26 Oct 2022 14:06:52 +0200 [thread overview] Message-ID: <630fde93-a95d-3b05-30eb-6e0a1a38895e@suse.de> (raw) In-Reply-To: <9a7d0dc3-67ce-e947-81c0-78c7ae40ded1@linux.intel.com> [-- Attachment #1.1: Type: text/plain, Size: 2045 bytes --] (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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de> To: "Jacek Lawrynowicz" <jacek.lawrynowicz@linux.intel.com>, dri-devel@lists.freedesktop.org, airlied@gmail.com, daniel@ffwll.ch, "thellstrom@vmware.com" <thellstrom@vmware.com>, "Christian König" <christian.koenig@amd.com> Cc: andrzej.kacprowski@linux.intel.com, Intel Graphics Development <intel-gfx@lists.freedesktop.org>, stanislaw.gruszka@linux.intel.com Subject: Re: [Intel-gfx] [PATCH v3 3/7] drm/ivpu: Add GEM buffer object management Date: Wed, 26 Oct 2022 14:06:52 +0200 [thread overview] Message-ID: <630fde93-a95d-3b05-30eb-6e0a1a38895e@suse.de> (raw) In-Reply-To: <9a7d0dc3-67ce-e947-81c0-78c7ae40ded1@linux.intel.com> [-- Attachment #1.1: Type: text/plain, Size: 2045 bytes --] (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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-10-26 12:07 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-24 15:11 [PATCH v3 RESEND 0/7] New DRM driver for Intel VPU Jacek Lawrynowicz 2022-09-24 15:11 ` [PATCH v3 1/7] drm/ivpu: Introduce a new " Jacek Lawrynowicz 2022-10-24 23:00 ` Jeffrey Hugo 2022-10-25 11:42 ` Jacek Lawrynowicz 2022-10-25 11:57 ` Thomas Zimmermann 2022-10-26 12:07 ` Jacek Lawrynowicz 2022-10-26 12:21 ` Thomas Zimmermann 2022-10-25 14:08 ` Jeffrey Hugo 2022-10-26 12:21 ` Jacek Lawrynowicz 2022-10-25 12:38 ` Thomas Zimmermann 2022-10-28 16:00 ` Jacek Lawrynowicz 2022-09-24 15:11 ` [PATCH v3 2/7] drm/ivpu: Add Intel VPU MMU support Jacek Lawrynowicz 2022-10-26 0:12 ` Jeffrey Hugo 2022-10-27 9:14 ` Jacek Lawrynowicz 2022-10-27 17:44 ` Jeffrey Hugo 2022-11-17 14:00 ` Jacek Lawrynowicz 2022-11-01 8:56 ` Thomas Zimmermann 2022-11-18 10:18 ` Jacek Lawrynowicz 2022-11-01 9:00 ` Thomas Zimmermann 2022-11-18 10:15 ` Jacek Lawrynowicz 2022-09-24 15:11 ` [PATCH v3 3/7] drm/ivpu: Add GEM buffer object management Jacek Lawrynowicz 2022-10-25 12:41 ` Thomas Zimmermann 2022-10-26 11:26 ` Jacek Lawrynowicz 2022-10-26 12:06 ` Thomas Zimmermann [this message] 2022-10-26 12:06 ` [Intel-gfx] " Thomas Zimmermann 2022-09-24 15:11 ` [PATCH v3 4/7] drm/ivpu: Add IPC driver and JSM messages Jacek Lawrynowicz 2022-11-01 10:02 ` Thomas Zimmermann 2022-12-07 9:47 ` Jacek Lawrynowicz 2022-09-24 15:11 ` [PATCH v3 5/7] drm/ivpu: Implement firmware parsing and booting Jacek Lawrynowicz 2022-11-01 10:08 ` Thomas Zimmermann 2022-11-14 8:21 ` Jacek Lawrynowicz 2022-09-24 15:11 ` [PATCH v3 6/7] drm/ivpu: Add command buffer submission logic Jacek Lawrynowicz 2022-09-24 15:11 ` [PATCH v3 7/7] drm/ivpu: Add PM support Jacek Lawrynowicz 2022-11-01 8:58 ` [PATCH v3 RESEND 0/7] New DRM driver for Intel VPU Thomas Zimmermann 2022-11-01 10:17 ` Thomas Zimmermann 2022-12-07 9:50 ` Jacek Lawrynowicz -- strict thread matches above, loose matches on Subject: below -- 2022-09-22 10:02 [PATCH v3 " Jacek Lawrynowicz 2022-09-22 10:02 ` [PATCH v3 3/7] drm/ivpu: Add GEM buffer object management Jacek Lawrynowicz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=630fde93-a95d-3b05-30eb-6e0a1a38895e@suse.de \ --to=tzimmermann@suse.de \ --cc=airlied@gmail.com \ --cc=andrzej.kacprowski@linux.intel.com \ --cc=christian.koenig@amd.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jacek.lawrynowicz@linux.intel.com \ --cc=stanislaw.gruszka@linux.intel.com \ --cc=thellstrom@vmware.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.