[Mesa-dev] EGL_MESA_query_renderer

Thu Aug 23 08:55:53 UTC 2018

On Wed, 22 Aug 2018 at 19:12, Rob Clark <robdclark at gmail.com> wrote:
>
> On Wed, Aug 22, 2018 at 1:43 PM Emil Velikov <emil.l.velikov at gmail.com> wrote:
> >
> > On 21 August 2018 at 14:40, Rob Clark <robdclark at gmail.com> wrote:
> > > On Tue, Aug 21, 2018 at 5:19 AM Emil Velikov <emil.l.velikov at gmail.com> wrote:
> > >>
> > >> HI all,
> > >>
> > >> On 20 August 2018 at 20:01, Rob Clark <robdclark at gmail.com> wrote:
> > >> > +Emil since he had some interest in this extension too
> > >> >
> > >> >
> > >> Bth since I did not hear anything last week, so I sat down and wrote
> > >> the spec, implementation and tests on Sunday ;-)
> > >> I'll try to find some time to cleanup and sent out the patches later today.
> > >>
> > >> To reiterate my earlier suggestion
> > >>
> > >> "He can work on it in parallel and compare/cross-review one another's work.
> > >>
> > >> If people are not keen on the duplication effort, the time could be
> > >> invested that into other parts of the project (distro/flatpak
> > >> packaging, etc.)"
> > >>
> > >>
> > >> > On Mon, Aug 20, 2018 at 1:55 AM Veluri Mithun <velurimithun38 at gmail.com> wrote:
> > >> >>
> > >> >> Hi Nicolai and Rob,
> > >> >>
> > >> >> I've started to work on the extension and once finish writing procedures, functions and spec file related this, I'll create pull request to Khronos official Registry source code repo at Github.
> > >> >>
> > >> >> I'm following the steps present here https://www.mesa3d.org/devinfo.html
> > >> >> it has instructions for GL extensions and I feel that only a few differences will be there and the rest it will be similar for EGL extension
> > >> >>
> > >> >> To add a new GL extension to Mesa you have to do at least the following.
> > >> >>
> > >> >> If glext.h doesn't define the extension, edit include/GL/gl.h and add code like this:
> > >> >>
> > >> >>      #ifndef GL_EXT_the_extension_name
> > >> >>      #define GL_EXT_the_extension_name 1
> > >> >>      /* declare the new enum tokens */
> > >> >>      /* prototype the new functions */
> > >> >>      /* TYPEDEFS for the new functions */
> > >> >>      #endif
> > >> >>
> > >> >>
> > >> >> here for my confirmation I need to ask that I should define it in include/EGL/eglmesaext.h right?
> > >> >
> > >> > So, looks like eglmesaext.h basically just exists for extensions that
> > >> > haven't showed up in eglext.h from Khronos yet.  So I guess this would
> > >> > be the place.
> > >> >
> > >> That's what I've done yes.
> > >>
> > >> > At any rate, probably the first step is to write an initial version of
> > >> > docs/specs/EGL_MESA_query_renderer.txt and send that out for review.
> > >> >
> > >> Personally, I'd suggest working on an glXGetScreenDriver and
> > >> glXGetDriverConfig equivalent for EGL.
> > >> That in itself will be a _fairly_ laborious task, which seems to have
> > >> been underestimated/missed in the initial plan.
> > >
> > > so, it was earlier discussed that
> > > glXGetScreenDriver()/glXGetDriverConfig() equivalents could be lumped
> > > into this extension, which is I guess not what you have done.  (I'm
> > > not too picky, it could be a separate extension, we just kinda lumped
> > > it all together)
> > >
> > Personal suggestion is to keep them separate - they are somewhat unrelated.
> > An EGL extension which maps to the GLX one, and something else for the
> > glX hacks.
> >
> > In either case, designing is the most important/time consuming thing.
> > Checking that the API is sane and can work with GLVND is crucial IMHO.
> > This thread lists some details about the incompat. with the glX and GLVND.
> >
> > https://lists.freedesktop.org/archives/mesa-dev/2017-May/155838.html
> >
> >
> > >> It would involve a) writing another EGL extension or b) Wayland
> > >> protocol or c) other mechanism.
> > >
> > > I haven't looked into the details, but I guess in the EGL on x11 case,
> > > it would re-use however these work with glx?
> > >
> > In theory ... looking at the implementation glXGetScreenDriver
> > It calls back via the DRI1/DRI2 protocol asking for the driver name.
> > So the DRI3 (only) case is broken.
>
> iirc, dri3 is similar case to wayland, where we should enumerate the
> rendernodes, since there is no relationship between the screen and the
> gpu, ie. buffers are allocated on client side and pushed to server.
>
Hm I'm either failing to understand what you mean, or you haven't
looked through the code in a while.
In particular
src/egl/drivers/dri2/egl_dri.h, and
git grep -i drivername -- src/glx

Both of these have the node fd and/or driver name,of the device
allocating the buffers ;-)

> > We should be able to fix that by storing the driver_name (if we don't
> > already) in the [GLX]Display.
> > With similar approach on the EGL side.
> >
> > Haven't looked at the other API.
> >
> > > And in the EGL on wayland case, we can enumerate the drm rendernode
> > > devices on the client side.. there shouldn't really be any display
> > > server side component, so I guess we don't need any protocol.
> > >
> > Eek, looping through nodes. You do recall that this (depending on a
> > number of factors), can wake up every device on the system.
>
> *shrug*
>
> If that is a problem, then maybe we need to invent some new uapi that
> can query the devices without waking them up.. until then I guess we
> have to live with the unintended wakeup.
>
Wish I could go along with the shrug, sadly Firefox continues to do
silly things. Effectively waking the GPU device 5+ times, leading to
large startup delays.
Esp. since now when I'm looking at its sandboxing, which prevents us
from knowing the device/vendor/etc PCI ID :-\

I've added a revision file in sysfs to fix this, plus updated
libpciaccess and libdrm to use it.
Sadly some distributions are slow at updating things, so YMMV.

AFAICT adding UAPI on the DRM device won't cut it since, the ioctl
itself will wake up the device.

HTH
Emil