Re: [Mesa-dev] [PATCH mesa] configure: install KHR/khrplatform.h when needed
On 08/07/2018 07:58 AM, Eric Engestrom wrote: > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511 > Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)" [snip] > AM_CONDITIONAL(NEED_KHRPLATFORM, test "x$enable_egl" = xyes -o \ > + "x$enable_opengl" = xyes -o \ That fixes issue 107511, thanks! -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa commit 183c6060 regresses VTK LIC tests
On 12/18/2015 11:32 AM, Brad King wrote: > Prior to this change the test renders what we expect. After the > change the test renders *nothing* on top of the background. Ugh, nevermind, sorry for the noise. It turns out this was a branch-on-uninitialized-value bug in VTK that happened to trigger differently due to the change in the mesa commit. I'll report this on the VTK side. -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] mesa commit 183c6060 regresses VTK LIC tests
Hi Folks, I run nightly testing of VTK with nightly 'master' of mesa. For the last few days some tests have been failing. According to `git bisect`, mesa commit 183c606066b1b260acb189e46a40cb71e63b44aa (glsl: simplify interface matching, 2015-12-02) introduced the regression. For example, see the SurfaceLICCurvedDefaultsColor test failure: https://open.cdash.org/testDetails.php?test=402737867&build=4150508 Prior to this change the test renders what we expect. After the change the test renders *nothing* on top of the background. See attached before and after images (one converted .jpg to reduce size). Please let me know what more information is needed to fix this. I can provide a test binary or try patches if needed. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor GL_LIB for gallium libgl-xlib
On 05/10/2014 08:37 AM, Emil Velikov wrote: > Reviewed-by: Emil Velikov > FWIW unless someone has further feedback I'll push this ~mid of the upcoming > week. Excellent, thanks! -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] automake: Honor GL_LIB for gallium libgl-xlib
Use "@GL_LIB@" in src/gallium/targets/libgl-xlib/Makefile.am to produce the library name specified by the configure --with-gl-lib-name option. --- src/gallium/targets/libgl-xlib/Makefile.am | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/gallium/targets/libgl-xlib/Makefile.am b/src/gallium/targets/libgl-xlib/Makefile.am index 4ee364e..7651333 100644 --- a/src/gallium/targets/libgl-xlib/Makefile.am +++ b/src/gallium/targets/libgl-xlib/Makefile.am @@ -40,17 +40,17 @@ AM_CPPFLAGS = \ -DGALLIUM_GALAHAD AM_CFLAGS = $(X11_INCLUDES) -lib_LTLIBRARIES = libGL.la +lib_LTLIBRARIES = lib@GL_LIB@.la -nodist_EXTRA_libGL_la_SOURCES = dummy.cpp -libGL_la_SOURCES = xlib.c -libGL_la_LDFLAGS = \ +nodist_EXTRA_lib@GL_LIB@_la_SOURCES = dummy.cpp +lib@GL_LIB@_la_SOURCES = xlib.c +lib@GL_LIB@_la_LDFLAGS = \ -no-undefined \ -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_TINY) \ $(GC_SECTIONS) \ $(LD_NO_UNDEFINED) -libGL_la_LIBADD = \ +lib@GL_LIB@_la_LIBADD = \ $(top_builddir)/src/gallium/state_trackers/glx/xlib/libxlib.la \ $(top_builddir)/src/gallium/winsys/sw/xlib/libws_xlib.la \ $(top_builddir)/src/gallium/drivers/softpipe/libsoftpipe.la \ @@ -64,9 +64,9 @@ libGL_la_LIBADD = \ $(CLOCK_LIB) if HAVE_MESA_LLVM -libGL_la_LIBADD += $(top_builddir)/src/gallium/drivers/llvmpipe/libllvmpipe.la $(LLVM_LIBS) +lib@GL_LIB@_la_LIBADD += $(top_builddir)/src/gallium/drivers/llvmpipe/libllvmpipe.la $(LLVM_LIBS) AM_CPPFLAGS += -DGALLIUM_LLVMPIPE -libGL_la_LDFLAGS += $(LLVM_LDFLAGS) +lib@GL_LIB@_la_LDFLAGS += $(LLVM_LDFLAGS) endif include $(top_srcdir)/install-gallium-links.mk -- 1.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] classic dri driver cleanup broke --disable-dri
Hi Folks, Since commit ee55500c (configure: cleanup classic dri drivers handling, 2014-02-04) when I build from source using $ ./autogen.sh --disable-dri it fails with this error message: configure: error: classic DRI driver 'yes' does not exist I'm not sure whether it is related but I also get a lot of warnings from automake of the form: .../Makefile.am:#: warning: source file '...' is in a subdirectory, .../Makefile.am:#: but option 'subdir-objects' is disabled I'm using autoconf 2.69 and automake 1.14.1. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2] automake: Honor GL_LIB for mangled/custom lib names
On 07/24/2012 01:37 AM, Dan Nicholson wrote: > Applied as 27382c0f. I had been hoping Eric would pick it up since I'm > not really keeping up with master these days, but the change looked good > enough to me. Thanks! Great, thanks! -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2] automake: Honor GL_LIB for mangled/custom lib names
On 07/16/2012 09:10 AM, Brad King wrote: > Use "@GL_LIB@" in src/mesa/drivers/x11/Makefile.am to configure the > library name. Also use this approach to simplify src/glx/Makefile.am > and drop the HAVE_MANGLED_GL conditional. > > On 07/11/2012 04:05 PM, Dan Nicholson wrote: >> Looks good to me. I wonder if the HAVE_MANGLED_GL conditional can be >> dropped at this point? Anyway, >> >> Reviewed-by: Dan Nicholson > > Additional changes have been made on master which conflict with > the previous patch, so here is another one rebased on 81de0431. > I also dropped the HAVE_MANGLED_GL conditional as it no longer > appears necessary. Please review this patch again when you get a chance. There is no rush, I just don't want it to be forgotten. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCHv2] automake: Honor GL_LIB for mangled/custom lib names
Commit 2d4b77c7 (automake: Convert src/mesa/drivers/x11/Makefile to
automake, 2012-06-12) dropped the old Makefile, which used GL_LIB, and
replaced it with a Makefile.am hard-coding the name "GL". This broke
handling of --enable-mangling and --with-gl-lib-name options which
depend on GL_LIB to specify the GL library name.
Use "@GL_LIB@" in src/mesa/drivers/x11/Makefile.am to configure the
library name. Also use this approach to simplify src/glx/Makefile.am
and drop the HAVE_MANGLED_GL conditional. While at it, fix the
compatibility link we create in "lib" for the software-only driver to
use version GL_MAJOR instead of hard-coding "1".
---
On 07/11/2012 04:05 PM, Dan Nicholson wrote:
> On 7/11/12, Brad King wrote:
>> On 07/11/2012 11:24 AM, Eric Anholt wrote:
>>> For the OSMesa changes, Laurent Carlier used @OSMESA_LIB@, so if you did
>>> this patch using @GL_LIB@, it would at least be consistent with that.
>>
>> Great, thanks! Here is a patch.
>
> Looks good to me. I wonder if the HAVE_MANGLED_GL conditional can be
> dropped at this point? Anyway,
>
> Reviewed-by: Dan Nicholson
Additional changes have been made on master which conflict with
the previous patch, so here is another one rebased on 81de0431.
I also dropped the HAVE_MANGLED_GL conditional as it no longer
appears necessary.
-Brad
configure.ac |1 -
src/glx/Makefile.am | 27 +++
src/mesa/drivers/x11/Makefile.am | 16
3 files changed, 15 insertions(+), 29 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9227474..2fb8f74 100644
--- a/configure.ac
+++ b/configure.ac
@@ -389,7 +389,6 @@ fi
AC_SUBST([GL_LIB])
AC_SUBST([GLU_LIB])
AC_SUBST([OSMESA_LIB])
-AM_CONDITIONAL(HAVE_MANGLED_GL, test "x${enable_mangling}" = "xyes")
dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 6ca85cd..482c4c5 100644
--- a/src/glx/Makefile.am
+++ b/src/glx/Makefile.am
@@ -47,15 +47,7 @@ AM_CFLAGS = \
$(GLPROTO_CFLAGS) \
$(X11_INCLUDES)
-if HAVE_MANGLED_GL
-MANGLED_GL_LIB = libMangledGL.la
-else
-NORMAL_GL_LIB = libGL.la
-endif
-
-lib_LTLIBRARIES = \
- $(NORMAL_GL_LIB) \
- $(MANGLED_GL_LIB)
+lib_LTLIBRARIES = lib@GL_LIB@.la
noinst_LTLIBRARIES = libglx.la
@@ -109,21 +101,16 @@ GL_LDFLAGS = \
-Wl,-Bsymbolic \
-version-number 1:2 -no-undefined
-libGL_la_SOURCES =
-libMangledGL_la_SOURCES =
-libGL_la_LIBADD = $(GL_LIBS)
-libMangledGL_la_LIBADD = $(GL_LIBS)
-libGL_la_LDFLAGS = $(GL_LDFLAGS)
-libMangledGL_la_LDFLAGS = $(GL_LDFLAGS)
+lib@GL_LIB@_la_SOURCES =
+lib@GL_LIB@_la_LIBADD = $(GL_LIBS)
+lib@GL_LIB@_la_LDFLAGS = $(GL_LDFLAGS)
# Provide compatibility with scripts for the old Mesa build system for
# a while by putting a link to the driver into /lib of the build tree.
-if !HAVE_MANGLED_GL
-all-local: $(NORMAL_GL_LIB) $(MANGLED_GL_LIB)
+all-local: lib@GL_LIB@.la
$(MKDIR_P) $(top_builddir)/$(LIB_DIR);
- ln -f .libs/libGL.so.1.2.0 $(top_builddir)/$(LIB_DIR)/libGL.so.1
- ln -sf libGL.so.1 $(top_builddir)/$(LIB_DIR)/libGL.so
-endif
+ ln -f .libs/lib@GL_LIB@.so.1.2.0
$(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so.1
+ ln -sf lib@GL_LIB@.so.1 $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so
$(GLAPI_LIB):
@$(MAKE) -C $(TOP)/src/mapi/glapi
diff --git a/src/mesa/drivers/x11/Makefile.am b/src/mesa/drivers/x11/Makefile.am
index 52febbb..726a9c6 100644
--- a/src/mesa/drivers/x11/Makefile.am
+++ b/src/mesa/drivers/x11/Makefile.am
@@ -33,10 +33,10 @@ AM_CPPFLAGS = \
$(DEFINES)
if HAVE_X11_DRIVER
-lib_LTLIBRARIES = libGL.la
+lib_LTLIBRARIES = lib@GL_LIB@.la
endif
-libGL_la_SOURCES = \
+lib@GL_LIB@_la_SOURCES = \
glxapi.h \
glxheader.h \
xfonts.h \
@@ -55,20 +55,20 @@ GL_MAJOR = 1
GL_MINOR = 6
GL_PATCH = 0
-libGL_la_LIBADD = \
+lib@GL_LIB@_la_LIBADD = \
$(top_builddir)/src/mesa/libmesa.la \
$(top_builddir)/src/mapi/glapi/libglapi.la
-libGL_la_LDFLAGS = \
+lib@GL_LIB@_la_LDFLAGS = \
-version-number $(GL_MAJOR):$(GL_MINOR):$(GL_PATCH) \
$(GL_LIB_DEPS)
if HAVE_SHARED_GLAPI
-libGL_la_LDFLAGS += -L$(top_builddir)/$(LIB_DIR) -l$(GLAPI_LIB)
+lib@GL_LIB@_la_LDFLAGS += -L$(top_builddir)/$(LIB_DIR) -l$(GLAPI_LIB)
endif
# Provide compatibility with scripts for the old Mesa build system for
# a while by putting a link to the driver into /lib of the build tree.
-all-local: libGL.la
+all-local: lib@GL_LIB@.la
$(MKDIR_P) $(top_builddir)/$(LIB_DIR);
- ln -f .libs/libGL.so.$(GL_MAJOR).$(GL_MINOR).$(GL_PATCH)
$(top_builddir)/$(LIB_DIR)/libGL.so.1
- ln -sf libGL.so.1 $(top_builddir)/$(LIB_DIR)/libGL.so
+ ln -f .libs/lib@GL_LIB@.so.$(GL_MAJOR).$(GL_MINOR).$(GL_PATCH)
$(top_builddir)/$(LIB_DIR)/lib@GL_L
[Mesa-dev] [PATCH] automake: Honor GL_LIB for mangled/custom lib names
Commit 2d4b77c7 (automake: Convert src/mesa/drivers/x11/Makefile to automake, 2012-06-12) dropped the old Makefile, which used GL_LIB, and replaced it with a Makefile.am hard-coding the name "GL". This broke handling of --enable-mangling and --with-gl-lib-name options which depend on GL_LIB to specify the GL library name. Use "@GL_LIB@" in src/mesa/drivers/x11/Makefile.am to configure the library name. Also simplify src/glx/Makefile.am using this approach. While at it, fix the compatibility link we create in "lib" for the software-only driver to use version GL_MAJOR instead of hard-coding "1". --- On 07/11/2012 11:24 AM, Eric Anholt wrote: > Brad King writes: >> Upon closer inspection it *does* obviously drop use of GL_LIB. >> Now "libGL" is hard-coded in "Makefile.am". Naive replacement >> like that below is not valid automake code AFAICT. I'm not >> familiar enough with automake to know how to make the library >> name configurable. Does anyone know? > > For the OSMesa changes, Laurent Carlier used @OSMESA_LIB@, so if you did > this patch using @GL_LIB@, it would at least be consistent with that. Great, thanks! Here is a patch. -Brad src/glx/Makefile.am | 25 +++-- src/mesa/drivers/x11/Makefile.am | 16 2 files changed, 15 insertions(+), 26 deletions(-) diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index 37a938d..26a4ca9 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -47,15 +47,7 @@ AM_CFLAGS = \ $(GLPROTO_CFLAGS) \ $(X11_INCLUDES) -if HAVE_MANGLED_GL -MANGLED_GL_LIB = libMangledGL.la -else -NORMAL_GL_LIB = libGL.la -endif - -lib_LTLIBRARIES = \ - $(NORMAL_GL_LIB) \ - $(MANGLED_GL_LIB) +lib_LTLIBRARIES = lib@GL_LIB@.la noinst_LTLIBRARIES = libglx.la @@ -109,20 +101,17 @@ GL_LDFLAGS = \ -Wl,-Bsymbolic \ -version-number 1:2 -no-undefined -libGL_la_SOURCES = -libMangledGL_la_SOURCES = -libGL_la_LIBADD = $(GL_LIBS) -libMangledGL_la_LIBADD = $(GL_LIBS) -libGL_la_LDFLAGS = $(GL_LDFLAGS) -libMangledGL_la_LDFLAGS = $(GL_LDFLAGS) +lib@GL_LIB@_la_SOURCES = +lib@GL_LIB@_la_LIBADD = $(GL_LIBS) +lib@GL_LIB@_la_LDFLAGS = $(GL_LDFLAGS) # Provide compatibility with scripts for the old Mesa build system for # a while by putting a link to the driver into /lib of the build tree. if !HAVE_MANGLED_GL -all-local: $(NORMAL_GL_LIB) $(MANGLED_GL_LIB) +all-local: lib@GL_LIB@.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/libGL.so.1.2.0 $(top_builddir)/$(LIB_DIR)/libGL.so.1 - ln -sf libGL.so.1 $(top_builddir)/$(LIB_DIR)/libGL.so + ln -f .libs/lib@GL_LIB@.so.1.2.0 $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so.1 + ln -sf lib@GL_LIB@.so.1 $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so endif $(GLAPI_LIB): diff --git a/src/mesa/drivers/x11/Makefile.am b/src/mesa/drivers/x11/Makefile.am index cced238..3d7a888 100644 --- a/src/mesa/drivers/x11/Makefile.am +++ b/src/mesa/drivers/x11/Makefile.am @@ -33,10 +33,10 @@ AM_CPPFLAGS = \ $(DEFINES) if HAVE_X11_DRIVER -lib_LTLIBRARIES = libGL.la +lib_LTLIBRARIES = lib@GL_LIB@.la endif -libGL_la_SOURCES = \ +lib@GL_LIB@_la_SOURCES = \ glxapi.h \ glxheader.h \ xfonts.h \ @@ -55,20 +55,20 @@ GL_MAJOR = 1 GL_MINOR = 6 GL_PATCH = 0 -libGL_la_LIBADD = \ +lib@GL_LIB@_la_LIBADD = \ $(top_builddir)/src/mesa/libmesa.a \ $(top_builddir)/src/mapi/glapi/libglapi.a -libGL_la_LDFLAGS = \ +lib@GL_LIB@_la_LDFLAGS = \ -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_PATCH) \ $(GL_LIB_DEPS) if HAVE_SHARED_GLAPI -libGL_la_LDFLAGS += -L$(top_builddir)/$(LIB_DIR) -l$(GLAPI_LIB) +lib@GL_LIB@_la_LDFLAGS += -L$(top_builddir)/$(LIB_DIR) -l$(GLAPI_LIB) endif # Provide compatibility with scripts for the old Mesa build system for # a while by putting a link to the driver into /lib of the build tree. -all-local: libGL.la +all-local: lib@GL_LIB@.la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/libGL.so.$(GL_MAJOR).$(GL_MINOR).$(GL_PATCH) $(top_builddir)/$(LIB_DIR)/libGL.so.1 - ln -sf libGL.so.1 $(top_builddir)/$(LIB_DIR)/libGL.so + ln -f .libs/lib@GL_LIB@.so.$(GL_MAJOR).$(GL_MINOR).$(GL_PATCH) $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so.$(GL_MAJOR) + ln -sf lib@GL_LIB@.so.$(GL_MAJOR) $(top_builddir)/$(LIB_DIR)/lib@GL_LIB@.so -- 1.7.10 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-(gl|glu|osmesa)-lib-name options
On 07/09/2012 04:57 PM, Brad King wrote: > Running "git bisect" points to commit 2d4b77c7 (automake: > Convert src/mesa/drivers/x11/Makefile, 2012-06-12). The change > made by the commit does not obviously drop use of GL_LIB. Upon closer inspection it *does* obviously drop use of GL_LIB. Now "libGL" is hard-coded in "Makefile.am". Naive replacement like that below is not valid automake code AFAICT. I'm not familiar enough with automake to know how to make the library name configurable. Does anyone know? Thanks, -Brad diff --git a/src/mesa/drivers/x11/Makefile.am b/src/mesa/drivers/x11/Makefile.am index cced238..af3fa8f 100644 --- a/src/mesa/drivers/x11/Makefile.am +++ b/src/mesa/drivers/x11/Makefile.am @@ -33,10 +33,10 @@ AM_CPPFLAGS = \ $(DEFINES) if HAVE_X11_DRIVER -lib_LTLIBRARIES = libGL.la +lib_LTLIBRARIES = lib$(GL_LIB).la endif -libGL_la_SOURCES = \ +lib$(GL_LIB)_la_SOURCES = \ glxapi.h \ glxheader.h \ xfonts.h \ @@ -55,20 +55,20 @@ GL_MAJOR = 1 GL_MINOR = 6 GL_PATCH = 0 -libGL_la_LIBADD = \ +lib$(GL_LIB)_la_LIBADD = \ $(top_builddir)/src/mesa/libmesa.a \ $(top_builddir)/src/mapi/glapi/libglapi.a -libGL_la_LDFLAGS = \ +lib$(GL_LIB)_la_LDFLAGS = \ -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_PATCH) \ $(GL_LIB_DEPS) if HAVE_SHARED_GLAPI -libGL_la_LDFLAGS += -L$(top_builddir)/$(LIB_DIR) -l$(GLAPI_LIB) +lib$(GL_LIB)_la_LDFLAGS += -L$(top_builddir)/$(LIB_DIR) -l$(GLAPI_LIB) endif # Provide compatibility with scripts for the old Mesa build system for # a while by putting a link to the driver into /lib of the build tree. -all-local: libGL.la +all-local: lib$(GL_LIB).la $(MKDIR_P) $(top_builddir)/$(LIB_DIR); - ln -f .libs/libGL.so.$(GL_MAJOR).$(GL_MINOR).$(GL_PATCH) $(top_builddir)/$(LIB_DIR)/libGL.so.1 - ln -sf libGL.so.1 $(top_builddir)/$(LIB_DIR)/libGL.so + ln -f .libs/lib$(GL_LIB).so.$(GL_MAJOR).$(GL_MINOR).$(GL_PATCH) $(top_builddir)/$(LIB_DIR)/lib$(GL_LIB).so.1 + ln -sf lib$(GL_LIB).so.1 $(top_builddir)/$(LIB_DIR)/lib$(GL_LIB).so ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-(gl|glu|osmesa)-lib-name options
On 06/11/2012 04:37 PM, Kenneth Graunke wrote: > Oh, sorry! Lost track of this. It looks like Eric's pushed it now. Yes, thanks Eric! However, since then another commit broke the feature. The build always produces "GL" no matter the --with-gl-lib-name given. The GLU and OSMesa options still work. Running "git bisect" points to commit 2d4b77c7 (automake: Convert src/mesa/drivers/x11/Makefile, 2012-06-12). The change made by the commit does not obviously drop use of GL_LIB. Any idea? Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-(gl|glu|osmesa)-lib-name options
On 06/05/2012 02:03 PM, Kenneth Graunke wrote: > On 06/05/2012 10:59 AM, Brad King wrote: >>> ./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU >>> --with-osmesa-lib-name=OSMesa ... >> >> That looks cleaner to me. Here is a patch for it. > > Reviewed-by: Kenneth Graunke > > If there are no objections, I'll push this tomorrow. Thanks! I haven't seen this appear in any origin branch yet. No rush, I just want to make sure it isn't accidentally forgotten. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-(gl|glu|osmesa)-lib-name options
On 06/05/2012 02:03 PM, Kenneth Graunke wrote: >> On 06/05/2012 01:38 PM, Kenneth Graunke wrote: >>> ./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU >>> --with-osmesa-lib-name=OSMesa ... >> >> That looks cleaner to me. Here is a patch for it. > > Reviewed-by: Kenneth Graunke > > If there are no objections, I'll push this tomorrow. Thanks! Great, thanks. If you want it: Signed-off-by: Brad King -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Add --with-(gl|glu|osmesa)-lib-name options
These allow one to mangle the library names, without also mangling the
symbol names, to make them distinct from other GL libraries on the
system.
---
On 06/05/2012 01:38 PM, Kenneth Graunke wrote:
> This looks good to me. The only real question I have is whether it
> makes sense to set them via environment variables, like you did, or
> whether it'd be better to use AC_ARG_WITH and do:
>
> ./autogen.sh --with-gl-lib-name=GL --with-glu-lib-name=GLU
> --with-osmesa-lib-name=OSMesa ...
That looks cleaner to me. Here is a patch for it.
Thanks,
-Brad
configure.ac | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9fb8149..e607d1c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,24 @@ else
LIB_EXTENSION='so' ;;
esac
fi
+AC_ARG_WITH([gl-lib-name],
+ [AS_HELP_STRING([--with-gl-lib-name@<:@=NAME@:>@],
+[specify GL library name @<:@default=GL@:>@])],
+ [GL_LIB=$withval],
+ [GL_LIB=GL])
+AC_ARG_WITH([glu-lib-name],
+ [AS_HELP_STRING([--with-glu-lib-name@<:@=NAME@:>@],
+[specify GLU library name @<:@default=GLU@:>@])],
+ [GLU_LIB=$withval],
+ [GLU_LIB=GLU])
+AC_ARG_WITH([osmesa-lib-name],
+ [AS_HELP_STRING([--with-osmesa-lib-name@<:@=NAME@:>@],
+[specify OSMesa library name @<:@default=OSMesa@:>@])],
+ [OSMESA_LIB=$withval],
+ [OSMESA_LIB=OSMesa])
+AS_IF([test "x$GL_LIB" = xyes], [GL_LIB=GL])
+AS_IF([test "x$GLU_LIB" = xyes], [GLU_LIB=GLU])
+AS_IF([test "x$OSMESA_LIB" = xyes], [OSMESA_LIB=OSMesa])
dnl
dnl Mangled Mesa support
@@ -365,19 +383,16 @@ AC_ARG_ENABLE([mangling],
[enable_mangling="${enableval}"],
[enable_mangling=no]
)
-GL_LIB="GL"
-GLU_LIB="GLU"
-OSMESA_LIB="OSMesa"
if test "x${enable_mangling}" = "xyes" ; then
DEFINES="${DEFINES} -DUSE_MGL_NAMESPACE"
- GL_LIB="MangledGL"
- GLU_LIB="MangledGLU"
- OSMESA_LIB="MangledOSMesa"
+ GL_LIB="Mangled${GL_LIB}"
+ GLU_LIB="Mangled${GLU_LIB}"
+ OSMESA_LIB="Mangled${OSMESA_LIB}"
fi
AC_SUBST([GL_LIB])
AC_SUBST([GLU_LIB])
AC_SUBST([OSMESA_LIB])
-AM_CONDITIONAL(HAVE_MANGLED_GL, test $GL_LIB = MangledGL)
+AM_CONDITIONAL(HAVE_MANGLED_GL, test "x${enable_mangling}" = "xyes")
dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On 06/05/2012 11:12 AM, Dan Nicholson wrote: > Duh, you're right. I think this original patch is good to go. Great, thanks! > a quick grep > shows that there are no remaining hardcoded -lGL around (I think). I've built with a custom configs/current in the old pure-make system that sets GL_LIB for years, so I think $(GL_LIB) is used everywhere unless there is new autotools-specific code that hard-codes -lGL. -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is the pure-make build system still supported?
On 06/04/2012 12:29 PM, Brian Paul wrote: > On 06/01/2012 12:55 PM, Brad King wrote: >> However, I still get the above undefined symbols on x86_64 when >> linking to the resulting GL library. The patch below (also in >> my previous post) solves it. It seems configs/* is still in use >> even by the autotools system. > > Hmmm, I don't quite see how the linux-x86-64 file is getting pulled > in. The files under configs/ will be gone soon. Okay, I can patch it locally until then. However, please consider the main patch I posted in this thread to allow the (GL|GLU|OSMESA)_LIB names to be changed at configuration time with autotools. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On 06/01/2012 05:49 PM, Dan Nicholson wrote:
>> +AC_ARG_VAR([GL_LIB],[name of GL library @<:@default=GL@:>@])
>> +AC_ARG_VAR([GLU_LIB],[name of GLU library @<:@default=GLU@:>@])
>> +AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @<:@default=OSMesa@:>@])
>> +GL_LIB="${GL_LIB-GL}"
>> +GLU_LIB="${GLU_LIB-GLU}"
>> +OSMESA_LIB="${OSMESA_LIB-OSMesa}"
>
> I don't think this part is necessary. AC_ARG_VAR does this already. The rest
> makes sense though.
Thanks for taking a look. I think the init lines are needed in
order to set the default values. With the patch below on top of
this one I get output
GL_LIB=
GLU_LIB=
OSMESA_LIB=
and the build fails. I see no mention in AC_ARG_VAR documentation
about default value selection:
http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Setting-Output-Variables.html#index-AC_005fARG_005fVAR-1134
-Brad
diff --git a/configure.ac b/configure.ac
index 7f6ba96..b4c0a4a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -358,9 +358,9 @@ fi
AC_ARG_VAR([GL_LIB],[name of GL library @<:@default=GL@:>@])
AC_ARG_VAR([GLU_LIB],[name of GLU library @<:@default=GLU@:>@])
AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @<:@default=OSMesa@:>@])
-GL_LIB="${GL_LIB-GL}"
-GLU_LIB="${GLU_LIB-GLU}"
-OSMESA_LIB="${OSMESA_LIB-OSMesa}"
+echo "GL_LIB=[$GL_LIB]"
+echo "GLU_LIB=[$GLU_LIB]"
+echo "OSMESA_LIB=[$OSMESA_LIB]"
dnl
dnl Mangled Mesa support
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
Teach 'configure' to read the default GL_LIB, GLU_LIB, and OSMESA_LIB
values from the environment. This allows one to mangle the library
names (without also mangling the symbol names) to make them distinct
from other GL libraries on the system.
---
On 06/01/2012 10:06 AM, Brian Paul wrote:
> You should transition to using autoconf
One feature I used in the pure-make build system was to create a custom
configs/current to set GL_LIB, GLU_LIB, and OSMESA_LIB to have a "Mesa"
prefix. This helps ensure that VTK both builds and runs against my
nightly Mesa build regardless of what other "GL" libraries appear in
the dynamic loader's search path. With this patch I can run
$ GL_LIB=MesaGL GLU_LIB=MesaGLU OSMESA_LIB=MesaOSMesa ./autogen.sh ...
to build with custom library names. Please review.
Thanks,
-Brad
configure.ac | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9fb8149..7f6ba96 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,12 @@ else
LIB_EXTENSION='so' ;;
esac
fi
+AC_ARG_VAR([GL_LIB],[name of GL library @<:@default=GL@:>@])
+AC_ARG_VAR([GLU_LIB],[name of GLU library @<:@default=GLU@:>@])
+AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @<:@default=OSMesa@:>@])
+GL_LIB="${GL_LIB-GL}"
+GLU_LIB="${GLU_LIB-GLU}"
+OSMESA_LIB="${OSMESA_LIB-OSMesa}"
dnl
dnl Mangled Mesa support
@@ -365,19 +371,16 @@ AC_ARG_ENABLE([mangling],
[enable_mangling="${enableval}"],
[enable_mangling=no]
)
-GL_LIB="GL"
-GLU_LIB="GLU"
-OSMESA_LIB="OSMesa"
if test "x${enable_mangling}" = "xyes" ; then
DEFINES="${DEFINES} -DUSE_MGL_NAMESPACE"
- GL_LIB="MangledGL"
- GLU_LIB="MangledGLU"
- OSMESA_LIB="MangledOSMesa"
+ GL_LIB="Mangled${GL_LIB}"
+ GLU_LIB="Mangled${GLU_LIB}"
+ OSMESA_LIB="Mangled${OSMESA_LIB}"
fi
AC_SUBST([GL_LIB])
AC_SUBST([GLU_LIB])
AC_SUBST([OSMESA_LIB])
-AM_CONDITIONAL(HAVE_MANGLED_GL, test $GL_LIB = MangledGL)
+AM_CONDITIONAL(HAVE_MANGLED_GL, test "x${enable_mangling}" = "xyes")
dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
--
1.7.10
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is the pure-make build system still supported?
On 06/01/2012 10:06 AM, Brian Paul wrote: > On 06/01/2012 07:32 AM, Brad King wrote: >> undefined reference to `_mesa_x86_64_transform_points4_3d' >> undefined reference to `_mesa_3dnow_transform_points4_perspective' >> undefined reference to `_mesa_x86_64_transform_points4_identity' >> undefined reference to `_mesa_x86_64_transform_points4_general' >> undefined reference to `_mesa_3dnow_transform_points4_2d' >> undefined reference to `_mesa_x86_64_cpuid' >> undefined reference to `_mesa_3dnow_transform_points4_2d_no_rot' >> undefined reference to `_mesa_3dnow_transform_points4_3d_no_rot' >> > The old makefile system is going away. Okay, thanks for confirming. I'll switch to autotools. > ./autogen.sh --disable-dri --enable-xlib-glx --enable-osmesa Thanks, that got me started. I ended up using ./autogen.sh --disable-dri --disable-egl --enable-xlib-glx \ --enable-osmesa --without-gallium-drivers However, I still get the above undefined symbols on x86_64 when linking to the resulting GL library. The patch below (also in my previous post) solves it. It seems configs/* is still in use even by the autotools system. -Brad diff --git a/configs/linux-x86-64 b/configs/linux-x86-64 index c2441e0..81bb36b 100644 --- a/configs/linux-x86-64 +++ b/configs/linux-x86-64 @@ -6,7 +6,7 @@ CONFIG_NAME = linux-x86-64 ARCH_FLAGS = -m64 -MESA_ASM_SOURCES = $(X86-64_SOURCES) +MESA_ASM_FILES = $(X86_64_FILES) GLAPI_ASM_SOURCES = $(X86-64_API) ASM_FLAGS = -DUSE_X86_64_ASM ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Is the pure-make build system still supported?
Hi Folks, Since commit 0ce0f7c0 (mesa: Remove the generated glapi from source control, and just build it, 2012-05-15) I get this: $ make linux-x86-64 ... make[3]: Entering directory `.../src/mapi/glapi' make[3]: *** No rule to make target `depend', needed by `default'. Stop. make[3]: Leaving directory `.../src/mapi/glapi' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `.../src' make[1]: *** [default] Error 1 make[1]: Leaving directory `...' It's easily addressed by the first patch below, but the build later fails with make[5]: Entering directory `.../src/gallium/auxiliary/pipe-loader' make[5]: *** No rule to make target `default'. Stop. make[5]: Leaving directory `.../src/gallium/auxiliary/pipe-loader' All I really need is GL and GLU so after applying the patch I can build using the command $ bin/extract_git_sha1 && ln -s linux-x86-64 configs/current && (cd src/glsl && make default) && (cd src/mapi/glapi/gen && make all) && (cd src/mapi/glapi && make default) && (cd src/mesa && make default) && (cd src/glu/sgi && make default) && true However, later commit 7d7fe1b0 (automake: Rename variables in sources.mak to be automake compatible, 2012-05-16) renamed many Makefile variables but did not update configs/* accordingly. The result drops config-specific sources from pure-make builds. For example on x86_64 when linking to Mesa GL I get: undefined reference to `_mesa_x86_64_transform_points4_3d' undefined reference to `_mesa_3dnow_transform_points4_perspective' undefined reference to `_mesa_x86_64_transform_points4_identity' undefined reference to `_mesa_x86_64_transform_points4_general' undefined reference to `_mesa_3dnow_transform_points4_2d' undefined reference to `_mesa_x86_64_cpuid' undefined reference to `_mesa_3dnow_transform_points4_2d_no_rot' undefined reference to `_mesa_3dnow_transform_points4_3d_no_rot' The second patch below fixes this particular issue but there are probably many more cases. FYI, the reason I use the pure-make build with the above command sequence is to achieve a minimal build of just GL and GLU. I use it to run a nightly build of Mesa so I can run the VTK test suite against it to catch any Mesa regressions VTK exposes. Occasionally Mesa fails to build in sources unrelated to GL and GLU which then prevents that version from being tested, so I want to build only the minimal part needed. Thanks, -Brad diff --git a/configs/default b/configs/default index 40fa5e3..ca9ac71 100644 --- a/configs/default +++ b/configs/default @@ -99,7 +99,7 @@ MOTIF_CFLAGS = -I/usr/include/Motif1.2 # Directories to build LIB_DIR = lib -SRC_DIRS = glsl mapi/glapi mapi/vgapi mesa \ +SRC_DIRS = glsl mapi/glapi/gen mapi/glapi mapi/vgapi mesa \ gallium egl gallium/winsys gallium/targets glu GLU_DIRS = sgi DRIVER_DIRS = x11 osmesa diff --git a/configs/linux-x86-64 b/configs/linux-x86-64 index c2441e0..81bb36b 100644 --- a/configs/linux-x86-64 +++ b/configs/linux-x86-64 @@ -6,7 +6,7 @@ CONFIG_NAME = linux-x86-64 ARCH_FLAGS = -m64 -MESA_ASM_SOURCES = $(X86-64_SOURCES) +MESA_ASM_FILES = $(X86_64_FILES) GLAPI_ASM_SOURCES = $(X86-64_API) ASM_FLAGS = -DUSE_X86_64_ASM ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Text rendering partly broken by commit f9874fee
Hi Brian, Recently VTK's TestPieChartActor and similar tests started to fail on our test machines that use nightly Mesa. For example, one that I run: http://www.cdash.org/CDash/testDetails.php?test=133410913&build=1960175 and one that Kevin Hobbs runs: http://www.cdash.org/CDash/testDetails.php?test=133403016&build=1960419 Some text comes out rendered as blocks, but not all. I think it may be the background color or transparency that is incorrect, as seen in the TestScalarBar result: http://www.cdash.org/CDash/testDetails.php?test=133403366&build=1960418 Git bisect reports http://cgit.freedesktop.org/mesa/mesa/commit/?id=f9874fee as the cause. I'm not sure exactly what day this commit became reachable in upstream master but I think the problem went unnoticed for a few days because it was obscured by some shared-glapi problems already discussed in other threads here. Please let me know if you need any other information. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa draw-instance topic v. point-only rendering in VTK tests
On 01/17/2011 11:46 AM, Brian Paul wrote:
> Does the attached patch help?
Yes, that fixes it. The assertion no longer fails and the test passes.
Total resulting patch on top of ef3b8042 appears below.
Thanks,
-Brad
diff --git a/src/mesa/tnl/t_draw.c b/src/mesa/tnl/t_draw.c
index bdb893e..616ee88 100644
--- a/src/mesa/tnl/t_draw.c
+++ b/src/mesa/tnl/t_draw.c
@@ -471,6 +471,7 @@ void _tnl_draw_prims( struct gl_context *ctx,
/* Binding inputs may imply mapping some vertex buffer objects.
* They will need to be unmapped below.
*/
+assert(prim[i].num_instances > 0);
for (inst = 0; inst < prim[i].num_instances; inst++) {
bind_prims(ctx, &prim[i], this_nr_prims);
diff --git a/src/mesa/vbo/vbo_split_inplace.c b/src/mesa/vbo/vbo_split_inplace.c
index 789cf31..fd5044f 100644
--- a/src/mesa/vbo/vbo_split_inplace.c
+++ b/src/mesa/vbo/vbo_split_inplace.c
@@ -178,6 +178,7 @@ static void split_prims( struct split_context *split)
outprim->end = (nr == remaining && prim->end);
outprim->start = prim->start + j;
outprim->count = nr;
+outprim->num_instances = prim->num_instances;
update_index_bounds(split, outprim);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa draw-instance topic v. point-only rendering in VTK tests
On 01/17/2011 11:18 AM, Brian Paul wrote:
> On Mon, Jan 17, 2011 at 8:58 AM, Brad King wrote:
>> I think a63486ac is the first commit that exhibits the behavior.
>
> Have you tried reversing that change?
I started at ef3b8042 and ran "git revert a63486ac". I resolved one
conflict (machine v. &machine) and compiled. The issue disappeared.
> Perhaps prim[i].num_instances is zero. Could you try debugging that?
> Maybe add an assertion that prim[i].num_instances > 0 then check the
> stack trace if it fails.
I started at ef3b8042 and added the assertion as shown below [1]. I get:
vtk: tnl/t_draw.c:474: _tnl_draw_prims: Assertion `prim[i].num_instances > 0'
failed.
Using gdb I get the backtrace below [2].
Thanks,
-Brad
[1] assert:
diff --git a/src/mesa/tnl/t_draw.c b/src/mesa/tnl/t_draw.c
index bdb893e..616ee88 100644
--- a/src/mesa/tnl/t_draw.c
+++ b/src/mesa/tnl/t_draw.c
@@ -471,6 +471,7 @@ void _tnl_draw_prims( struct gl_context *ctx,
/* Binding inputs may imply mapping some vertex buffer objects.
* They will need to be unmapped below.
*/
+assert(prim[i].num_instances > 0);
for (inst = 0; inst < prim[i].num_instances; inst++) {
bind_prims(ctx, &prim[i], this_nr_prims);
[2] backtrace:
#0 0x7fffed636165 in *__GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x7fffed638f70 in *__GI_abort () at abort.c:92
#2 0x7fffed62f2b1 in *__GI___assert_fail (assertion=0x7fffec3fcbf5
"prim[i].num_instances > 0", file=, line=474,
function=0x7fffec3fcca0 "_tnl_draw_prims") at assert.c:81
#3 0x7fffec2833dc in _tnl_draw_prims (ctx=,
arrays=, prim=0x0, nr_prims=,
ib=, min_index=0, max_index=2999) at tnl/t_draw.c:474
#4 0x7fffec2834b6 in _tnl_vbo_draw_prims (ctx=0x9ebbf0, arrays=0xa400d8,
prim=0x7fffb7d4, nr_prims=1, ib=0x0, index_bounds_valid=,
min_index=0, max_index=2999) at tnl/t_draw.c:384
#5 0x7fffec39fb6b in flush_vertex (ctx=,
arrays=, prim=, nr_prims=,
ib=, min_index=, max_index=5460,
draw=0x7fffec283450 <_tnl_vbo_draw_prims>, limits=0x7fffbbe0)
at vbo/vbo_split_inplace.c:85
#6 split_prims (ctx=, arrays=,
prim=, nr_prims=, ib=,
min_index=, max_index=5460, draw=0x7fffec283450
<_tnl_vbo_draw_prims>, limits=0x7fffbbe0) at vbo/vbo_split_inplace.c:193
#7 vbo_split_inplace (ctx=, arrays=,
prim=, nr_prims=,
ib=, min_index=, max_index=5460,
draw=0x7fffec283450 <_tnl_vbo_draw_prims>, limits=0x7fffbbe0)
at vbo/vbo_split_inplace.c:280
#8 0x7fffec283215 in _tnl_draw_prims (ctx=,
arrays=, prim=, nr_prims=,
ib=, min_index=0, max_index=5460) at tnl/t_draw.c:445
#9 0x7fffec2834b6 in _tnl_vbo_draw_prims (ctx=0x9ebbf0, arrays=0xa400d8,
prim=0xa3e6f4, nr_prims=1, ib=0x0, index_bounds_valid=,
min_index=0, max_index=5460) at tnl/t_draw.c:384
#10 0x7fffec270a8e in vbo_exec_vtx_flush (exec=0xa3e410, unmap=0 '\000') at
vbo/vbo_exec_draw.c:382
#11 0x7fffec2642a2 in vbo_exec_wrap_buffers (exec=0xa3e410) at
vbo/vbo_exec_api.c:88
#12 vbo_exec_vtx_wrap (exec=0xa3e410) at vbo/vbo_exec_api.c:123
#13 0x71099be6 in [VTK]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] mesa draw-instance topic v. point-only rendering in VTK tests
Hi Brian, One of your changes in commit range 21001d2b..652901e9 causes one of the VTK tests to render an empty image: http://www.cdash.org/CDash/testDetails.php?test=79911707&build=826979 I think a63486ac is the first commit that exhibits the behavior. This particular test renders only *points* with no other geometry. Tests that render lines and polys do not fail. Please take a look when you can and let me know if you need more information. Thanks, -Brad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
