>> 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 ca
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
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 spe
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
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
> 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
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
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 expor
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
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 wh
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 s
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 artif
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
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 Gall
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 use
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 driver
> 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.
N
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/d
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), bu
19 matches
Mail list logo
