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
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
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
On Tue, Jan 12, 2010 at 5:06 AM, José Fonseca jfons...@vmware.com 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
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
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
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
On Tue, Jan 12, 2010 at 12:39 PM, Luca Barbieri l...@luca-barbieri.com 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,
On Mon, Jan 4, 2010 at 2:24 AM, Luca Barbieri l...@luca-barbieri.com 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
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
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
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
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
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
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
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
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.
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
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),
19 matches
Mail list logo
