Speaker
Description
Modern GPUs are moving more functionality into firmware in order to allow for user space to submit jobs directly and gain additional performance from that.
DRM framework for rendering nodes assumes that the kernel driver is in charge all the time and job submissions are only happening in kernel context.
io_uring is a mechanism inside the kernel that allows for asynchronously queuing requests from userspace and let them be handled by the kernel driver(s) in a batched mode. Adopting this (or a very similar) mechanism in DRM would allow us to gain the benefits of reduced context switching between userspace apps and kernel while keeping the kernel driver(s) for GPU(s) in charge of actual job submissions.
I am looking at gathering feedback on the idea and on why it might not be appropriate to add support for io_uring in DRM. We know that io_uring had its fair share of security issues and that Android for example disables it completely, but there are other aspects that need to be discussed like user space implementing a job scheduling on its own, or lack of a need for job scheduling at all as firmware might be completely in charge of that.
| Code of Conduct | Yes |
|---|---|
| In-person or virtual presentation | In-person |
| GSoC, EVoC or Outreachy | No |
