On Wed, Aug 22, 2018 at 1:43 PM Emil Velikov <emil.l.veli...@gmail.com> wrote: > > On 21 August 2018 at 14:40, Rob Clark <robdcl...@gmail.com> wrote: > > On Tue, Aug 21, 2018 at 5:19 AM Emil Velikov <emil.l.veli...@gmail.com> > > wrote: > >> > >> HI all, > >> > >> On 20 August 2018 at 20:01, Rob Clark <robdcl...@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 <velurimithu...@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. > 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. BR, -R > My suggestions above could work, although another think to consider > why the driver name is needed in the first place? > That is the key information that it provides that we find so > user-friendly/needed? > > Having a the marketing string name (like the AMD's here [1]) seems > better candidate for a GUI aimed at your average user ;-) > > > A note to Veluri since we haven't interacted before: > > I am a person who questions, in order to understand the design and > inspire people to look at the problem differently. > A good quote from MarkJ: looking for a needle in a haystack? one > approach is to burn the haystack. > > HTH > Emil > > [1] Mesa provides it, as well as libdrm_amdgpu directly > https://gitlab.freedesktop.org/mesa/drm/blob/master/data/amdgpu.ids _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
