From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Krystian Pradzynski <krystian.pradzynski@linux.intel.com>,
Jeffrey Hugo <quic_jhugo@quicinc.com>,
dri-devel@lists.freedesktop.org,
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
tzimmermann@suse.de, andrzej.kacprowski@linux.intel.com
Subject: Re: [PATCH v4 1/7] accel/ivpu: Introduce a new DRM driver for Intel VPU
Date: Fri, 6 Jan 2023 13:43:25 +0100 [thread overview]
Message-ID: <20230106124325.GC1586324@linux.intel.com> (raw)
In-Reply-To: <CAKMK7uEu=aKCVgNfzqVE-NKX9O6HyNmYKORuHcK4Y=j=kmRDMw@mail.gmail.com>
On Fri, Jan 06, 2023 at 11:44:58AM +0100, Daniel Vetter wrote:
> > > The problem is going to happen as soon as you have cross-vendor userspace.
> > > Which I'm kinda hoping is at least still the aspiration. Because with
> > > cross-vendor userspace you generally iterate & open all devices before you
> > > select the one you're going to use. And so we do kinda need a distinction,
> > > or we need that the single-user drivers also guarantee that open() is
> > > cheap.
> >
> > FWIW we had good support in ivpu for probe open's in form of lazy context
> > allocation. It was removed recently due to review feedback that this is
> > unnecessary, but we can add it back.
>
> Yeah once you have more than 1 multi-user accel chip in the system you
> need to do that. Which is really the reason why I think smashing
> multi-user client accel things into render is good, it forces drivers
> to suck less.
>
> On that topic, does your userspace still do the drmIoctl() wrapper?
Yes, it still does. We released the code BTW, the wrapper can be seen here:
https://github.com/intel/linux-vpu-driver/blob/b6ed73cabf87f461cbbe4427e1b9351a548d790b/umd/vpu_driver/source/os_interface/vpu_driver_api.cpp#L41
Regards
Stanislaw
next prev parent reply other threads:[~2023-01-06 12:43 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 [this message]
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
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=20230106124325.GC1586324@linux.intel.com \
--to=stanislaw.gruszka@linux.intel.com \
--cc=andrzej.kacprowski@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacek.lawrynowicz@linux.intel.com \
--cc=krystian.pradzynski@linux.intel.com \
--cc=quic_jhugo@quicinc.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