[Mesa-dev] EGL_MESA_query_renderer

[Nicolai Hähnle]

In a separate email, Rob wrote:

 > 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 fairly agnostic on this, but if you do lump it into one extension, 
please make the GetDriverConfig part optional.

There are non-Mesa drivers which implement GLX_MESA_query_renderer, and 
it'd be good if the same were at least possible for 
EGL_MESA_query_renderer as well.

Cheers,
Nicolai


On 22.08.2018 07:24, Veluri Mithun wrote:
> Hi all,
> 
> On Tue, Aug 21, 2018 at 2:49 PM Emil Velikov <emil.l.velikov at gmail.com 
> <mailto:emil.l.velikov at gmail.com>> wrote:
> 
>     HI all,
> 
>     On 20 August 2018 at 20:01, Rob Clark <robdclark at gmail.com
>     <mailto: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.
> 
> I can see only tests 
> here(https://gitlab.freedesktop.org/mesa/piglit/compare/2fa9b8fa3e81e230977c2b16ca5b03dd6d85d69b...166c6e3a955c7ed6ac9c514abb6da30b04f81c8e) 
> may I please know more about these tests...
> 
> and in mesa dev list also I didn't find any patch related to spec and 
> imlplementation..!(If had not missed any mail :-) )
> 
> 
>     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.)"
> 
> Actual plan(proposal) is to first create extension then use that in 
> adriconf and then packaging.
> But, If you( @Jean Hertel <mailto:jean.hertel at hotmail.com> , @Rob Clark 
> <mailto:robdclark at gmail.com> )are okay if I do packaging before creating 
> extension(adriconf can't configure drivers in wayland) then I can 
> continue with packaging. Later after we finish extension I can come to 
> adding wayland support in adriconf. Rob and Jean pl. give your opinoin 
> about this.
> 
> 
>     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.
> 
>     It would involve a) writing another EGL extension or b) Wayland
>     protocol or c) other mechanism.
> 
> This extension is intended to provied the similar functionality as like 
> glXGetScreenDriver and GlXGetDriverConfig work in X11. Something like 
> EGLGetDriverConfig and EGLGETScreenDriver (or EGLGETDisplayDriver I 
> think.. ) in wayland server.
> 
> To be more clear EGLGETDriverConfig should provide an xml format string 
> with all the options in different languages as seen in X11 when 
> *xdriinfo* is run and EGLDIsplayDriver should return a driver 
> name(string eg: i965) of current driver in use.
> 
> And also EGLQueryRendererInteger which returns id like pciID(like in x11).
> 
> Only after we achevie these through any EGL extension, adriconf can 
> configure drivers in wayland protocol.
> 
> 
>      > I don't think this extension should require any driver specific
>      > functionality?  (But maybe some window system specific
>      > functionality??)
>      >
>     Extensions piggy-backs on the DRI extension - implementation is ~200
>     loc ;-)
> 
>      >> EGL_MESA_drm_image_formats is what I can refer I think, Do you
>     know any other extensions?
>      >
>      > That is probably a reasonable one to look at.  Probably git-blame on
>      > eglmesaext.h and eglext.h and then going at looking at the patches
>      > around there which add the corresponding extensions would be useful.
>      > (Maybe eglext.h less useful, since it probably has a lot of
>     "resyncing
>      > Khronos headers" type commits..)
>      >
>     Rob is on spot, yet again. Many header and synced from Khronos. I
>     would ignore those and look at the rest for examples.
>     Personally I started with the GLX extension, tweaking it here and
>     there ;-)
> 
> 
>     Something that kind of hit me, why is the project status/emails like
>     these happening in private?
>     It doesn't seem to follow the open-source mantra and others interested
>     in learning about Mesa/adriconf are left in the dark.
> 
>     On my GSoC pretty much everything was done on the public discussion
>     medium. The next year when Varad was doing a GSoC same thing happened.
>     Am I missing something?
> 
> I'm sry about this!
> 
> 
>     Thanks
>     Emil
> 
> 
> Sincerely,
> Veluri.