----- 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. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
