On 4/13/26 11:24, Khatri, Sunil wrote: > On 13-04-2026 02:32 pm, Christian König wrote: >> On 4/13/26 10:49, Sunil Khatri wrote: >>> In function amdgpu_userq_priority_permit allow till >>> maximum priority i.e 3 which is seen for gnome shell. >>> >>> This is needed to fix the issue of unable to create queue >>> for gnome shell. >>> >>> logs: >>> [drm] *ERROR* comm: gnome-shell pid: 2802 client-id:10 client: Unset ... >>> SK: Priority 3 >> Clear NAK, as far as I can see the existing code is correct. >> >> AMDGPU_USERQ_CREATE_FLAGS_QUEUE_PRIORITY_HIGH is only allowed when you have >> CAP_SYS_NICE, e.g. you are root. >> >> That is also documented in the UAPI. Question is why is gnome shell trying >> to use that? > I see, let me add Yogesh for his inputs, @yogesh, why gnome shell is asking > for priority AMDGPU_USERQ_CREATE_FLAGS_QUEUE_PRIORITY_HIGH. Based on the code > seems mesa is getting a flag set flags & PIPE_CONTEXT_HIGH_PRIORITY -> this > sets AMDGPU_USERQ_CREATE_FLAGS_QUEUE_PRIORITY_HIGH for graphics queue.
For some background, mutter uses EGL_CONTEXT_PRIORITY_HIGH_IMG when EGL_IMG_context_priority is supported, to try and prevent its GPU work from getting starved by clients. This works (or at least doesn't fail similarly) with kernel queues, presumably via DRM master status. I'd argue that should suffice with user queues as well. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
