I will reply to the parts that I am more familiar with. On Tue, Jan 12, 2010 at 12:23 PM, Luca Barbieri <l...@luca-barbieri.com> wrote: >> 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. The sequence number change? I think we can work it out soon in the other thread. > 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. I am ok with EGL_MESA_gallium you proposed. My proposal is also easy to implement, but since I am not working on it, I don't want to hinder your work (which is promising!). Regarding the patches, I would like to see
* the extension be compile time (#ifdef EGL_MESA_gallium) or runtime checked (dpy->Extensions.MESA_gallium) * all new types are prefixed by "EGL" and suffixed by "Mesa". E.g., EGLg3dContextMesa. The naming rule is according to http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image.txt > 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. My suggestion for this is still http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10541.html I don't think egl_g3d can replace the stock libGL because, at least, it lacks indirect rendering. Longer term, you might consider revive the Xegl project. > 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
