Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
>> 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. This can be solved by making libGL load a GLX driver. One of them would be egl_g3d, and another the existing code for indirect rendering and legacy DRI. Or possibly some newly written XCB-based indirect rendering GLX driver, if anyone wants to do that. -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
I will reply to the parts that I am more familiar with. On Tue, Jan 12, 2010 at 12:23 PM, Luca Barbieri 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 distrib
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Tue, Jan 12, 2010 at 12:39 PM, Luca Barbieri wrote:
> Indeed both EGL 1.0 and EGL1.4 contain that language in the specs, but
> the Khronos manpage does not.
> I think we can safely ignore this.
> Applications are very unlikely to rely on eglSwapBuffers failing in
> that case, and anyway the specification explicitly prohibits them from
> doing so by saying that the restriction may be lifted.
> It seems the intent of the specification is to say "implementations
> are allowed to only support surfaces bound to the current context; an
> unrestricted implementation is also possible, but applications must
> not rely on the restriction not being present".
> In this case, users of EGL_MESA_gallium would depend on not having the
> restriction, but that's OK because EGL_MESA_gallium guarantees that
> behavior.
Could it be
if (!disp->Extensions.MESA_gallium) {
/* checks if the surface is current */
}
?
--
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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
Indeed both EGL 1.0 and EGL1.4 contain that language in the specs, but the Khronos manpage does not. I think we can safely ignore this. Applications are very unlikely to rely on eglSwapBuffers failing in that case, and anyway the specification explicitly prohibits them from doing so by saying that the restriction may be lifted. It seems the intent of the specification is to say "implementations are allowed to only support surfaces bound to the current context; an unrestricted implementation is also possible, but applications must not rely on the restriction not being present". In this case, users of EGL_MESA_gallium would depend on not having the restriction, but that's OK because EGL_MESA_gallium guarantees that behavior. -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Tue, Jan 12, 2010 at 12:23 PM, Luca Barbieri 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 http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
> 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Tue, Jan 12, 2010 at 5:06 AM, José Fonseca wrote: > I think that there was enough time for everybody interested to voice > their opinion. > I'm going to start committing Luca's patches. Are both GLX_MESA_gallium and EGL_MESA_gallium required for direct Gallium access? If GLX_MESA_gallium alone suffices, I hope the EGL part could be postponed. 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. -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Fri, 2010-01-01 at 10:13 -0800, José Fonseca wrote: > 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. I think that there was enough time for everybody interested to voice their opinion. I'm going to start committing Luca's patches. 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Fri, 2010-01-01 at 10:13 -0800, José Fonseca wrote: > On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote: > > 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. Something like a "direct state tracker" would be required if we ever wanted to export a stable Gallium API. This is because Gallium *will* change, but we want the API to be stable, so the "direct state tracker" would start off as a direct mapping between the API and Gallium, but as Gallium evolves, the state-tracker would grow to map between the stable and current versions of Gallium. Note that the Direct state tracker has already been written -- more or less it is just what's in drivers/identity... Keith -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Mon, Jan 4, 2010 at 2:24 AM, Luca Barbieri wrote: > Yes, that's a possible way to implement this. > However, it would artificially introduce the notion of a current context in > Gallium. > Also, if you mean implementing this as an egl_g3d API, it seems to me you > would have to implement the whole st_public_tmp.h for Gallium. > This would introduce more artificial notions like framebuffers with front > and back attachments, draw and read buffers, texture image binding, and so > on. I was talking about a way to support Gallium in EGL that I think fit the existing model, by treating it as a client API. Depending on how you define the client API, it may not be too much effort to implement and not be too much different to use than EGL_MESA_gallium. You may also avoid all the artifacts. For example, if the following changes are made * eglCreateGalliumContextMESA may be replaced by eglBindAPI(EGL_GALLIUM_API_MESA) and eglCreateContext(...) * eglGetGalliumScreenMESA is replaced by g3dGetScreen(G3DeglDisplay), where G3DeglDisplay is casted from EGLDisplay * eglGetGalliumSurfacesMESA is replaced by g3dGetSurfaces(G3DeglDisplay, * G3DeglSurface, ...), where G3DeglSurface is casted from EGLSurface. You get exactly what you can do with EGL_MESA_gallium, and a perfect EGL extension. The latter two functions belong to GALLIUM API and you are free to define them whatever you want. Incidentally, about the casting, I know this may look silly but it is how EGL resources are passed to client APIs http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image.txt http://www.khronos.org/registry/vg/extensions/KHR/VG_KHR_EGL_image.txt > Instead, the point of accessing a Gallium context is to be able to use > *only* pipe_context functions after doing initial setup with EGL (except > possibly for presenting the drawn pipe_surface to the user with > eglSwapBuffers). > So, for instance, setting a framebuffer has to happen via the user calling > pipe->set_framebuffer_state, not EGL. > EGL only needs to provide a struct pipe_context* (and if pipe_screen had a > create_context function like it should, then EGL would only need to provide > a pipe_screen*) > It also needs to either provide a struct pipe_surface* for the screen or > provide an interface to show an user created struct pipe_surface* on the > screen. -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
I'm porting the patch to egl_g3d right now, so that there is something concrete to talk about. -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
Yes, that's a possible way to implement this. However, it would artificially introduce the notion of a current context in Gallium. Also, if you mean implementing this as an egl_g3d API, it seems to me you would have to implement the whole st_public_tmp.h for Gallium. This would introduce more artificial notions like framebuffers with front and back attachments, draw and read buffers, texture image binding, and so on. Instead, the point of accessing a Gallium context is to be able to use *only* pipe_context functions after doing initial setup with EGL (except possibly for presenting the drawn pipe_surface to the user with eglSwapBuffers). So, for instance, setting a framebuffer has to happen via the user calling pipe->set_framebuffer_state, not EGL. EGL only needs to provide a struct pipe_context* (and if pipe_screen had a create_context function like it should, then EGL would only need to provide a pipe_screen*) It also needs to either provide a struct pipe_surface* for the screen or provide an interface to show an user created struct pipe_surface* on the screen. -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Sun, Jan 03, 2010 at 04:14:30PM +0100, Luca Barbieri wrote: > I don't think we want to use the same Gallium context for multiple state > trackers and/or the Gallium code in the application, because they will break > each other's assumptions about bound constant objects and state. > There may be some synchronization issue. Currently Nouveau multiplexes all > the Gallium context on a single hardware FIFO. Other driver can implement > and use fence objects. Every call to eglCreateContext will create a new pipe context. You may consider the currently bound API as an additional argument. That is, eglBindAPI(EGL_xxx_API); eglCreateContext(...); is equivalent to eglCreateContext(..., EGL_xxx_API); When one calls, for example, eglCreateContext(..., EGL_OPENGL_API), EGL will create a pipe context, which is wrapped in a Mesa st context, which is wrapped in an EGL context. eglGetGalliumContext() ignores the Mesa st context and peeks the implementation detail; While making Gallium a client API fits perfectly with the EGL model. When one calls eglCreateContext(..., EGL_GALLIUM_API_MESA) EGL will create a pipe context wrapped in a EGL context. One benefit of this approach is that Mesa st context will not be created. If eglGetGalliumContext() was implemented, it could be still used to get the underlying pipe context. But now that Gallium is a client API, it would be better if the task is left to Gallium itself. That is, ... > eglBindAPI seems to cause eglCreateContext/eglMakeCurrent to not create on > OpenGL context, but rather create and manipulate a context for the other > API. Is that correct? Gallium doesn't have a notion of a current context, so > it seems it wouldn't fit that well. ... we can define "Gallium Client API" to something like #include "pipe/p_state.h" /** * Most API entries of Gallium are provided as member functions of the * pipe context. Unlike other client APIs, where all entries assume * an implicit argument (that is, the current context), Gallium has no * such assumption, except for g3dGetContext(). */ struct pipe_context * g3dGetContext(void); Since pipe context has no reference count, a note might be added /** * The returned pipe context may be used even if the context is no * longer current. This is because there is no assumption of a * current context in Gallium. However, one should note that the life * time of the context is not defined by Gallium itself. It depends * on the API used to create the pipe context. */ > Resource sharing only requires sharing a pipe_screen, which is part of the > point of accessing Gallium via GLX/EGL. > It could be accomplished with an additional OpenGL extension providing APIs > like glGetGalliumTextureMESA(texid), glGetGalliumBufferMESA(bufid), > glGetGalliumRenderbufferTextureMESA(rbid), glGetGalliumFenceMESA(fence) > possibly glGetGalliumFramebufferMESA(fboid, pipe_framebuffer_state*). -- Regards, olv -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
I don't think we want to use the same Gallium context for multiple state trackers and/or the Gallium code in the application, because they will break each other's assumptions about bound constant objects and state. There may be some synchronization issue. Currently Nouveau multiplexes all the Gallium context on a single hardware FIFO. Other driver can implement and use fence objects. eglBindAPI seems to cause eglCreateContext/eglMakeCurrent to not create on OpenGL context, but rather create and manipulate a context for the other API. Is that correct? Gallium doesn't have a notion of a current context, so it seems it wouldn't fit that well. Resource sharing only requires sharing a pipe_screen, which is part of the point of accessing Gallium via GLX/EGL. It could be accomplished with an additional OpenGL extension providing APIs like glGetGalliumTextureMESA(texid), glGetGalliumBufferMESA(bufid), glGetGalliumRenderbufferTextureMESA(rbid), glGetGalliumFenceMESA(fence) possibly glGetGalliumFramebufferMESA(fboid, pipe_framebuffer_state*). -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Sat, Dec 26, 2009 at 03:04:51AM +0100, Luca Barbieri wrote: > This patch adds two extensions, EGL_MESA_gallium and GLX_MESA_gallium, > which allow an application to directly access the Gallium3D API > bypassing OpenGL and using EGL or GLX for general setup. > The python state tracker already uses the GLX_MESA_gallium functions > (due to a commit by Jose Fonseca), but the functions are not actually > implemented. > There is already a WGL extension with wglGetGalliumScreenMESA and > wglCreateGalliumContextMESA. A wglGetGalliumSurfacesMESA function > should probably be added to match the EGL/GLX versions in this patch. > It adds 3 functions: > (egl|glx)GetGalliumScreenMESA: returns a pipe_screen for an X11 > display/screen or an EGL display > (egl|glx)CreateGalliumContextMESA: creates a pipe_context for an X11 > display/screen or an EGL display > (egl|glx)GetGalliumSurfacesMESA: returns all pipe_surface attachments > for an X11 drawable or EGL surface For the EGL part, is it possible to define Gallium as a client API? Then the setup code would look like (pseudo code): eglBindAPI(EGL_GALLIUM_API_MESA); ctx = eglCreateContext(); suf = eglCreateWindowSurface(); eglMakeCurrent(ctx, surf); And the new "Gallium Client API" provides: p_context = g3dGetContext(); fb = g3dGetFramebuffer(); This way, it allows mixing OpenGL/OpenVG/Gallium, and resource sharing between them. -- Regards, olv -- 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
> 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
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
Hi Luca, This is something I'm very interested but I'm on travel and I'll need some more time to review it. Just a few quick thoughts. Python state tracker has the code to call glxGetGalliumScreenMESA and glxCreateGalliumContextMESA but I never got around to implement these functions on any glx/dri/etc state tracker, and I'm glad to see you making progress on that direction. 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. 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. 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 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. Also, if these extensions become more than a hack for debugging gallium drivers then we need to start writing a spec for them too.. Jose On Fri, 2009-12-25 at 18:04 -0800, Luca Barbieri wrote: > This patch adds two extensions, EGL_MESA_gallium and GLX_MESA_gallium, > which allow an application to directly access the Gallium3D API > bypassing OpenGL and using EGL or GLX for general setup. > > The python state tracker already uses the GLX_MESA_gallium functions > (due to a commit by Jose Fonseca), but the functions are not actually > implemented. > There is already a WGL extension with wglGetGalliumScreenMESA and > wglCreateGalliumContextMESA. A wglGetGalliumSurfacesMESA function > should probably be added to match the EGL/GLX versions in this patch. > > It adds 3 functions: > (egl|glx)GetGalliumScreenMESA: returns a pipe_screen for an X11 > display/screen or an EGL display > (egl|glx)CreateGalliumContextMESA: creates a pipe_context for an X11 > display/screen or an EGL display > (egl|glx)GetGalliumSurfacesMESA: returns all pipe_surface attachments > for an X11 drawable or EGL surface > > The array returned by GetGalliumSurfacesMESA must be freed by the application. > > They are implemented for egl_glx, and the EGL and GLX DRI loaders and > drivers. The egl_glx implementation simply wraps the GLX functions. > > The first two functions are trivially implemented, while > GetGalliumSurfaces is trickier. > > The problem is that the current code assumes that a GL context is > bound when getting surfaces, so most of the invasive changes in this > patch remove this assumption. > > Currently, this only works for double buffered DRI surfaces, because > the flush_framebuffer functions provided by DRI get the surface to > flush from the current GL context. > How to fix this is not obvious. An option could be to provide an > (egl|glx)FlushFrontbuffer function with takes a drawable as input. > Another option would be to change (egl|glx)SwapBuffers to do > frontbuffer flushing without a GL context (it currently does that > indirectly by calling glFlush()). > Also currently surfaces are extracted from an st_framebuffer, which is > not ideal as it keeps a dependency on the Mesa state tracker > > The patch assumes that my previous MESA_screen_surface patch has been > applied. The patches are independent, but they textually conflict on > the function tables. > > A GL_MESA_gallium extension could be implemented in the future for > access to the underlying Gallium objects of OpenGL textures, buffers > and renderbuffers. > Some way to access the GLSL compiler without OpenGL would also be useful. > > --- > include/EGL/eglext.h | 20 +++ > include/GL/glxext.h | 20 +++ > include/GL/internal/dri_interface.h | 19 +++ > src/egl/drivers/glx/egl_glx.c | 28 ++ > src/egl/main/eglapi.c | 40 ++- > src/egl/main/eglapi.h | 11 > src/egl/main/egldisplay.h |1 + > src/egl/main/eglmisc.c|6 ++- > src/gallium/state_trackers/dri/dri_drawable.c |4 +- > src/gallium/state_trackers/dri/dri_screen.c | 38 ++ > src/gallium/state_trackers/egl/egl_tracker.c | 26 + > src/gallium/winsys/egl_xlib/egl_xlib.c| 54 +++- > src/glx/x11/dri_common.c |7 +++ > src/glx/x11/glxclient.h |7 +++ > src/glx/x11/glxcmds.c | 69 > + > src/glx/x11/glxcurrent.c | 13 +++-- > src/glx
[Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
This patch adds two extensions, EGL_MESA_gallium and GLX_MESA_gallium, which allow an application to directly access the Gallium3D API bypassing OpenGL and using EGL or GLX for general setup. The python state tracker already uses the GLX_MESA_gallium functions (due to a commit by Jose Fonseca), but the functions are not actually implemented. There is already a WGL extension with wglGetGalliumScreenMESA and wglCreateGalliumContextMESA. A wglGetGalliumSurfacesMESA function should probably be added to match the EGL/GLX versions in this patch. It adds 3 functions: (egl|glx)GetGalliumScreenMESA: returns a pipe_screen for an X11 display/screen or an EGL display (egl|glx)CreateGalliumContextMESA: creates a pipe_context for an X11 display/screen or an EGL display (egl|glx)GetGalliumSurfacesMESA: returns all pipe_surface attachments for an X11 drawable or EGL surface The array returned by GetGalliumSurfacesMESA must be freed by the application. They are implemented for egl_glx, and the EGL and GLX DRI loaders and drivers. The egl_glx implementation simply wraps the GLX functions. The first two functions are trivially implemented, while GetGalliumSurfaces is trickier. The problem is that the current code assumes that a GL context is bound when getting surfaces, so most of the invasive changes in this patch remove this assumption. Currently, this only works for double buffered DRI surfaces, because the flush_framebuffer functions provided by DRI get the surface to flush from the current GL context. How to fix this is not obvious. An option could be to provide an (egl|glx)FlushFrontbuffer function with takes a drawable as input. Another option would be to change (egl|glx)SwapBuffers to do frontbuffer flushing without a GL context (it currently does that indirectly by calling glFlush()). Also currently surfaces are extracted from an st_framebuffer, which is not ideal as it keeps a dependency on the Mesa state tracker The patch assumes that my previous MESA_screen_surface patch has been applied. The patches are independent, but they textually conflict on the function tables. A GL_MESA_gallium extension could be implemented in the future for access to the underlying Gallium objects of OpenGL textures, buffers and renderbuffers. Some way to access the GLSL compiler without OpenGL would also be useful. --- include/EGL/eglext.h | 20 +++ include/GL/glxext.h | 20 +++ include/GL/internal/dri_interface.h | 19 +++ src/egl/drivers/glx/egl_glx.c | 28 ++ src/egl/main/eglapi.c | 40 ++- src/egl/main/eglapi.h | 11 src/egl/main/egldisplay.h |1 + src/egl/main/eglmisc.c|6 ++- src/gallium/state_trackers/dri/dri_drawable.c |4 +- src/gallium/state_trackers/dri/dri_screen.c | 38 ++ src/gallium/state_trackers/egl/egl_tracker.c | 26 + src/gallium/winsys/egl_xlib/egl_xlib.c| 54 +++- src/glx/x11/dri_common.c |7 +++ src/glx/x11/glxclient.h |7 +++ src/glx/x11/glxcmds.c | 69 + src/glx/x11/glxcurrent.c | 13 +++-- src/glx/x11/glxextensions.c |1 + src/glx/x11/glxextensions.h |1 + src/mesa/state_tracker/st_cb_fbo.c| 26 ++ src/mesa/state_tracker/st_cb_fbo.h|4 ++ src/mesa/state_tracker/st_framebuffer.c | 51 ++ src/mesa/state_tracker/st_public.h|8 +++- 22 files changed, 409 insertions(+), 45 deletions(-) diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index b65f7f2..1b94784 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -179,6 +179,26 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLCOPYCONTEXTMESA) (EGLDisplay dpy, EGLCont #endif /* EGL_MESA_copy_context */ +/* EGL_MESA_gallium >>> PRELIMINARY <<< */ +#ifndef EGL_MESA_gallium +#define EGL_MESA_gallium 1 + +struct pipe_screen; +struct pipe_context; +struct pipe_surface; + +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI struct pipe_screen* EGLAPIENTRY eglGetGalliumScreenMESA(EGLDisplay dpy); +EGLAPI struct pipe_context* EGLAPIENTRY eglCreateGalliumContextMESA(EGLDisplay dpy); +EGLAPI int EGLAPIENTRY eglGetGalliumSurfacesMESA(EGLDisplay* dpy, EGLSurface surface, struct pipe_surface*** surfaces); +#endif /* EGL_EGLEXT_PROTOTYPES */ + +typedef struct pipe_screen* (EGLAPIENTRYP PFNEGLGETGALLIUMSCREENMESA)(EGLDisplay dpy); +typedef struct pipe_context* (EGLAPIENTRYP PFNEGLCREATEGALLIUMCONTEXTMESA)(EGLDisplay dpy); +typedef int (EGLAPIENTRYP PFNEGLGETGALLIUMSURFACESMESA)(EGLDisplay* dpy, EGLSurface surface, struct pipe_surface*** surfaces); + +#endif /* EGL_MESA_gallium */ + #ifdef __cplusplus } #endif diff --git a/include/GL/glxext.h b/include
