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

[Chia-I Wu]

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.
It could be as simple as adding

  #define __DRI_API_OPENVG 4

with regard to interface change.  Then only st/dri needs to be updated
to create an OpenVG context when createNewContextForAPI is called.

>
> Jose



-- 
olv at LunarG.com