[Mesa-dev] Drooping multiple driver support in EGL?
kenneth at whitecape.org
Thu Dec 22 10:31:22 PST 2011
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
> 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?
I'm mostly curious, as I've always used egl_dri2.
> 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.
More information about the mesa-dev