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

[Ian Romanick]

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.

> 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