On 14-04-2026 07:12 pm, Michel Dänzer wrote:
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.
Below is the check that we have for userqueues during queue creation,
and for gnome it did not hit any of the condition and eventually return
with -EACCES that is wrong. It has to be maste or CAP_SYS_NICE capable.
if(priority<AMDGPU_USERQ_CREATE_FLAGS_QUEUE_PRIORITY_HIGH)
return0;
if(capable(CAP_SYS_NICE))
return0;
if(drm_is_current_master(filp))
return0;
return-EACCES;
regards
Sunil khatri
