From: Jeffrey Hugo <quic_jhugo@quicinc.com>
To: Oded Gabbay <ogabbay@kernel.org>
Cc: David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Arnd Bergmann <arnd@arndb.de>, <linux-kernel@vger.kernel.org>,
<dri-devel@lists.freedesktop.org>,
Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
Jiho Chu <jiho.chu@samsung.com>,
Daniel Stone <daniel@fooishbar.org>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Christoph Hellwig <hch@infradead.org>,
Kevin Hilman <khilman@baylibre.com>,
Jagan Teki <jagan@amarulasolutions.com>,
John Hubbard <jhubbard@nvidia.com>,
Alex Deucher <alexander.deucher@amd.com>,
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>,
Christopher Friedt <chrisfriedt@gmail.com>
Subject: Re: [PATCH v4 4/4] doc: add documentation for accel subsystem
Date: Mon, 21 Nov 2022 08:26:50 -0700 [thread overview]
Message-ID: <5cc6f9eb-0221-2a55-453e-82cdc8a61b21@quicinc.com> (raw)
In-Reply-To: <CAFCwf13KLp7SzNjDE_EuhVePQ5=a-KEmzd7ytt3zY+tO6RyOxw@mail.gmail.com>
On 11/21/2022 8:18 AM, Oded Gabbay wrote:
> On Mon, Nov 21, 2022 at 12:02 AM Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>>
>> On 11/19/2022 1:44 PM, Oded Gabbay wrote:
>>> Add an introduction section for the accel subsystem. Most of the
>>> relevant data is in the DRM documentation, so the introduction only
>>> presents the why of the new subsystem, how are the compute accelerators
>>> exposed to user-space and what changes need to be done in a standard
>>> DRM driver to register it to the new accel subsystem.
>>>
>>> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
>>> ---
>>> Documentation/accel/index.rst | 17 +++++
>>> Documentation/accel/introduction.rst | 109 +++++++++++++++++++++++++++
>>> Documentation/subsystem-apis.rst | 1 +
>>> MAINTAINERS | 1 +
>>> 4 files changed, 128 insertions(+)
>>> create mode 100644 Documentation/accel/index.rst
>>> create mode 100644 Documentation/accel/introduction.rst
>>>
>>> diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst
>>> new file mode 100644
>>> index 000000000000..2b43c9a7f67b
>>> --- /dev/null
>>> +++ b/Documentation/accel/index.rst
>>> @@ -0,0 +1,17 @@
>>> +.. SPDX-License-Identifier: GPL-2.0
>>> +
>>> +====================
>>> +Compute Accelerators
>>> +====================
>>> +
>>> +.. toctree::
>>> + :maxdepth: 1
>>> +
>>> + introduction
>>> +
>>> +.. only:: subproject and html
>>> +
>>> + Indices
>>> + =======
>>> +
>>> + * :ref:`genindex`
>>> diff --git a/Documentation/accel/introduction.rst b/Documentation/accel/introduction.rst
>>> new file mode 100644
>>> index 000000000000..5a3963eae973
>>> --- /dev/null
>>> +++ b/Documentation/accel/introduction.rst
>>> @@ -0,0 +1,109 @@
>>> +.. SPDX-License-Identifier: GPL-2.0
>>> +
>>> +============
>>> +Introduction
>>> +============
>>> +
>>> +The Linux compute accelerators subsystem is designed to expose compute
>>> +accelerators in a common way to user-space and provide a common set of
>>> +functionality.
>>> +
>>> +These devices can be either stand-alone ASICs or IP blocks inside an SoC/GPU.
>>> +Although these devices are typically designed to accelerate Machine-Learning
>>> +and/or Deep-Learning computations, the accel layer is not limited to handling
>>
>> You use "DL" later on as a short form for Deep-Learning. It would be
>> good to introduce that here.
>>
>>> +these types of accelerators.
>>> +
>>> +typically, a compute accelerator will belong to one of the following
>>
>> Typically
>>
>>> +categories:
>>> +
>>> +- Edge AI - doing inference at an edge device. It can be an embedded ASIC/FPGA,
>>> + or an IP inside a SoC (e.g. laptop web camera). These devices
>>> + are typically configured using registers and can work with or without DMA.
>>> +
>>> +- Inference data-center - single/multi user devices in a large server. This
>>> + type of device can be stand-alone or an IP inside a SoC or a GPU. It will
>>> + have on-board DRAM (to hold the DL topology), DMA engines and
>>> + command submission queues (either kernel or user-space queues).
>>> + It might also have an MMU to manage multiple users and might also enable
>>> + virtualization (SR-IOV) to support multiple VMs on the same device. In
>>> + addition, these devices will usually have some tools, such as profiler and
>>> + debugger.
>>> +
>>> +- Training data-center - Similar to Inference data-center cards, but typically
>>> + have more computational power and memory b/w (e.g. HBM) and will likely have
>>> + a method of scaling-up/out, i.e. connecting to other training cards inside
>>> + the server or in other servers, respectively.
>>> +
>>> +All these devices typically have different runtime user-space software stacks,
>>> +that are tailored-made to their h/w. In addition, they will also probably
>>> +include a compiler to generate programs to their custom-made computational
>>> +engines. Typically, the common layer in user-space will be the DL frameworks,
>>> +such as PyTorch and TensorFlow.
>>> +
>>> +Sharing code with DRM
>>> +=====================
>>> +
>>> +Because this type of devices can be an IP inside GPUs or have similar
>>> +characteristics as those of GPUs, the accel subsystem will use the
>>> +DRM subsystem's code and functionality. i.e. the accel core code will
>>> +be part of the DRM subsystem and an accel device will be a new type of DRM
>>> +device.
>>> +
>>> +This will allow us to leverage the extensive DRM code-base and
>>> +collaborate with DRM developers that have experience with this type of
>>> +devices. In addition, new features that will be added for the accelerator
>>> +drivers can be of use to GPU drivers as well.
>>> +
>>> +Differentiation from GPUs
>>> +=========================
>>> +
>>> +Because we want to prevent the extensive user-space graphic software stack
>>> +from trying to use an accelerator as a GPU, the compute accelerators will be
>>> +differentiated from GPUs by using a new major number and new device char files.
>>> +
>>> +Furthermore, the drivers will be located in a separate place in the kernel
>>> +tree - drivers/accel/.
>>> +
>>> +The accelerator devices will be exposed to the user space with the dedicated
>>> +261 major number and will have the following convention:
>>> +
>>> +- device char files - /dev/accel/accel*
>>> +- sysfs - /sys/class/accel/accel*/
>>> +- debugfs - /sys/kernel/debug/accel/accel*/
>>> +
>>> +Getting Started
>>> +===============
>>> +
>>> +First, read the DRM documentation. Not only it will explain how to write a new
>>
>> How about a link to the DRM documentation?
>>
>>> +DRM driver but it will also contain all the information on how to contribute,
>>> +the Code Of Conduct and what is the coding style/documentation. All of that
>>> +is the same for the accel subsystem.
>>> +
>>> +Second, make sure the kernel is configured with CONFIG_DRM_ACCEL.
>>> +
>>> +To expose your device as an accelerator, two changes are needed to
>>> +be done in your driver (as opposed to a standard DRM driver):
>>> +
>>> +- Add the DRIVER_COMPUTE_ACCEL feature flag in your drm_driver's
>>> + driver_features field. It is important to note that this driver feature is
>>> + mutually exclusive with DRIVER_RENDER and DRIVER_MODESET. Devices that want
>>
>> I don't remember seeing code that validates a driver with
>> DRIVER_COMPUTE_ACCEL does not also have DRIVER_MODESET. What am I missing?
>
> Look at drm_dev_init() (patch 3/4):
>
> if (drm_core_check_feature(dev, DRIVER_COMPUTE_ACCEL) &&
> (drm_core_check_feature(dev, DRIVER_RENDER) ||
> drm_core_check_feature(dev, DRIVER_MODESET))) {
> DRM_ERROR("DRM driver can't be both a compute acceleration
> and graphics driver\n");
> return -EINVAL;
> }
Ah. I saw "RENDER", but "MODESET" didn't register in my brain. Thanks
for pointing it out to me. All good here.
next prev parent reply other threads:[~2022-11-21 15:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-19 20:44 [PATCH v4 0/4] new subsystem for compute accelerator devices Oded Gabbay
2022-11-19 20:44 ` [PATCH v4 1/4] drivers/accel: define kconfig and register a new major Oded Gabbay
2022-11-19 20:44 ` [PATCH v4 2/4] accel: add dedicated minor for accelerator devices Oded Gabbay
2022-11-20 21:47 ` Jeffrey Hugo
2022-11-21 15:11 ` Oded Gabbay
2022-11-19 20:44 ` [PATCH v4 3/4] drm: initialize accel framework Oded Gabbay
2022-11-22 10:55 ` Melissa Wen
2022-11-22 10:59 ` Oded Gabbay
2022-11-22 11:02 ` Oded Gabbay
2022-11-22 11:11 ` Melissa Wen
2022-11-19 20:44 ` [PATCH v4 4/4] doc: add documentation for accel subsystem Oded Gabbay
2022-11-20 22:01 ` Jeffrey Hugo
2022-11-21 15:18 ` Oded Gabbay
2022-11-21 15:26 ` Jeffrey Hugo [this message]
2022-11-20 15:26 ` [PATCH v4 0/4] new subsystem for compute accelerator devices Greg Kroah-Hartman
2022-11-20 22:04 ` Jeffrey Hugo
2022-11-22 15:57 ` Jeffrey Hugo
2022-11-21 6:25 ` Dave Airlie
2022-11-21 15:11 ` Oded Gabbay
2022-11-21 15:08 ` Thomas Zimmermann
2022-11-21 15:57 ` Alex Deucher
2022-11-21 15:58 ` Alex Deucher
2022-11-21 23:06 ` Sonal Santan
2022-11-22 5:46 ` Dave Airlie
2022-11-22 14:54 ` Daniel Vetter
2022-11-23 14:02 ` Sonal Santan
2022-11-22 10:17 ` Jacek Lawrynowicz
2022-11-23 12:27 ` Maxime Ripard
2022-11-24 18:34 ` Daniel Stone
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=5cc6f9eb-0221-2a55-453e-82cdc8a61b21@quicinc.com \
--to=quic_jhugo@quicinc.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=arnd@arndb.de \
--cc=chrisfriedt@gmail.com \
--cc=daniel@ffwll.ch \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jacek.lawrynowicz@linux.intel.com \
--cc=jagan@amarulasolutions.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=jiho.chu@samsung.com \
--cc=khilman@baylibre.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maciej.kwapulinski@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ogabbay@kernel.org \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=tzimmermann@suse.de \
--cc=yuji2.ishikawa@toshiba.co.jp \
/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
all inboxes | Powered by JetHome®