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

[Ian Romanick]

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.

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.