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
