[fix subject..] On Fri, Dec 23, 2011 at 2:31 AM, Kenneth Graunke <kenn...@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? > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev