Re: [PATCH v1 0/7] New DRM driver for Intel VPU

From: Dave Airlie <airlied@gmail.com>
To: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
	 "Koenig, Christian" <Christian.Koenig@amd.com>,
	 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dave Airlie <airlied@linux.ie>,
	andrzej.kacprowski@linux.intel.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	stanislaw.gruszka@linux.intel.com
Subject: Re: [PATCH v1 0/7] New DRM driver for Intel VPU
Date: Mon, 8 Aug 2022 12:34:59 +1000	[thread overview]
Message-ID: <CAPM=9tyqsK3X_+s53Xy5jUs+cq3+aSkYne-E4NLLJ+NBnRqjNg@mail.gmail.com> (raw)
In-Reply-To: <20220728131709.1087188-1-jacek.lawrynowicz@linux.intel.com>

On Thu, 28 Jul 2022 at 23:17, Jacek Lawrynowicz
<jacek.lawrynowicz@linux.intel.com> wrote:
>
> Hi,
>
> This patchset contains a new Linux* Kernel Driver for Intel® VPUs.
>
> VPU stands for Versatile Processing Unit and it is an AI inference accelerator
> integrated with Intel non-server CPUs starting from 14th generation.
> VPU enables efficient execution of Deep Learning applications
> like object detection, classification etc.
>
> Driver is part of gpu/drm subsystem because VPU is similar in operation to
> an integrated GPU. Reusing drm driver init, ioctl handling, gem and prime
> helpers and drm_mm allows to minimize code duplication in the kernel.
>
> The whole driver is licensed under GPL-2.0-only except for two headers imported
> from the firmware that are MIT licensed.
>
> User mode driver stack consists of Level Zero API driver and OpenVINO plugin.
> Both should be open-sourced by the end of Q3.
> The firmware for the VPU will be distributed as a closed source binary.

Thanks for the submission, this looks pretty good and well layed out,

just a few higher level things, I think I'd like this name intel-vpu
or ivpu or something, VPU is a pretty generic namespace usage.

I think adding some sort of TODO file with what is missing and what
future things need to happen would be useful to know when merging this
might be a good idea.

I'm kinda thinking with a rename we could merge this sooner into a
staging-lite model.

I think I'd like Christian/Maarten to maybe review the fencing/uapi,
to make sure nothing too much is wrong there. The submit/waitbo model
is getting a bit old, and using syncobjs might be useful to make it
more modern. Is this device meant to be used by multiple users at
once? Maybe we'd want scheduler integration for it as well (which I
think I saw mentioned somewhere in passing).

Dave.