On Tue, Jan 10, 2012 at 12:55 AM, Jose Fonseca <[email protected]> wrote: > > > ----- Original Message ----- >> On Fri, Dec 23, 2011 at 7:51 PM, Chia-I Wu <[email protected]> wrote: >> > On Sat, Dec 24, 2011 at 12:37 AM, Ian Romanick >> > <[email protected]> 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. > > Jose -- [email protected] _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
