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

[Chia-I Wu]

[fix subject..]

On Fri, Dec 23, 2011 at 2:31 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 12/22/2011 09:01 AM, Chia-I Wu wrote:
>> 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.
>>
>> But this also introduces new problems.   For example, when the vendor
>> string or the extension string is queried, whose string of all EGL
>> drivers should be returned?
>>
>> My proposal is to simply drop multiple driver support from EGL.
>> Instead, we will provide four libEGL implementations:
>>
>>  - libEGL_dri2: derived from egl_dri2
>>  - libEGL_gallium: derived from egl_gallium
>>  - libEGL_glx: derived from egl_glx
>>  - libEGL_loader: see below
>
> Somewhat tangentially...what is the advantage of egl_glx?  Does anybody
> use it?   Why?  Is it being tested?
It is the last driver from the early days.  I do not use it myself and
am not sure about the status.

As it aims to work with any GLX implementation, one use is to run
EGL+GLES2 apps on GLX+GLX_EXT_create_context_es2_profile.  With some
tweaking for sure.

>
> I'm mostly curious, as I've always used egl_dri2.
It seems to make sense to install libEGL_dri2 as libEGL in autoconf-based build.
>> All of them are conformant EGL implementations.  That is, any one of
>> them can be installed as /usr/lib/libEGL.so.
>>
>> libEGL_loader is new.  It is basically a wrapper that loads another
>> implementation to do the real work.  As such, the problems we face with
>> multiple driver support will remain in libEGL_loader.
>>
>> Distros may choose to install libEGL_loader as libEGL and let it pick
>> the real implementation.  Or they may choose to have the first three
>> installed as libEGL, and package them separately.
>>
>> Thoughts?
>



-- 
olv at LunarG.com