On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote:
> > 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

OK. Looks good to me.

> > 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.

In my view Gallium isn't an interface meant for applications and direct
accessing Gallium interface is exclusively for development/testings
purposes. Whatever works is good. 

> > 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.

The patches look good to me. I'm not familiar with EGL though, and I
haven't touched DRI in quite some time. Please allow a bit more time for
people to come back from vacations.

Jose


------------------------------------------------------------------------------
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
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to