On Thu, Jan 12, 2012 at 12:06 PM, Chia-I Wu <olva...@gmail.com> wrote: > On Tue, Jan 10, 2012 at 12:55 AM, Jose Fonseca <jfons...@vmware.com> wrote: >> >> >> ----- Original Message ----- >>> On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wu <olva...@gmail.com> wrote: >>> > On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick >>> > <i...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
