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.
Section 3.9.3 of eglspec.1.4.20090623.pdf says:
  surface must be bound to the calling thread’s current context, for
the current ren-
  dering API. This restriction may be lifted in future EGL revisions.

I am reading your patches to egl-g3d.  I need to think about the rest
of the mail, and I will reply later.

> 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
Mesa3d-dev mailing list

Reply via email to