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

[Jose Fonseca]

----- 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.

Jose