On Fri, 2010-01-01 at 10:13 -0800, José Fonseca wrote: > 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.
I think that there was enough time for everybody interested to voice their opinion. I'm going to start committing Luca's patches. 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
