All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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: link
Be 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.