[Mesa-dev] distribution of EGL and its drivers and client APIs

[Chia-I Wu]

On Sat, May 8, 2010 at 3:56 AM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> On Fri, May 7, 2010 at 7:33 PM, Keith Whitwell <keithw at vmware.com> wrote:
>> On Fri, 2010-05-07 at 10:47 -0700, Jakob Bornecrantz wrote:
>>> 2010/5/7 Kristian Høgsberg <krh at bitplanet.net>:
>>> > 2010/5/7 Jakob Bornecrantz <wallbraker at gmail.com>:
>>> > ...
>>> >>> No I understand that.  We currently have an interface between libEGL
>>> >>> and the EGL driver it loads.  You're proposing to move that interface
>>> >>> up the stack to just below the EGL entry points.  It's still going to
>>> >>> be a custom shared library interface and we're still stuck with one
>>> >>> .so (libEGL) dlopening another (EGL driver), which then dlopens a
>>> >>> third .so (DRI driver or gallium driver).
>>> >>
>>> >> On a unrelated note if the distro choice to ship (or user choice to
>>> >> install) a gallium egl driver libEGL would load it directly without
>>> >> going via the egl_dri2.so loader.
>>> >
>>> > I know, but the gallium EGL driver will still have to dlopen the
>>> > gallium chipset driver.
>>>
>>> They are statically linked.
>>>
>>> >
>>> >>> But you still didn't answer my question: what problem does this solve?
>>> >>
>>> >> Pretty much for all the same reasons we have a libGL dispatcher.
>>> >
>>> > I don't think any of those apply to libEGL.  Could you list some of
>>> > those reasons?  Here's what I got:
>>> >
>>> >  - Ability to switch the underlying implementation for entry points on
>>> > the fly (for glBegin/End)
>>>
>>> Right this does not apply.
>>>
>>> >
>>> >  - Ability to share libGL between different driver vendors (that is,
>>> > closed source drivers could share the same libGL while sharing only
>>> > minnal code), which never happened.
>>>
>>> With my nVidia/ATI user hat on, that would be pretty neat, and untill
>>> we get good enough FOSS drivers for the hardware it would make it
>>> easier for everybody involved if this would happen.
>>>
>>> Now only the people involved with the nVidia/ATI drivers can say for
>>> sure, but I wouldn't be surprised that it was due to us using a
>>> different glx implementation and/or them not using DRM/DRI. That is
>>> nothing to do with the dispatcher itself but the fact that libGL came
>>> bundled with other code that they didn't agree with.
>>>
>>> >
>>> > Other than that, having the abstraction layer so high in the stack, is
>>> > just really awkward.  A more natural split would keep more code in
>>> > libGL and only dlopen the driver specific parts.  Essentially what
>>> > ajax did with the dri_core hack in the Fedora RPMs, or you know, how
>>> > gallium splits the core state tracker and the driver in two parts.
>>> > And it's how libEGL is structured today: we have all the highl-level
>>> > API logic in libEGL which then calls into the dlopened driver to make
>>> > it happen.
>>> >
>>> >> Given
>>> >> that if we where to roll egl_dri2.so into the libEGL library the API
>>> >> exported by libEGL would be the dri interface we would not need one.
>>> >> But I like to keep the ability to load native (for lack of a better
>>> >> word) EGL drivers.
>>> >
>>> > We already have that ability.  That's what the egl/main / egl/drivers interface does.
>>>
>>> It was a counter point to my own idea of just bundling egl/main
>>> egl_dri2 together in libEGL. That is with regards to that I like
>>> things to stay the way things are now.
>>>
>>> > And we don't have to worry about binary compatibility there, we always build libEGL and drivers from the same mesa release. Mixing and matching libEGL and EGL drivers from different releases isn't allowed as it is for DRI drivers and there's no reason it should be.
>>> >
>>>
>>> With my VMware hat firmly on, mixing support, do want!
>>
>> I think I have to say I don't have a clear idea how this relates to
>> anything we're doing at VMware.
>>
>> This looks like a discussion about how to split up the EGL stack into
>> loadable modules.  I'm sure there are pros and cons for making that
>> split at various levels, but it's not really valid to say that we've got
>> any sort of corporate opinion on that...
>>
>> Basically it sounds like Jakob has an architecture he's interested in
>> pursuing, but this seems to be a bit of a round-about way of creating a
>> discussion about it.
>>
>> Jakob -- Maybe the best thing to do would be to take a step back from
>> this change and really put some effort into describing what your desired
>> architecture is, how it differs from what's there now, what the
>> advantages & disadvantages are, and then have a proper discussion about
>> the whole thing?
> Sure, this turned out a bit bigger then I was hoping to. I'll get to
> that later in the weekend, now its beer o clock.
Looking at the list of libraries that dlopen()

  1) GLX libGL and DRI drivers
  2) libEGL    and EGL drivers
  3) egl_dri2  and DRI drivers
  4) egl_g3d   and API trackers (see 63ab2509)

1) & 3) will fall back, or fail, more elegantly than 2) & 4) when the versions
mismatch because there is a defined ABI for DRI.

For 4), the interface used is st_api.h, which uses pipe_texture or pipe_screen
for data exchange.  There cannot be an ABI here.  It is better to simply
distribute egl_g3d and API trackers together.

For 2), there is no defined ABI between libEGL and its drivers right now.  If
we force libEGL and its drivers to be distributed together, because of 4), it
will be a big package consits of libEGL, all EGL drivers, and all API trackers.
That is, a distribution must distribute Mesa as

  - libGL
  - DRI drivers
  - libEGL, EGL drivers, and API trackers

I think Jakob is trying the solve the issue by defining an ABI between libEGL
and its drivers.  This way, a distribution can distribute them as 5 packages
that can be upgraded independently

  - libGL
  - libEGL
  - DRI drivers
  - egl_dri2
  - egl_g3d and API trackers

One thing to note here is that 4) must be distributed together because pipe
drivers are compiled into egl_g3d.  An alternative I can think of is to turn 4)
into

  4a) (egl_g3d without pipe drivers) and (pipe drivers + API trackers)

The ABI between 4a) is defined by drm_api.h and st_api.h together.  Note that
they are _not_ part of the Gallium interfaces.  A distribution can then have 4
independently upgradable packages

  - libGL
  - libEGL and EGL drivers
  - DRI drivers
  - pipe drivers and API trackers (a.k.a. Gallium drivers)

-- 
olv at LunarG.com