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