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<[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.
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.
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.
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
