> Regardless of my personal preference as expressed, there are some minor issues > in the EGL part of the patch. One is that, it lifts certain restrictions > required by EGL 1.4 by commenting out the code (e.g. in eglSwapBuffers). It > should check if EGL_MESA_gallium is supported and decide what to do.
Is that restriction (the surface being swapped by eglSwapBuffers must be bound to the current context) actually in the spec? The man page at http://www.khronos.org/opengles/documentation/opengles1_0/html/eglSwapBuffers.html doesn't talk about contexts at all, and GLX doesn't have that restriction. As far as merging my patches, great, but there is some complexity involved, since there are various versions of them. First of all, the Gallium framework/programs code is now independent of the extensions as it contains its own main loop with DRI2 and KMS support, and can thus be merged now, independently of the extension and/or egl_g3d. This is quite useful for writing Gallium demos/tool in C: you call its init_and_render function passing a "draw" function pointer, and it calls back draw with a pipe_context and pipe_framebuffer_state you can use for drawing. Using it from Python would however require some adaptations. As for the extension, this is the current situation: 1. The orginal GLX and EGL patches. There are based on egl_glx, egl_softpipe and the GLX/DRI stack. They implement a GetGalliumSurfaces call which pulls surfaces out of an st_framebuffer. This makes them somewhat invasive and is inelegant since there is a dependency on the state tracker. 2. The EGL patch based on egl_g3d. This patch is much cleaner, thanks to egl_g3d's design, which is much better than the existing one as it separates the API implementation (in egl_g3d.c) from the abstraction of the underlying rendering system (the native_display/native_surface/native_config classes). This allows a very simple implementation of the Gallium extension. However, the patch I posted depends on changes to native_surface which I think are beneficial, but I'm not sure if Chia-I Wu likes. Note that this actually changes the extension interface, which now has a GetGalliumTextures function instead of GetGalliumSurfaces, that mimics Chia-I Wu's design of native_surface->validate, which I believe is superior to my initial interface design. 3. A new GLX implementation based on the egl_g3d native core, including a GLX_MESA I sent a preview of this to Chia-I Wu and have since made it work with all applications except single-buffered ones (due to egl_g3d dropping single-buffered visuals: this should be asily fixable), including compiz. I'll post a patch to the list soon with the code. Using this means however replacing (in actual use, not in the repository, of course) all the GLX/DRI stack with a new Gallium-only GLX implementation. Thus, of all the code involved, my new Gallium programs code and Chia-I Wu's egl_g3d can be merged now, as they have no dependencies and don't affect the existing code. As for the extensions, they somewhat depend on whether we decide to go with egl_g3d or not. If egl_g3d becomes the default EGL and GLX layer for Gallium drivers, then the egl_g3d versions of the extensions and the overall codebase are much cleaner. Otherwise, it's easy to add glXGetGalliumScreen and glXCreateGalliumContext on top of the existing code but getting surfaces/textures is a bit more ugly. Also, it may be a good idea to update the old patches to expose the new glXGetGalliumTextures with user-specified attachments rather than the old and uglier GetGaliumSurfaces interface. What do you think? ------------------------------------------------------------------------------ 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
