Re: [Mesa3d-dev] Mesa (master): fix overflow

2010-01-04 Thread Alan Hourihane 
On Mon, 2010-01-04 at 10:51 -0700, Brian Paul wrote:
 Alan Hourihane wrote:
  Module: Mesa
  Branch: master
  Commit: 1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
  URL:
  http://cgit.freedesktop.org/mesa/mesa/commit/?id=1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
  
  Author: Alan Hourihane al...@vmware.com
  Date:   Mon Jan  4 17:41:49 2010 +
  
  fix overflow
  
  ---
  
   src/mesa/main/enums.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
  diff --git a/src/mesa/main/enums.c b/src/mesa/main/enums.c
  index 85197af..73d6e6a 100644
  --- a/src/mesa/main/enums.c
  +++ b/src/mesa/main/enums.c
  @@ -3680,7 +3680,7 @@ static const enum_elt all_enums[1885] =
  { 37780, 0x2802 }, /* GL_TEXTURE_WRAP_S */
  { 37798, 0x2803 }, /* GL_TEXTURE_WRAP_T */
  { 37816, 0x911B }, /* GL_TIMEOUT_EXPIRED */
  -   { 37835, 0x }, /* GL_TIMEOUT_IGNORED */
  +   { 37835, 0x }, /* GL_TIMEOUT_IGNORED */
  { 37854, 0x88BF }, /* GL_TIME_ELAPSED_EXT */
  { 37874, 0x8648 }, /* GL_TRACK_MATRIX_NV */
  { 37893, 0x8649 }, /* GL_TRACK_MATRIX_TRANSFORM_NV */
 
 Alan, the enums.c file is generated with python code in 
 src/mesa/glapi/ so this change will get clobbered.
 
 The root problem is GL_TIMEOUT_IGNORED isn't really a GLenum but a 
 special GLuint64 value.  We should probably just remove it from the 
 ARB_sync.xml file.
 
 I could do that later today.

Sounds good, I'll let you take care of it.

Thanks,

Alan.


--
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] mesa with llvm?

2009-03-09 Thread Alan Hourihane 
On Mon, 2009-03-09 at 16:12 +0530, Kamalneet Singh wrote:
 Hi,
 
 I got link errors while building gallium-mesa-7.4 branch with make
 linux-llvm. The attached patch fixes it.
 
 But I wonder which is the right branch for running mesa with llvm,
 preferably with softpipe. Can someone please tell that.. :)

It's probably best to do LLVM work with master.

Alan.


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] EGL in Mesa

2008-10-06 Thread Alan Hourihane 
On Mon, 2008-10-06 at 16:34 -0400, Kristian Høgsberg wrote:
 On Mon, Oct 6, 2008 at 1:09 PM, Brian Paul
 [EMAIL PROTECTED] wrote:
  KwangYul Seo wrote:
  Hi,
 
  I want to know the current status of EGL in Mesa. Mesa in the git
  repository seems to have src/egl, but I can't find it in the stable
  releases of Mesa. Is this EGL implementation usable?
 
  Software rendering should work on the gallium-0.1/2 branches.  Hardware
  rendering may or may not work.  It's in flux.  That's why it's not
  included in the Mesa releases yet.
 
 I'm jumping the gun here, but I've been working on an EGL
 implementation that works with the new standard DRI interface.  It
 only works with intel dri driver and requires gem and modesetting, but
 I've got EGL gears running at this point:

I've also committed an EGL interface that just sits on top of GLX for
X11 implementations.

It's on the gallium-0.2 branch in src/egl/drivers/glx.

Alan.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (mesa_7_0_branch) fails to build

2008-03-27 Thread Alan Hourihane 
On Thu, 2008-03-27 at 17:18 +0100, Julien Cristau wrote:
 On Thu, Mar 27, 2008 at 17:02:27 +0100, Jens Stroebel wrote:
 
  Hello all :)
  
  While trying to track the mesa_7_0_branch of mesa, I noticed my build 
  failing with:
  
  
  gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main 
  -I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl 
  -I../../src/mesa/shader -I../../src/mesa/shader/grammar 
  -I../../src/mesa/shader/slang -I../../src/mesa/swrast 
  -I../../src/mesa/swrast_setup -Wall -Wmissing-prototypes -std=c99 
  -ffast-math -O -g -I/opt/Xorg/include -fPIC -m32 -D_POSIX_SOURCE 
  -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE 
  -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER 
  -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS 
  -DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM 
  -DUSE_SSE_ASM -fno-strict-aliasing tnl/t_vertex_sse.c -o tnl/t_vertex_sse.o
  tnl/t_vertex_sse.c: In function '_tnl_generate_sse_emit':
  tnl/t_vertex_sse.c:656: error: too many arguments to function 
  'x86_init_func'
  tnl/t_vertex_sse.c:656: error: wrong type argument to unary exclamation mark
  make[4]: *** [tnl/t_vertex_sse.o] Error 1
  make[4]: Leaving directory `/usr/src/rpm/BUILD/Mesa-7.0.3rc2h/src/mesa'
  
  
  Has anybody built mesa (mesa_7_0_branch) on linux successfully or is 
  this really a temporary glitch in the branch?
  
 It looks like f93882512e54402a7b5199208648be4f60015597 changed the
 prototype of x86_init_func without updating its caller.  CCing Alan and
 the mesa list.

Ooops. Sorry about that. My build tree was a little messed up and didn't
notice the breakage. I've re-checked out, and re-built and just
committed fixes.

Alan.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa (mesa_7_0_branch) fails to build

2008-03-27 Thread Alan Hourihane 
On Thu, 2008-03-27 at 17:18 +0100, Julien Cristau wrote:
 On Thu, Mar 27, 2008 at 17:02:27 +0100, Jens Stroebel wrote:
 
  Hello all :)
  
  While trying to track the mesa_7_0_branch of mesa, I noticed my build 
  failing with:
  
  
  gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main 
  -I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl 
  -I../../src/mesa/shader -I../../src/mesa/shader/grammar 
  -I../../src/mesa/shader/slang -I../../src/mesa/swrast 
  -I../../src/mesa/swrast_setup -Wall -Wmissing-prototypes -std=c99 
  -ffast-math -O -g -I/opt/Xorg/include -fPIC -m32 -D_POSIX_SOURCE 
  -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE 
  -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER 
  -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS 
  -DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM 
  -DUSE_SSE_ASM -fno-strict-aliasing tnl/t_vertex_sse.c -o tnl/t_vertex_sse.o
  tnl/t_vertex_sse.c: In function '_tnl_generate_sse_emit':
  tnl/t_vertex_sse.c:656: error: too many arguments to function 
  'x86_init_func'
  tnl/t_vertex_sse.c:656: error: wrong type argument to unary exclamation mark
  make[4]: *** [tnl/t_vertex_sse.o] Error 1
  make[4]: Leaving directory `/usr/src/rpm/BUILD/Mesa-7.0.3rc2h/src/mesa'
  
  
  Has anybody built mesa (mesa_7_0_branch) on linux successfully or is 
  this really a temporary glitch in the branch?
  
 It looks like f93882512e54402a7b5199208648be4f60015597 changed the
 prototype of x86_init_func without updating its caller.  CCing Alan and
 the mesa list.

Ooops. Sorry about that. My build tree was a little messed up and didn't
notice the breakage. I've re-checked out, and re-built and just
committed fixes.

Alan.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)

2007-09-26 Thread Alan Hourihane 
On Wed, 2007-09-26 at 14:15 -0400, Kristian Høgsberg wrote:
 On 9/20/07, José Fonseca [EMAIL PROTECTED] wrote:
  On 9/19/07, Gabor Gombas [EMAIL PROTECTED] wrote:
   On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote:
However, when loaded, references to __glXFreeContext *inside*
libglxgext.so are linked to the external __glXFreeContext in libGL.so:
  
   If you have multiple definitions for a symbol it is completely random
   which a given reference will resolve to.
  
   Now, the two underscores are a good hint that these are internal symbols
   and they should not be exported at all or if they have to, one of them
   must be renamed.
  
libtool's -export-dynamic flag is not being used. Using libtool's 
-module
flag doesn't change anything.
  
   Does this symbol have to be exported? If no, you should use libtool's
   --export-symbol feature to explicitely declare which symbols should be
   visible and which should not. In fact, it is always wise to use
   --export-symbol when creating shared libraries to prevent ABI breakage
   by accidentally exporting private symbols.
  
   If __glXFreeContext should be exported, then it should be decided which
   library owns this symbol, and the other must be modified not to export
   it.
  
   If it is the case that libGL.so exports __glXFreeContext but
   libglxgext.so wants to locally override it, and for some reason you
   absolutely cannot rename it, then you must use gcc's
   __visibility__((__protected__)) attribute when declaring __glXFreeContext
   in libglgxext.so, but that is not portable to non-ELF platforms and
   other compilers and also has run-time performance costs IIRC.
 
  I agree in principle with your suggestions. But I'm not entitled to
  decide if __glX* symbols
  should or not  be exported, nor to say what's the best way to accomplish it.
 
  I know that __glX* functions came originally from SGI code. From there
  derived copies appear on mesa (for libGL), and more than once in
  xserver code -- I suppose always for indirect rendering purposes (in
  places such as AIGLX, DMX, and Xgl). It is likely that other vendors
  also ship libGL exporting those symbols.
 
  But it would definitely make things simpler and less likely to break
  if the __glX* symbols were not exported...
 
 Ok, big disclaimer here: I haven't looked into glucose or even glitz
 much, so what I'm suggesting here may not apply.  But my take is that
 we shouldn't be loading libGL in the X server to begin with.  If we
 want to use opengl in the X server we should call into the dispatch
 table directly (as for example the __glXDRIbindTexImage implementation
 in GL/glx/glxdri.c:
 
 CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap-target == GL_TEXTURE_2D ?
   GL_TEXTURE_BINDING_2D :
   GL_TEXTURE_BINDING_RECTANGLE_NV,
   texname));
 
 and we may have to export some of the GLX code for use inside the X
 server (creating glx drawables and contexts etc) and separate out the
 protocol stuff.  Basically if we have to hack around linking issues
 and fudge symbol resolution issues we're doing something wrong.

glucose is already doing what you say above Kristian, it's definitely
not loading libGL.

Remember Xgl is an OpenGL client, and that's where the problems are
caused. Nothing to do with glucose here.

Alan.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Mesa 6.5.3 release candidate 2

2007-04-22 Thread Alan Hourihane 
On Sun, 2007-04-22 at 09:05 -0600, Brian Paul wrote:
 On 4/22/07, Michel Dänzer [EMAIL PROTECTED] wrote:
  On Sat, 2007-04-21 at 16:06 -0600, Brian Paul wrote:
   I've uploaded a second release candidate:  http://www.mesa3d.org/beta/
 
  I think it would be useful in general, but in particular for packagers,
  if there was a GIT tag corresponding to each RC.
 
 I did a 'git-tag -a mesa_6_5_3_rc2' which seemed to work.  But how do
 I push that to master?  git-push didn't do anything.

git-push --tags

should do the trick

Alan.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [RFC] Attempt to fix the need to LD_PRELOAD libGL

2006-07-23 Thread Alan Hourihane 
On Sun, 2006-07-23 at 13:31 +0200, Michel Dänzer wrote:
 On Sat, 2006-07-22 at 18:52 +0100, Alan Hourihane wrote:
  
  Seems like a good solution to me.
 
 Thanks.
 
  Although should we try and open libGL.so first, and then
  libGL.so.1 ??
 
 Can you elaborate on what kind of scenario you think that would be
 necessary in?

I'm thinking if anyone does libGL.so.2 for OpenGL 2.x (maybe) ??

But checking on other OS's I see one of my OpenBSD installs actually
called it libGL.so.3. I've no idea why though.

Having checked the dlopen() man page, maybe we can use NULL for the
filename which should use the main program, and check all loaded
libraries anyway

So, does this work ...

glhandle = dlopen(NULL, RTLD_NOW | RTLD_GLOBAL);

??

Alan


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [RFC] Attempt to fix the need to LD_PRELOAD libGL

2006-07-22 Thread Alan Hourihane 
On Sat, 2006-07-22 at 18:11 +0200, Michel Dänzer wrote:
 I think we need to get to the bottom of this problem, as it keeps
 getting more annoying, e.g. now with AIGLX it's not always easy to tell
 whether direct rendering is being used, and when it's not, bugs may take
 down the server instead of just the app, not to mention the inferior
 performance.
 
 From what I've gathered, the problem seems to be due to the DRI drivers
 no longer being linked against libGL (again for AIGLX) and occurs with
 apps that aren't linked to libGL directly but dlopen it, and do so
 without RTLD_GLOBAL. This seems to be mostly the case with SDL, but I
 don't think we can just discard it as a bug there, as even changing SDL
 to dlopen libGL with RTLD_GLOBAL now won't help with games that ship
 their own versions of SDL, etc.
 
 The attached patch attempts to fix this in libGL by always dlopening
 libGL itself with RTLD_GLOBAL before trying to dlopen the driver, and
 dlclosing the handle obtained from dlopening libGL again before
 returning. It works here, e.g. tremulous and slune now get direct
 rendering without LD_PRELOAD=libGL.so.1 again.
 
 Any feedback appreciated.

Seems like a good solution to me.

Although should we try and open libGL.so first, and then
libGL.so.1 ??

Alan.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] DualHead and direct rendering

2006-07-14 Thread Alan Hourihane 
On Fri, 2006-07-14 at 18:30 +0200, Agustin Rubio Mingorance wrote:
 Hello
 
 I have a PC with an Intel GM855 graphic card. 
 I've been able to get dualhead and direct rendering 
 in one of the screens, but I can't get it in both of them.
 
 ¿What should I do in order to get dri in dualhead mode?

You currently can't. It's not supported at this time.

Alan.



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] 3D performance loss with i915 driver

2006-05-02 Thread Alan Hourihane 
On Tue, 2006-05-02 at 11:49 +0100, Alan Hourihane wrote:
 On Thu, 2006-04-27 at 13:55 +0200, Lukas Hejtmanek wrote:
  On Wed, Apr 26, 2006 at 08:06:51PM -0700, Eric Anholt wrote:
   The open source driver isn't doing some important things that can be
   done to improve memory bandwidth usage.  5x is more than I expected, but
   it's not unbelievable.
   
   If you had a clear performance regression between versions of the
   open-source driver, we should definitely track that down, though.
  
  Using CVS HEAD of xc (i.e. 6.9.0 Xorg) including bundled Mesa 6.4.1 I can 
  reach
  1110 FPS in glxgears and 27-30 FPS in ppracer (compared to 860 FPS glxgears 
  and
  11 FPS in ppracer using modular CVS HEAD of X.org and Mesa).
  
  First, I thought that it's because of rotation support in i810 driver, but 
  that
  version (6.9.0) also has rotation support so it is not the problem.
 
 The problem here is batchbuffers.
 
 Due to rotation being able to shuffle memory around it wasn't possible to
 support batchbuffers in agp space as the 2D driver could rip up memory
 allocation upon a rotation event. 
 
 So the 3D driver falls back to the cmdbuffer path from system memory (rather
 than AGP memory) which can be guaranteed.
 
 To support batchbuffers again we'll need the new memory manager.

to activate the batchbuffer path again for now though, you should be
able to do...

INTEL_BATCH=1 glxgears

But this will undoubtably crash things if you rotate.

Alan.



---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] I915_PARAM_LAST_DISPATCH missing

2006-02-09 Thread Alan Hourihane 
On Thu, 2006-02-09 at 15:52 -0800, Johnson, Charles F wrote:
 I'm down to trying to build the i915_dri driver and am getting:
 
 gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver 
 -I../../../../../../drm/shared-core -I../../../../../include 
 -I../../../../../include/GL/internal -I../../../../../src/mesa 
 -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi 
 -I../../../../../src/mesa/math -I../../../../../src/mesa/transform 
 -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast 
 -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main 
 -I../../../../../src/egl/drivers/dri  `pkg-config --cflags libdrm` -Wall 
 -Wmissing-prototypes -g  -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L 
 -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS 
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS 
 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 
 -ffast-math  -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE 
 -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 
 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS intel_ioctl.c -o 
 intel_ioctl.o
 intel_ioctl.c: In function âintelGetLastFrameâ:
 intel_ioctl.c:49: error: âI915_PARAM_LAST_DISPATCHâ undeclared (first use in 
 this function)
 intel_ioctl.c:49: error: (Each undeclared identifier is reported only once
 intel_ioctl.c:49: error: for each function it appears in.)
 intel_ioctl.c: In function âintelRefillBatchLockedâ:
 intel_ioctl.c:143: warning: pointer targets in assignment differ in signedness
 make: *** [intel_ioctl.o] Error 1
 
 
 Anyone know about this one ??

You need the latest DRM from freedesktop.org CVS too.

Alan.



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev