[Mesa-dev] [PATCH 2/2] egl, dri: Propagate context priority hint to driver->CreateContext

[Emil Velikov]

On 7 April 2017 at 09:50, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Thu, Apr 06, 2017 at 08:29:55PM -0400, Rob Clark wrote:
>> On Thu, Apr 6, 2017 at 3:12 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> > Jump through the layers of abstraction between egl and dri in order to
>> > feed the context priority attribute through to the backend. This
>> > requires us to read the value from the base _egl_context, convert it to
>> > a DRI attribute, parse it again in the generic context creater before
>> > passing it to the driver as a function parameter.
>> >
>> > Issues:
>> >
>> >  * How to pass back the priority of the create context (as it may be
>> > modified by the driver) back to EGL?
>>
>> Maybe driver provides a bitmask of supportable priority levels, and
>> then EGL clamps?  Or a NumPriorityLevels param?  That avoids needing
>> to get the value back from the driver and at least works for the
>> situations I can think of.  (Ie. either kernel+hw support multiple
>> priority levels or it doesn't.)  Maybe with an additional system level
>> limit, ie. maybe only compositor can be highest priority.. but that
>> seems like a system level thing rather than driver level thing, so
>> should be in EGL?
>
> We mirrored our kernel API around nice(2) in that we allow anybody to
> reduce their priority, but only a privileged process can raise it above
> 0. To be accurate, I was going to use the result of the context priority
> adjustment to see if the requested level was applied.
>
> I think we can at least do something like
>
> dri2_setup_screen:
>         dri2_dpy->*->getCapabilities()
>
> and use disp->Extensions.IMG_context_priority = (LO | MED | HI);
> to pass the support up the chain.

This sounds like a plan IMHO.

Humble suggestion though - do split the .CreateContext changes from
the rest of the patch.
Those are no-op, plus as-is the gallium drivers don't even build :-\

Thanks
Emil