From: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, Oded Gabbay <oded.gabbay@gmail.com>
Cc: andrzej.kacprowski@linux.intel.com, quic_jhugo@quicinc.com,
tzimmermann@suse.de, dri-devel@lists.freedesktop.org,
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Subject: Re: [PATCH v4 3/7] accel/ivpu: Add GEM buffer object management
Date: Mon, 9 Jan 2023 13:06:18 +0100 [thread overview]
Message-ID: <7b29f0b7-9a16-2460-3096-46b7ae977eed@linux.intel.com> (raw)
In-Reply-To: <CAKMK7uG8Qudy2Cf5zZ5CLwQd1+J5M3MyiNhKGuNrGbZNz4Bs4A@mail.gmail.com>
Hi,
On 06.01.2023 19:25, Daniel Vetter wrote:
> On Fri, 6 Jan 2023 at 14:23, Stanislaw Gruszka
> <stanislaw.gruszka@linux.intel.com> wrote:
>>
>> On Fri, Jan 06, 2023 at 11:50:05AM +0100, Daniel Vetter wrote:
>>> On Thu, Dec 08, 2022 at 12:07:29PM +0100, Jacek Lawrynowicz wrote:
>>>> Adds four types of GEM-based BOs for the VPU:
>>>> - shmem
>>>> - userptr
>>>> - internal
>>>
>>> Uh what do you need this for? Usually the way we do these is just alloce a
>>> normal bo, and then pin them.
>>
>> I think we do alloc/pin this way, but all our bo's are GEM based.
>> For those bo's we use internally and other non-shmem we create them
>> with drm_gem_private_object_init(). I think this way is simpler than
>> have separate code for non-GEM and GEM bo's ...
>
> They should be all gem bo, I guess you mean shmem vs non-shmem? And
> the allocate+pin is the standard approach for drivers that have
> somewhat dynamic bo (i.e. not using dma_alloc) and need some of them
> (hopefully only for driver internal objects, not for userspace) pinned
> in place. So you handrolling a perma-pinned gem bo for internal
> objects is rather strange by drm driver standards.
>
>>> Also, gem shmem helpers should be able to mostly cover you here, why not
>>> use those? Might need some work to push basic userptr to them, but we have
>>> enough drivers reinventing that wheel to justify that work.
>>>
>>> Can I guess also be done after merging.
>>
>> ... but if not, we can add this to TODO.
>
> Yeah I'm fine with todo to cut these over to shmem helpers, this
> driver has been stuck in limbo for way too long anyway.
Yeah, I think it would be easier for everyone if this driver was merged.
Especially for me :)
I feel like I'm shifting tons of coal every time I need to update it.
But also from the reviewer perspective it would be easier to track changes
between driver revisions if only delta was posted instead of the whole 8K lines of code.
Guys, please make my day and merge it to 6.3.
Regards,
Jacek
next prev parent reply other threads:[~2023-01-09 12:06 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 11:07 [PATCH v4 0/7] New DRM accel driver for Intel VPU Jacek Lawrynowicz
2022-12-08 11:07 ` [PATCH v4 1/7] accel/ivpu: Introduce a new DRM " Jacek Lawrynowicz
2022-12-14 13:57 ` Oded Gabbay
2022-12-14 15:07 ` Jeffrey Hugo
2022-12-14 18:21 ` Oded Gabbay
2022-12-14 15:39 ` Stanislaw Gruszka
2022-12-20 20:17 ` Oded Gabbay
2022-12-21 8:25 ` Jacek Lawrynowicz
2023-01-05 12:57 ` Daniel Vetter
2023-01-05 16:25 ` Jeffrey Hugo
2023-01-05 17:38 ` Oded Gabbay
2023-01-06 9:28 ` Daniel Vetter
2023-01-06 9:56 ` Stanislaw Gruszka
2023-01-06 10:44 ` Daniel Vetter
2023-01-06 11:43 ` Oded Gabbay
2023-01-11 4:35 ` Dave Airlie
2023-01-06 12:43 ` Stanislaw Gruszka
2022-12-08 11:07 ` [PATCH v4 2/7] accel/ivpu: Add Intel VPU MMU support Jacek Lawrynowicz
2022-12-12 11:19 ` kernel test robot
2022-12-18 9:13 ` Oded Gabbay
2022-12-19 13:17 ` Jacek Lawrynowicz
2022-12-08 11:07 ` [PATCH v4 3/7] accel/ivpu: Add GEM buffer object management Jacek Lawrynowicz
2022-12-12 15:31 ` kernel test robot
2022-12-18 10:23 ` Oded Gabbay
2022-12-19 8:08 ` Jacek Lawrynowicz
2023-01-05 18:46 ` Andrew Davis
2023-01-06 13:29 ` Stanislaw Gruszka
2023-01-09 11:47 ` Jacek Lawrynowicz
2023-01-09 18:09 ` Andrew Davis
2023-01-06 10:50 ` Daniel Vetter
2023-01-06 13:22 ` Stanislaw Gruszka
2023-01-06 18:25 ` Daniel Vetter
2023-01-09 12:06 ` Jacek Lawrynowicz [this message]
2022-12-08 11:07 ` [PATCH v4 4/7] accel/ivpu: Add IPC driver and JSM messages Jacek Lawrynowicz
2022-12-27 15:34 ` Oded Gabbay
2023-01-03 10:54 ` Jacek Lawrynowicz
2022-12-08 11:07 ` [PATCH v4 5/7] accel/ivpu: Implement firmware parsing and booting Jacek Lawrynowicz
2022-12-08 11:07 ` [PATCH v4 6/7] accel/ivpu: Add command buffer submission logic Jacek Lawrynowicz
2022-12-08 11:07 ` [PATCH v4 7/7] accel/ivpu: Add PM support Jacek Lawrynowicz
2022-12-13 11:36 ` [PATCH v4 8/7] accel/ivpu: Add depend on !UML to Kconfig Stanislaw Gruszka
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=7b29f0b7-9a16-2460-3096-46b7ae977eed@linux.intel.com \
--to=jacek.lawrynowicz@linux.intel.com \
--cc=andrzej.kacprowski@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=oded.gabbay@gmail.com \
--cc=quic_jhugo@quicinc.com \
--cc=stanislaw.gruszka@linux.intel.com \
--cc=tzimmermann@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox