----- Original Message ----- > On 01/13/2012 04:29 PM, Jose Fonseca wrote: > > > > > > ----- Original Message ----- > >> On 01/12/2012 09:06 AM, Chia-I Wu 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. > >> > >> We don't get to require that lib*GL and *_dri.so be upgraded in > >> lock-step. Ever. > > > > I'm afraid I don't understand what you're trying to say.. (Who > > requires what and why?) > > > > > > Anyway, the fact is that gallium state tracker and pipe driver have > > to be upgraded in lock-step *today*, and my point is that it must > > be > > somehow possible to preserve that constraint, without having to do > > something completely different from the non-gallium drivers. > > This is another case where the term "DRI" is overloaded in an awkward > and confusing way. We cannot require that things loader side > (libEGL, > libGL, or the xserver's GLX module) be updated in lock-step with the > drivers or vice versa.
Why? Is it because the X server will continue to run in the background w/ the old libEGL/libGL and may load the new xxx_dri.so drivers? > We can version the interfaces and only have certain functionality > when > everyone agrees on the interfaces (e.g., the recent > GLX_ARB_create_context work). This sounds different than what was > being > discussed above, but I may be mistaken. I'm not sure myself either how exactly gallium's OpenVG implementation is split across shared objects. But intuitively I still think that it must be somehow possible to perserve lib(E)GL.so <-> xxx_dri.so loose versioning, w/ the gallium state tracker <-> pipe driver strict versioning, without doing something radically different between gallium and classic dri drivers. For example, leave lib(E)GL.so gallium agnostic, and put the OpenVG state tracker in a shared object on which the gallium based xxx_dri.so drivers can depend. Or something along those lines. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev