On Fri, 2 Jul 2021 09:58:06 -0400 Alyssa Rosenzweig alyssa@collabora.com wrote:
My Vulkan knowledge is limited so I'm not sure whether this is the right approach or not. In particular is it correct that an application can create a high priority queue which could affect other (normal priority) applications?
That's what msm does (with no extra CAPS check AFAICT), and the freedreno driver can already create high priority queues if PIPE_CONTEXT_HIGH_PRIORITY is passed. Not saying that's okay to allow userspace to tweak the priority, but if that's a problem, other drivers are in trouble too ;-).
Speaking of, how will PIPE_CONTEXT_HIGH_PRIORITY be implemented with the new ioctl()? I envisioned something much simpler (for the old ioctl), just adding a "high priority?" flag to the submit and internally creating the two queues of normal/high priority for drm_sched to work out. Is this juggling now moved to userspace?
That's what freedreno does. I guess we could create 2 default queues (one normal and one high prio) and extend the old submit ioctl() to do what you suggest if you see a good reason to not switch to the new ioctl() directly. I mean, we'll have to keep support for both anyway, but switching to the new ioctl()) shouldn't be that hard (I can prepare a MR transitioning the gallium driver to BATCH_SUBMIT if you want).