> The reason why I didn't implement the glX*Gallium*Mesa functions is
> because the glx* extensions are implemented by libGL, and a driver
> driver never has chance to export those extensions. And libGL is used
> for non-gallium drivers.
I solved this by adding a DRI driver extension for Gallium.
Non-Gallium drivers don't expose the extension and GLX returns null
for the calls.
Also, EGL support is either through egl_glx (based on the GLX
extension) or through the

> Furthermore, both on WGL and GLX the hardware specific driver is loaded
> quite late -- when the first GL context is created --, so the idea of
> having GL context independent extensions to create Gallium pipe_screens
> and pipe_contexts sounds good in theory but it's not how things work in
> practice.
My tests based on egl_glx worked without creating an EGL context.
It seems it's not necessary, even though it may need some other GLX
call (which you need anyway for fbconfig/visual setup).
I think it can be easily fixed though.

> So both things considered, using gl* extensions names instead of
> wgl*/glx* would make more sense:
> - libGL could remain untouched
> - same extensions names for all OSes
It has however the disadvantage of requiring Mesa and the OpenGL state
tracker even for Gallium-only applications. With the current interface
you could in principle remove both and still run Gallium code, while
using EGL/GLX only for window system setup.

In particular, an EGL application using the Gallium EGL state tracker
could run without libmesa.a with little adjustments and without
libmesagallium.a with some more adjustments.

Maybe a "direct Gallium state tracker" could be added, but it would
require duplicating the X11/DRM setup logic in EGL and GLX.

> Just to be clear -- names is not the big issue here, but keeping
> libGL.so Gallium agnostic is an important thing in the current
> circumstances -- libGL.so shouldn't be tied to any particular driver
> architecture in any way.
My patch doesn't add a Gallium dependency to libGL since all the work
happens behind the DRI Gallium extension.
The only Gallium specific code is "struct pipe_screen; struct
pipe_context; struct pipe_surface;" to declare the opaque structures
which are exposed to the users.

> Also, if these extensions become more than a hack for debugging gallium
> drivers then we need to start writing a spec for them too..
However the Gallium API is not stable and also mostly undocumented and
making it stable is probably not desirable in the short/medium term,
so this isn't a significant problem.

I have of couple of demos using this interface through EGL/egl_glx
(galliumgears and galliumglobe which displays a textured rendering of
Earth with Blue Marble imagery). I'm going to send them shortly.

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
Mesa3d-dev mailing list

Reply via email to