[Mesa-dev] Drooping multiple driver support in EGL?

[Jose Fonseca]

----- Original Message -----
> On 01/13/2012 04:29 PM, Jose Fonseca wrote:
> >
> >
> > ----- Original Message -----
> >> On 01/12/2012 09:06 AM, Chia-I Wu wrote:
> >>> On Tue, Jan 10, 2012 at 12:55 AM, Jose
> >>> Fonseca<jfonseca at vmware.com>
> >>>   wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wu<olvaffe at gmail.com>
> >>>>>   wrote:
> >>>>>> On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick
> >>>>>> <idr at freedesktop.org>   wrote:
> >>>>>>> On 12/23/2011 07:20 AM, Jose Fonseca wrote:
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>>
> >>>>>>>>> Hi list,
> >>>>>>>>>
> >>>>>>>>> Multiple driver support in EGL is hard to get right, if not
> >>>>>>>>> impossible.
> >>>>>>>>> On Linux desktop, we almost always want to use egl_dri2.
> >>>>>>>>>  It
> >>>>>>>>> allows
> >>>>>>>>> EGL
> >>>>>>>>> to loads DRI2 drivers, thus allowing it to share DRI2
> >>>>>>>>> drivers
> >>>>>>>>> with
> >>>>>>>>> libGL.
> >>>>>>>>>
> >>>>>>>>> In one case where the app wants to use OpenVG, libEGL needs
> >>>>>>>>> to
> >>>>>>>>> load
> >>>>>>>>> egl_gallium instead.  The problem comes from that we cannot
> >>>>>>>>> know
> >>>>>>>>> that
> >>>>>>>>> an
> >>>>>>>>> OpenVG context is to be created until it is created.  But
> >>>>>>>>> before
> >>>>>>>>> a
> >>>>>>>>> context can be created, EGL needs to be initialized and an
> >>>>>>>>> EGLConfig
> >>>>>>>>> needs to be chosen.  So when EGL is to be initialized, we
> >>>>>>>>> need
> >>>>>>>>> to
> >>>>>>>>> load
> >>>>>>>>> and initilaize all EGL drivers.  When an EGLConfig is to be
> >>>>>>>>> picked,
> >>>>>>>>> we
> >>>>>>>>> need to pick it from all drivers.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Couldn't we restructure this such that OpenVG (and all other
> >>>>>>>> state
> >>>>>>>> trackers on Linux) still use a dri2 driver, but one which
> >>>>>>>> exposes
> >>>>>>>> an
> >>>>>>>> additional (gallium specific) interface?
> >>>>>>> I was going to suggest something similar.  I think we want
> >>>>>>> fewer
> >>>>>>> EGL
> >>>>>>> backends to test and maintain, not more.  Right?
> >>>>>> I totally agree with that.  I even had an unfinished branch
> >>>>>> for
> >>>>>> that.
> >>>>>>
> >>>>>> Note that this thread is about dropping multiple EGL driver
> >>>>>> support.
> >>>>>> The motivation for having OpenVG in DRI2 drivers is that we do
> >>>>>> not
> >>>>>> want multiple EGL drivers.  The former should push the latter
> >>>>>> to
> >>>>>> happen more quickly, instead of preventing it from happening.
> >>>>>
> >>>>> The problem with exposing the Gallium Interface via the DRI
> >>>>> interface
> >>>>> is that the DRI interface is public and stable while the
> >>>>> Gallium
> >>>>> one
> >>>>> is
> >>>>> not.
> >>>>
> >>>> I think one doesn't invalidate the other. That is, it is
> >>>> technically feasible to have an unstable interface on top of an
> >>>> stable interface. In detail, we could add a stable extension DRI
> >>>> ,
> >>>> which exposes Gallium (eg. DRI2GetGalliumScreen). Obviously, for
> >>>> things to work, it would be imperative that the libEGL.so and
> >>>> foo_dri.so were built together, which is already the case today.
> >>
> >> We don't get to require that lib*GL and *_dri.so be upgraded in
> >> lock-step.  Ever.
> >
> > I'm afraid I don't understand what you're trying to say.. (Who
> > requires what and why?)
> >
> >
> > Anyway, the fact is that gallium state tracker and pipe driver have
> > to  be upgraded in lock-step *today*, and my point is that it must
> > be
> > somehow possible to preserve that constraint, without having to do
> > something completely different from the non-gallium drivers.
> 
> This is another case where the term "DRI" is overloaded in an awkward
> and confusing way.  We cannot require that things loader side
> (libEGL,
> libGL, or the xserver's GLX module) be updated in lock-step with the
> drivers or vice versa.

Why? Is it because the X server will continue to run in the background w/ the old libEGL/libGL and may load the new xxx_dri.so drivers?

> We can version the interfaces and only have certain functionality
> when
> everyone agrees on the interfaces (e.g., the recent
> GLX_ARB_create_context work).  This sounds different than what was
> being
> discussed above, but I may be mistaken.

I'm not sure myself either how exactly gallium's OpenVG implementation is split across shared objects.

But intuitively I still think that it must be somehow possible to perserve lib(E)GL.so <-> xxx_dri.so loose versioning, w/ the gallium state tracker <-> pipe driver strict versioning, without doing something radically different between gallium and classic dri drivers. For example, leave lib(E)GL.so gallium agnostic, and put the OpenVG state tracker in a shared object on which the gallium based xxx_dri.so drivers can depend. Or something along those lines.

Jose