On 7 April 2017 at 09:50, Chris Wilson <[email protected]> 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 <[email protected]> >> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
