News: 0001497768

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Arm Exploring IO_uring For Graphics Drivers For Better Performance & Synchronization

([Linux Kernel] 4 Hours Ago DRM Drivers + IO_uring)


The [1]IO_uring asynchronous I/O API for Linux is quite novel and has proven performance benefits. With time IO_uring has been adapted to other areas of the kernel like networking and now with a proposal raised by an Arm graphics driver engineer, it could potentially be adapted for use by Direct Rendering Manager (DRM) kernel graphics drivers.

Liviu Dudau of Arm who is currently working on the Panthor DRM driver for modern Arm Mali hardware is exploring the possibility of using IO_uring for handling job submission to graphics drivers outside the kernel.

This approach would better jive with how Vulkan drivers could ideally function, would allow for better performance by letting user-space submit jobs directly to the hardware/firmware, and easier synchronization handling.

Thus a proposal to add IO_uring support to the Direct Rendering Manager subsystem. The idea is to submit work over to the kernel drivers via a submission queue that would wrap around the actual GPU job submission. The submission queue would only contain pointers to buffers and fences, thereby eliminating kernel copies. The IO_uring submission would be done at the kernel DRM framework level and thus potentially shared by all GPU kernel drivers.

Liviu Dudau raised the proposal at XDC 2024 happening this week in Montreal. See [2]the PDF slide deck and the presentation embedded below. It will be interesting to see where this IO_uring DRM work leads for improving job submission for Linux GPU drivers.



[1] https://www.phoronix.com/search/IO_uring

[2] https://indico.freedesktop.org/event/6/contributions/309/attachments/229/309/io_uringforDRM.pdf



davidbepo

Vermilion

discordian

aviallon

coder

The following quote is from page 4-27 of the MSCP Basic Disk Functions
Manual which is part of the UDA50 Programmers Doc Kit manuals:

As stated above, the host area of a disk is structured as a vector of
logical blocks. From a performance viewpoint, however, it is more
appropriate to view the host area as a four dimensional hyper-cube, the
four dimensions being cylinder, group, track, and sector.
. . .
Referring to our hyper-cube analogy, the set of potentially accessible
blocks form a line parallel to the track axis. This line moves
parallel to the sector axis, wrapping around when it reaches the edge
of the hyper-cube.