On 4/14/26 16:50, Michel Dänzer wrote:
> On 4/14/26 15:51, Khatri, Sunil wrote:
>> 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;
> 
> Indeed, looks like at least in some cases mutter creates the EGL context 
> before it has DRM master status. I'll look into fixing this in mutter.

I realized what I'm seeing is a regression from 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40519 , since a 
render node file description can't have DRM master status.

I created https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40974 to 
fix that.

-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Reply via email to