[Mesa-dev] Drooping multiple driver support in EGL?
Kristian Høgsberg
krh at bitplanet.net
Fri Jan 13 06:40:31 PST 2012
On Thu, Jan 12, 2012 at 12:06 PM, Chia-I Wu <olvaffe at gmail.com> 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.
> 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.
Very much in favor of this.
Kristian
More information about the mesa-dev
mailing list