mesa3d-dev

[Mesa3d-dev] glxinfo -l ARB prog errors

[Xavier C. <cha...@gm...>]

It seems the commit below will always report an user error when
glxinfo -l is called.
And indeed I always get the following :
$ glxinfo -l
...
    GL_VERTEX_PROGRAM_ARB:
...
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)

Should glxinfo be fixed to avoid this error ?
We could just put the fragment program only parameter in its own list,
and not use them when target is vertex program.

commit 4bccd693a72a0b42dffc849034263a68e779ca91
Author: Ian Romanick <ian...@in...>
Date:   Mon Aug 24 12:48:01 2009 -0700

    ARB prog: Set error instead of falling through with incorrect value

    If a fragment program only parameter was queried of a vertex program
    (e.g., GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB) no error would be set and
    a random value would be returned.  This caused 'glxinfo -l' to show
    the same values for GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB,
    GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB, GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB,
    GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB,
    GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB,
    GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB as for
    GL_MAX_PROGRAM_ENV_PARAMETERS_ARB.  This is confusing and incorrect.

diff --git a/src/mesa/shader/arbprogram.c b/src/mesa/shader/arbprogram.c
index 39136ef..4d8cff0 100644
--- a/src/mesa/shader/arbprogram.c
+++ b/src/mesa/shader/arbprogram.c
@@ -1001,6 +1001,9 @@ _mesa_GetProgramivARB(GLenum target, GLenum
pname, GLint *params)
             _mesa_error(ctx, GL_INVALID_ENUM, "glGetProgramivARB(pname)");
             return;
       }
+   } else {
+      _mesa_error(ctx, GL_INVALID_ENUM, "glGetProgramivARB(pname)");
+      return;
    }
 }

[Mesa3d-dev] postponed output on intel graphic with recent mesa & xorg-server

[Stephan R. <mai...@op...>]

Hi all,

with recent Mesa (git from 19.02.2010), xorg server 
(git://anongit.freedesktop.org/~krh/xserver dri2-invalidate branch), 
xorg-video-intel from 13.02.2010 i have an very postponed output on my 
Thinkpad X200t.

in my Xorg.log i see a lot of follow messages:

[3904117.243] (EE) intel(0): Failed to submit batch buffer, expect 
rendering corruption or even a frozen display: Bad file descriptor.
[3904117.277] (WW) intel(0): flip queue failed: Device or resource busy
[3904117.277] (WW) intel(0): Page flip failed: Device or resource busy
[3904117.344] (WW) intel(0): flip queue failed: Device or resource busy
[3904117.344] (WW) intel(0): Page flip failed: Device or resource busy

what can be wrong?

greetings

Stephan

-- 
               ### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
              http://www.openelec.tv

[Mesa3d-dev] Remove color index rendering?

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While we're on the topic of removing dead weight, can we remove support
for color index rendering?  None of the hardware drivers support color
index rendering, and color index rendering is deprecated in OpenGL 3.0
(and removed in 3.1).

Can it please die in a fire?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt/Kd8ACgkQX1gOwKyEAw+zpQCgj+Yr0Bo3e6O3BijR5KYEds48
DfIAniZibZEaXZsO0qYa9OW5745LM9xL
=tcrK
-----END PGP SIGNATURE-----

[Mesa3d-dev] [Bug 26632] Various cygwin build fixes

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26632


Jon TURNEY <jon...@dr...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33404|0                           |1
        is obsolete|                            |




--- Comment #10 from Jon TURNEY <jon...@dr...>  2010-02-19 15:59:28 PST ---
Created an attachment (id=33442)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33442)
Cygwin linkage fix patch

(In reply to comment #9)
> I think you still need a 'rm -rf ${LIBNAME}.obj' command like the other
> targets.  That'll get rid of the temp directory made by the expand_archives
> function.

Doh! Updated patch attached.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 26663] New: OS ABI Tag Breaks ldconfig.

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26663

           Summary: OS ABI Tag Breaks ldconfig.
           Product: Mesa
           Version: 7.6
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: GLX
        AssignedTo: mes...@li...
        ReportedBy: pa...@su...


Created an attachment (id=33437)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33437)
Remove ABI Tag

For some time libGL has included an OS ABI tag, to indicate that the library is
only usable on systems with TLS support (kernel 2.4.20 and above).

The problem is that this tag breaks ldconfig ordering of libGL. In my
deployment, I install libGL from Mesa, from nVidia, and from ATI,
simultaneously but under different paths. Adding the correct path to
/etc/ld.so.conf used to work very well.

However, with the current libGL, even when another libGL is specified with
priority, ldconfig will ignore it in favour of the Mesa GLX version, because of
the tag:

           libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
           libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1

Seeing as 2.4 kernels are becoming increasingly rare, I am recommending
removing the tag, thus restoring correct ldconfig order going forward. Patch
attached.

This was discussed on the mailing list:
http://sourceforge.net/mailarchive/message.php?msg_name=4B7467A0.7070605%40suwalski.net


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] Mesa release for the end of March?

[Corbin S. <mos...@gm...>]

On Fri, Feb 19, 2010 at 11:14 AM, Brian Paul <br...@vm...> wrote:
> Guillem Jover wrote:
>> Hi!
>>
>> [ CCing Daniel Borca who used to work on 3dfx support in Mesa and
>>   libglide, not sure though if he is around or interested anymore. ]
>>
>> On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote:
>>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
>>> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
>>
>> Could the drivers for actual hardware (namely glide, tdfx, dri/mga
>> and dri/mach64) be exempted from removal? I at least still have cards
>> for those, not sure though how many users might be out there, but
>> whenever libglide has broken in Debian, I tend to receive bug reports,
>> so I'd assume there's still some. And it always saddens me a bit when
>> hardware support gets dropped in projects.
>
> I have/had no idea if the tdfx, glide, mga or mach64 drivers function
> anymore.  If someone is actively using or testing the drivers I guess
> we could keep them, but I'd rather not otherwise.

One of my co-workers, bless his soul, is digging out a PCI Voodoo3 for
my collection, so I can maintain tdfx. I don't know about glide.

I am *not* testing mga; I don't have the right motherboard for it, sorry.

mach64's DRM code was getting a once-over by somebody on either
dri-devel or LKML; maybe we could wait and see if somebody cares.

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>

[Mesa3d-dev] [PATCH] Remove a few more instances of the MEMCPY macro.

[Kenneth G. <ke...@wh...>]

---
It looks like these were missed in commit 2240ba10.  This also removes the
last of the SUNOS4 defines; we can probably remove configs/sunos4* as well.

 src/glu/mesa/gluP.h     |   10 ----------
 src/glu/mesa/nurbssrf.c |    4 ++--
 src/glu/mesa/project.c  |    2 +-
 src/glu/mini/gluP.h     |   10 ----------
 src/glu/mini/project.c  |    2 +-
 5 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/src/glu/mesa/gluP.h b/src/glu/mesa/gluP.h
index dc1b05b..11bf239 100644
--- a/src/glu/mesa/gluP.h
+++ b/src/glu/mesa/gluP.h
@@ -79,16 +79,6 @@
 #define GLU_NO_ERROR		GL_NO_ERROR
 
 
-/* for Sun: */
-#ifdef SUNOS4
-#define MEMCPY( DST, SRC, BYTES) \
-	memcpy( (char *) (DST), (char *) (SRC), (int) (BYTES) )
-#else
-#define MEMCPY( DST, SRC, BYTES) \
-	memcpy( (void *) (DST), (void *) (SRC), (size_t) (BYTES) )
-#endif
-
-
 #ifndef NULL
 #  define NULL 0
 #endif
diff --git a/src/glu/mesa/nurbssrf.c b/src/glu/mesa/nurbssrf.c
index d39fa47..7915e28 100644
--- a/src/glu/mesa/nurbssrf.c
+++ b/src/glu/mesa/nurbssrf.c
@@ -211,7 +211,7 @@ convert_surf(knot_str_type * s_knot, knot_str_type * t_knot,
    }
    for (i = 0; i < tmp_n_control; i++)
       for (j = 0; j < t_cnt; j++)
-	 MEMCPY(*new_ctrl + j * dim + i * dim * t_cnt, tmp_ctrl[j] + dim * i,
+	 memcpy(*new_ctrl + j * dim + i * dim * t_cnt, tmp_ctrl[j] + dim * i,
 		sizeof(GLfloat) * dim);
    for (i = 0; i < t_cnt; i++)
       free(tmp_ctrl[i]);
@@ -266,7 +266,7 @@ convert_surf(knot_str_type * s_knot, knot_str_type * t_knot,
       return GLU_OUT_OF_MEMORY;
    }
    for (i = 0; i < (*s_n_ctrl); i++) {
-      MEMCPY(*new_ctrl + i * tmp_stride, tmp_ctrl[i],
+      memcpy(*new_ctrl + i * tmp_stride, tmp_ctrl[i],
 	     sizeof(GLfloat) * tmp_stride);
       free(tmp_ctrl[i]);
    }
diff --git a/src/glu/mesa/project.c b/src/glu/mesa/project.c
index 2e79cdf..1f007ec 100644
--- a/src/glu/mesa/project.c
+++ b/src/glu/mesa/project.c
@@ -105,7 +105,7 @@ matmul(GLdouble * product, const GLdouble * a, const GLdouble * b)
 #undef A
 #undef B
 #undef T
-   MEMCPY(product, temp, 16 * sizeof(GLdouble));
+   memcpy(product, temp, 16 * sizeof(GLdouble));
 }
 
 
diff --git a/src/glu/mini/gluP.h b/src/glu/mini/gluP.h
index a39edce..c7c8fb0 100644
--- a/src/glu/mini/gluP.h
+++ b/src/glu/mini/gluP.h
@@ -123,16 +123,6 @@ typedef struct tagPIXELFORMATDESCRIPTOR PIXELFORMATDESCRIPTOR, *PPIXELFORMATDESC
 #define GLU_NO_ERROR		GL_NO_ERROR
 
 
-/* for Sun: */
-#ifdef SUNOS4
-#define MEMCPY( DST, SRC, BYTES) \
-	memcpy( (char *) (DST), (char *) (SRC), (int) (BYTES) )
-#else
-#define MEMCPY( DST, SRC, BYTES) \
-	memcpy( (void *) (DST), (void *) (SRC), (size_t) (BYTES) )
-#endif
-
-
 #ifndef NULL
 #  define NULL 0
 #endif
diff --git a/src/glu/mini/project.c b/src/glu/mini/project.c
index 2e79cdf..1f007ec 100644
--- a/src/glu/mini/project.c
+++ b/src/glu/mini/project.c
@@ -105,7 +105,7 @@ matmul(GLdouble * product, const GLdouble * a, const GLdouble * b)
 #undef A
 #undef B
 #undef T
-   MEMCPY(product, temp, 16 * sizeof(GLdouble));
+   memcpy(product, temp, 16 * sizeof(GLdouble));
 }
 
 
-- 
1.7.0

[Mesa3d-dev] [PATCH mesa] Fix some typos in pointer checking for OML_sync_control entry points.

[Mario K. <mar...@tu...>]

From: kleinerm <mar...@tu...>

Signed-off-by: Mario Kleiner <mar...@tu...>
---
 src/glx/x11/glxcmds.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index fefdd99..67518dd 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -2364,7 +2364,7 @@ __glXGetSyncValuesOML(Display * dpy, GLXDrawable drawable,
    psc = &priv->screenConfigs[i];
 
 #if defined(__DRI_SWAP_BUFFER_COUNTER) && defined(__DRI_MEDIA_STREAM_COUNTER)
-   if (pdraw && psc->sbc && psc->sbc)
+   if (pdraw && psc->sbc && psc->msc)
       return ( (pdraw && psc->sbc && psc->msc)
 	       && ((*psc->msc->getMSC)(psc->driScreen, msc) == 0)
 	       && ((*psc->sbc->getSBC)(pdraw->driDrawable, sbc) == 0)
@@ -2487,7 +2487,7 @@ __glXSwapBuffersMscOML(Display * dpy, GLXDrawable drawable,
    __GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable, &screen);
    __GLXscreenConfigs *const psc = GetGLXScreenConfigs(dpy, screen);
 
-   if (!pdraw || !gc->driContext) /* no GLX for this */
+   if (!pdraw || !gc || !gc->driContext) /* no GLX for this */
       return -1;
 
    /* The OML_sync_control spec says these should "generate a GLX_BAD_VALUE
@@ -2587,7 +2587,7 @@ __glXWaitForSbcOML(Display * dpy, GLXDrawable drawable,
       return ((ret == 0) && (__glXGetUST(ust) == 0));
    }
 #endif
-   if (pdraw && psc->driScreen && psc->driScreen->waitForMSC) {
+   if (pdraw && psc->driScreen && psc->driScreen->waitForSBC) {
       ret = psc->driScreen->waitForSBC(pdraw, target_sbc, ust, msc, sbc);
       return ret;
    }
-- 
1.6.6

[Mesa3d-dev] [Bug 26121] Crash on x86-64 (but not on x86) for glLightfv w/o rendering context

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26121


Ian Romanick <id...@fr...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |NOTOURBUG




--- Comment #2 from Ian Romanick <id...@fr...>  2010-02-19 11:40:05 PST ---
The NULL dereference happens during function dispatch.  Add a NULL check would
add overhead to every single OpenGL function call.  Correct applications should
not have to pay a performance penalty to prevent buggy apps from crashing.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [PATCH 00/11] Kill various _mesa_* wrappers.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenneth Graunke wrote:
> These patches remove various _mesa_foo() wrappers in favor of simply
> calling foo() directly.  I've split them out by function so it's
> possible to pick and choose which ones to apply.  Sorry for the spam.
> 
> I figured I'd resend updated copies since Brian mentioned possibly
> including them before the 7.8 release.
> 
> The last three may break the SUNOS4 build, but I doubt anyone
> cares seeing as the last release of that system was in 1994.

After reviewing the patches, I don't think those changes will break the
SUNOS4 build.  I think it will just cause a bunch of spurious warnings.
 I'm okay with that.  You can add

Reviewed-by: Ian Romanick <ian...@in...>

on the whole series except 9 and 10.  I think those patches should also
eliminate the MEMCPY and MEMSET macros that wrap the wrappers.  Unless
there are objections, I'll apply patches 1 through 8 and 11 later today.

Thanks for jumping on this so quickly!

I'd also like to see additional patches to eliminate:

 - _mesa_bzero - Conditionally wrap this if HAVE_BZERO is not defined.
Do the usual autoconf magic to detect it.  Let non-autoconf builds
figure it out there own way.

 - _mesa_bsearch.  If we care about WinCE, we can give similar autoconf
treatment for bsearch.

 - The math (_mesa_sin, _mesa_sinf, etc.) wrappers.  Since the float
versions exist on some implementations, this should get the same
autoconf treatment as bzero.

 - _mesa_malloc, _mesa_calloc, _mesa_free, and especially _mesa_realloc.
 The other memory management wrappers provide useful functionality, so
they should be kept.

 - _mesa_printf and friends.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt+5uMACgkQX1gOwKyEAw99wQCdGz4BPjNTEEPRdeyVseo/+FS4
i8MAn2fPnIkIXutMPRT+QCXMhcKWKd8v
=8hub
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Mesa release for the end of March?

[Brian P. <br...@vm...>]

Guillem Jover wrote:
> Hi!
> 
> [ CCing Daniel Borca who used to work on 3dfx support in Mesa and
>   libglide, not sure though if he is around or interested anymore. ]
> 
> On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote:
>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
>> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
> 
> Could the drivers for actual hardware (namely glide, tdfx, dri/mga
> and dri/mach64) be exempted from removal? I at least still have cards
> for those, not sure though how many users might be out there, but
> whenever libglide has broken in Debian, I tend to receive bug reports,
> so I'd assume there's still some. And it always saddens me a bit when
> hardware support gets dropped in projects.

I have/had no idea if the tdfx, glide, mga or mach64 drivers function 
anymore.  If someone is actively using or testing the drivers I guess 
we could keep them, but I'd rather not otherwise.


> Out of curiousity, are those burdersome to deal with, or hindering
> further imrpovements or development in other areas? Anything major
> that needs to be done to them? I can perfectly understand the desire
> to remove legacy stuff that might block or take much of your time,
> keeping them would still be appreciated. I also fear I have my hands
> full already with lots of stuff, so cannot offer much of help, at
> least right now. Though, I should finally cleanup and commit upstream
> some of the libglide patches I have in Debian.

When I change core things in Mesa (like the texformat overhaul last 
fall) I wonder if the lesser-used drivers still function since I don't 
test them.

In any case, older versions of Mesa with the drivers in question won't 
go away so people can use those if needed.

-Brian

Re: [Mesa3d-dev] Mesa release for the end of March?

[José F. <jfo...@vm...>]

On Fri, 2010-02-19 at 10:23 -0800, Kristian Høgsberg wrote:
> 2010/2/19 Brian Paul <bri...@gm...>:
> > 2010/2/19 Kristian Høgsberg <kr...@bi...>:
> >> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
> >>> 2010/2/19 Brian Paul <bri...@gm...>:
> >>>> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
> >>>>
> >>>>> I applied the patches from Kenneth Graunke on the list for this.  Can
> >>>>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
> >>>>> _mesa_bzero() too?
> >>>>
> >>>> I've remove _mesa_bzero() just now, plus some other macro wrappers.
> >>>>
> >>>> We might as well remove the malloc/calloc() wrappers too, but that'll
> >>>> be a bit more work.
> >>>
> >>> I'm using:
> >>>
> >>>  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
> >>>
> >>> which does most of the work.  I'll do the same thing for _mesa_calloc
> >>> and _mesa_free, review the result and commit that.
> >>
> >> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
> >> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
> >> _mesa_align_* functions.  Do we want to drop those too?  I hesitated
> >> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
> >> instead of the malloc, calloc, free functions."  But as far as I can
> >> see, they're not redefined or anything for gallium and they just
> >> resolve to the standard malloc, calloc and free functions.  Am I
> >> missing something?
> >
> > Let's keep the Gallium code as-is.
> >
> > But for Mesa:
> >
> > MALLOC_STRUCT and CALLOC_STRUCT should be kept.  They save a lot of typing.
> >
> > MALLOC, CALLOC, and FREE can go.  The ALIGN macros could probably go
> > too (just call the align functions).
> >
> > Years ago, some systems defined malloc() as returning char * instead
> > of void * so the Mesa wrappers helped with casting.  Plus, back before
> > valgrind I'd often rig up my own malloc-debug code to track down
> > memory errors.  The macros were handy for that.
> 
> Ok, I droppped the ALIGN macros, but I'll leave the rest as is.  Not
> sure what Jose has in mind, but I hope we can drop the MALLOC, CALLOC
> and FREE wrappers as well.  At least on Linux today, we have valgrind
> and LD_PRELOAD tricks available to do malloc debugging that doesn't
> require malloc wrappers.

My plan was to use pretty much the src/gallium/auxiliary/os/os_memory.h
as is. Mesa will never run in kernel mode like gallium needs to, but it
still quite cross-platform, so having a thing abstraction on top of STDC
free/malloc/calloc is always a convenient.

Linux has very nice memory debugging tools indeed, but windows has
nothing near valgrind. Even if one is willing to pay.

Also the debugging wrappers are convenient because they run every time
-- if you introduce a regression you quickly see that in the final
report when closing the app. It's not necessary to go out of the way to
run a debugging tool.

Jose

Re: [Mesa3d-dev] [PATCH 00/11] Kill various _mesa_* wrappers.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenneth Graunke wrote:
> These patches remove various _mesa_foo() wrappers in favor of simply
> calling foo() directly.  I've split them out by function so it's
> possible to pick and choose which ones to apply.  Sorry for the spam.
> 
> I figured I'd resend updated copies since Brian mentioned possibly
> including them before the 7.8 release.
> 
> The last three may break the SUNOS4 build, but I doubt anyone
> cares seeing as the last release of that system was in 1994.

It may be worth going one further and just removing any SUNOS4 ifdef's
altogether as a separate patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt+4TcACgkQX1gOwKyEAw8HxACfVSjW3x68XlUeGdOcOCK1imDe
9koAnic34sBlvZMJEBv6QEHNdnDhW8VH
=k3dd
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Mesa release for the end of March?

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Paul wrote:
> Ian Romanick wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ian Romanick wrote:
>>> All,
>>>
>>> It's time again to plan what version or versions of Mesa we want to
>>> release in Q1 (end of March).  It seems like 7.7.1 is a no-brainer.  Do
>>> we also want to release Mesa 7.8?  I haven't been keeping track of
>>> master, so I don't know what its state is.  Is it pretty stable?  Are
>>> there any big branches waiting to land?
>>>
>>> Working backwards from a "last week of March" release, master would have
>>> to branch to mesa_7_8_branch during the last week of February.  That's
>>> roughly 6 weeks away.
>>>
>>> Thoughts?  Opinions?
>> Assuming this plan still works for people, I'll make the mesa_7_8_branch
>> on Friday, February 26th.
> 
> I think we could get by with a shorter "beta" period.  There's a few 
> more things that would be nice to do for 7.8 which I doubt I'd get to 
> before the 26th:

Part of the reason for the long lead time is to keep my testing group
happy.  I don't see a problem moving the branch out a week (to 3/5).
I'll check with them to be sure.

> 1. GL_APPLE_object_purgeable - I think the last round of patches 
> looked OK.  Chris?

Wow.  I thought this was already in. :)

> 2. _mesa_memcpy() -> memcpy(), etc. replacement.  There were patches 
> for this that haven't been applied yet.  Maybe someone could pick 
> those up.

I think Kenneth Graunke has some patches.

> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx, 
> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?

I'd be in favor of dumping the various unmaintained software
rasterization drivers.  beos, dos, d3d, and svga could probably be added
to that list.  I'm not too excited about dumping working hardware
drivers, though.  We should probably come up with a complete candidate
list and circulate it.  Any drivers that nobody stands up for should get
axed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt+4KQACgkQX1gOwKyEAw/ZBQCgmkt2WebOUgdjM4tLwP6Qskff
UX8An2T7yWjbo79kdsq/CmTD7KhNyib4
=gYtg
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Mesa release for the end of March?

[Kristian H. <kr...@bi...>]

2010/2/19 Brian Paul <bri...@gm...>:
> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>>> 2010/2/19 Brian Paul <bri...@gm...>:
>>>> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>>>>
>>>>> I applied the patches from Kenneth Graunke on the list for this.  Can
>>>>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>>>>> _mesa_bzero() too?
>>>>
>>>> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>>>>
>>>> We might as well remove the malloc/calloc() wrappers too, but that'll
>>>> be a bit more work.
>>>
>>> I'm using:
>>>
>>>  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>>>
>>> which does most of the work.  I'll do the same thing for _mesa_calloc
>>> and _mesa_free, review the result and commit that.
>>
>> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
>> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
>> _mesa_align_* functions.  Do we want to drop those too?  I hesitated
>> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
>> instead of the malloc, calloc, free functions."  But as far as I can
>> see, they're not redefined or anything for gallium and they just
>> resolve to the standard malloc, calloc and free functions.  Am I
>> missing something?
>
> Let's keep the Gallium code as-is.
>
> But for Mesa:
>
> MALLOC_STRUCT and CALLOC_STRUCT should be kept.  They save a lot of typing.
>
> MALLOC, CALLOC, and FREE can go.  The ALIGN macros could probably go
> too (just call the align functions).
>
> Years ago, some systems defined malloc() as returning char * instead
> of void * so the Mesa wrappers helped with casting.  Plus, back before
> valgrind I'd often rig up my own malloc-debug code to track down
> memory errors.  The macros were handy for that.

Ok, I droppped the ALIGN macros, but I'll leave the rest as is.  Not
sure what Jose has in mind, but I hope we can drop the MALLOC, CALLOC
and FREE wrappers as well.  At least on Linux today, we have valgrind
and LD_PRELOAD tricks available to do malloc debugging that doesn't
require malloc wrappers.

Kristian

Re: [Mesa3d-dev] Mesa release for the end of March?

[José F. <jfo...@vm...>]

On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote:
> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
> > 2010/2/19 Brian Paul <bri...@gm...>:
> >> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
> >>
> >>> I applied the patches from Kenneth Graunke on the list for this.  Can
> >>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
> >>> _mesa_bzero() too?
> >>
> >> I've remove _mesa_bzero() just now, plus some other macro wrappers.
> >>
> >> We might as well remove the malloc/calloc() wrappers too, but that'll
> >> be a bit more work.
> >
> > I'm using:
> >
> >  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
> >
> > which does most of the work.  I'll do the same thing for _mesa_calloc
> > and _mesa_free, review the result and commit that.
> 
> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
> _mesa_align_* functions.  Do we want to drop those too?  

Given that we'll unify these for gallium and mesa it's better leave them
allone for now -- it will make it easier to search'n'replace when we do
that.

I hope to get started on this task next week.

> I hesitated
> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
> instead of the malloc, calloc, free functions."  But as far as I can
> see, they're not redefined or anything for gallium and they just
> resolve to the standard malloc, calloc and free functions.  Am I
> missing something?

On gallium they only resolve to malloc/calloc/free on certain platforms
-- Linux & Windows user space. And even in Windows debug we use malloc
debugging macros.

Jose

Re: [Mesa3d-dev] Mesa release for the end of March?

[Brian P. <bri...@gm...>]

On Fri, Feb 19, 2010 at 10:59 AM, José Fonseca <jfo...@vm...> wrote:
> On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote:
>> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>> > 2010/2/19 Brian Paul <bri...@gm...>:
>> >> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>> >>
>> >>> I applied the patches from Kenneth Graunke on the list for this.  Can
>> >>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>> >>> _mesa_bzero() too?
>> >>
>> >> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>> >>
>> >> We might as well remove the malloc/calloc() wrappers too, but that'll
>> >> be a bit more work.
>> >
>> > I'm using:
>> >
>> >  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>> >
>> > which does most of the work.  I'll do the same thing for _mesa_calloc
>> > and _mesa_free, review the result and commit that.
>>
>> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
>> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
>> _mesa_align_* functions.  Do we want to drop those too?
>
> Given that we'll unify these for gallium and mesa it's better leave them
> allone for now -- it will make it easier to search'n'replace when we do
> that.
>
> I hope to get started on this task next week.

OK, disregard my other reply then.  I forgot about this, Jose.

-Brian

Re: [Mesa3d-dev] Mesa release for the end of March?

[Brian P. <bri...@gm...>]

2010/2/19 Kristian Høgsberg <kr...@bi...>:
> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>> 2010/2/19 Brian Paul <bri...@gm...>:
>>> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>>>
>>>> I applied the patches from Kenneth Graunke on the list for this.  Can
>>>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>>>> _mesa_bzero() too?
>>>
>>> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>>>
>>> We might as well remove the malloc/calloc() wrappers too, but that'll
>>> be a bit more work.
>>
>> I'm using:
>>
>>  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>>
>> which does most of the work.  I'll do the same thing for _mesa_calloc
>> and _mesa_free, review the result and commit that.
>
> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
> _mesa_align_* functions.  Do we want to drop those too?  I hesitated
> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
> instead of the malloc, calloc, free functions."  But as far as I can
> see, they're not redefined or anything for gallium and they just
> resolve to the standard malloc, calloc and free functions.  Am I
> missing something?

Let's keep the Gallium code as-is.

But for Mesa:

MALLOC_STRUCT and CALLOC_STRUCT should be kept.  They save a lot of typing.

MALLOC, CALLOC, and FREE can go.  The ALIGN macros could probably go
too (just call the align functions).

Years ago, some systems defined malloc() as returning char * instead
of void * so the Mesa wrappers helped with casting.  Plus, back before
valgrind I'd often rig up my own malloc-debug code to track down
memory errors.  The macros were handy for that.

-Brian

Re: [Mesa3d-dev] Mesa release for the end of March?

[Kristian H. <kr...@bi...>]

2010/2/19 Kristian Høgsberg <kr...@bi...>:
> 2010/2/19 Brian Paul <bri...@gm...>:
>> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>>
>>> I applied the patches from Kenneth Graunke on the list for this.  Can
>>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>>> _mesa_bzero() too?
>>
>> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>>
>> We might as well remove the malloc/calloc() wrappers too, but that'll
>> be a bit more work.
>
> I'm using:
>
>  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>
> which does most of the work.  I'll do the same thing for _mesa_calloc
> and _mesa_free, review the result and commit that.

All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
_mesa_align_* functions.  Do we want to drop those too?  I hesitated
because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
instead of the malloc, calloc, free functions."  But as far as I can
see, they're not redefined or anything for gallium and they just
resolve to the standard malloc, calloc and free functions.  Am I
missing something?

Kristian

Re: [Mesa3d-dev] Mesa release for the end of March?

[Guillem J. <gu...@ha...>]

Hi!

[ CCing Daniel Borca who used to work on 3dfx support in Mesa and
  libglide, not sure though if he is around or interested anymore. ]

On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote:
> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?

Could the drivers for actual hardware (namely glide, tdfx, dri/mga
and dri/mach64) be exempted from removal? I at least still have cards
for those, not sure though how many users might be out there, but
whenever libglide has broken in Debian, I tend to receive bug reports,
so I'd assume there's still some. And it always saddens me a bit when
hardware support gets dropped in projects.

Out of curiousity, are those burdersome to deal with, or hindering
further imrpovements or development in other areas? Anything major
that needs to be done to them? I can perfectly understand the desire
to remove legacy stuff that might block or take much of your time,
keeping them would still be appreciated. I also fear I have my hands
full already with lots of stuff, so cannot offer much of help, at
least right now. Though, I should finally cleanup and commit upstream
some of the libglide patches I have in Debian.

thanks,
guillem

Re: [Mesa3d-dev] Mesa release for the end of March?

[Kristian H. <kr...@bi...>]

2010/2/19 Brian Paul <bri...@gm...>:
> 2010/2/19 Kristian Høgsberg <kr...@bi...>:
>
>> I applied the patches from Kenneth Graunke on the list for this.  Can
>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>> _mesa_bzero() too?
>
> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>
> We might as well remove the malloc/calloc() wrappers too, but that'll
> be a bit more work.

I'm using:

  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g

which does most of the work.  I'll do the same thing for _mesa_calloc
and _mesa_free, review the result and commit that.

>>  What about the _mesa_*printf() functions?  It
>> looks to me like they just wrap the platform *printf() functions and
>> don't provide any fallbacks if the platform doesn't provide the
>> function.
>
> That's probably fine too.

I'll use the same sed line for the *printf functions.

Kristian

Re: [Mesa3d-dev] [PATCH 08/12] intel: Implement DRI image extension

[Brian P. <bri...@gm...>]

2010/2/18 Kristian Høgsberg <kr...@bi...>:
> 2010/2/18 Brian Paul <br...@vm...>:
>> Kristian Høgsberg wrote:
>>>
>>> 2010/2/12 Ian Romanick <id...@fr...>:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Kristian Høgsberg wrote:
>>>>>
>>>>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> b/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> index f7ce87e..c2c8c6e 100644
>>>>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>>>>> @@ -41,6 +41,7 @@
>>>>>  #include "intel_fbo.h"
>>>>>  #include "intel_screen.h"
>>>>>  #include "intel_tex.h"
>>>>> +#include "intel_regions.h"
>>>>>
>>>>>  #include "i915_drm.h"
>>>>>
>>>>> @@ -141,11 +142,84 @@ static const struct __DRI2flushExtensionRec
>>>>> intelFlushExtension = {
>>>>>     intelDRI2FlushInvalidate,
>>>>>  };
>>>>>
>>>>> +static __DRIimage *
>>>>> +intel_create_image_internal(__DRIcontext *context,
>>>>> +                         int width, int height, int internal_format,
>>>>> +                         int name, int pitch, void *loaderPrivate)
>>>>> +{
>>>>> +    __DRIimage *image;
>>>>> +    struct intel_context *intel = context->driverPrivate;
>>>>> +    int cpp;
>>>>> +
>>>>> +    image = CALLOC(sizeof *image);
>>>>> +    image->internal_format = internal_format;
>>>>> +    switch (internal_format) {
>>>>> +    case GL_RGBA:
>>>>> +       image->format = MESA_FORMAT_ARGB8888;
>>>>> +       image->data_type = GL_UNSIGNED_BYTE;
>>>>> +       break;
>>>>> +    case GL_RGB:
>>>>> +       image->format = MESA_FORMAT_XRGB8888;
>>>>> +       image->data_type = GL_UNSIGNED_BYTE;
>>>>> +       break;
>>>>> +    }
>>>>
>>>> No love for 565 or 4444 pixmaps?
>>>
>>> Good question.  What is a sufficient way to specify the pixel format?
>>> Internal format + datatype?  That's what glTexImage2D uses and should
>>> be enough to describe the type of content and layout of the color
>>> components, for example GL_RGB8 + GL_UNSIGNED_INT_8_8_8_8.
>>
>> That particular format/type combo is invalid for glTexImage, btw.
>
> That was meant as an internalformat/type combo - that's valid right?

Yes.  It's the glTexImage format and type parameters that have
particular combinations that are legal or illegal.


>>> Alternatively we can expose the MESA_FORMAT_* values as __DRI_FORMAT_*
>>> tokens and use that in the __DRIimage extension.
>>
>> I haven't followed this too closely... but FYI, there's no guarantee that
>> the MESA_FORMAT_x token values won't change at any time.  If you create some
>> __DRI_FORMAT_x tokens they should probably have different values just to be
>> safe.
>
> Yeah, they would be different tokens, the idea was to specify color
> components and layout with one token similar to how the MESA_FORMAT_*
> defines work, not to expose the MESA_FORMAT_* values directly.  But
> I'm leaning aginst not going for this idea.
>
> I'm trying to figure out if it's appropriate to assume that all
> drivers for a given chipset will choose the same pixel layout for, say
> GL_RGBA8 or GL_RGB5.  Then when we create an EGLImage from a GEM (or
> TTM) handle we only need to pass GL_RGBA8 as the format value and the
> driver will know how the components are laid out.  Or do we need to
> specify the pixel layout as well.  Still not sure...


-Brian

Re: [Mesa3d-dev] Mesa release for the end of March?

[Brian P. <bri...@gm...>]

2010/2/19 Kristian Høgsberg <kr...@bi...>:

> I applied the patches from Kenneth Graunke on the list for this.  Can
> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
> _mesa_bzero() too?

I've remove _mesa_bzero() just now, plus some other macro wrappers.

We might as well remove the malloc/calloc() wrappers too, but that'll
be a bit more work.


>  What about the _mesa_*printf() functions?  It
> looks to me like they just wrap the platform *printf() functions and
> don't provide any fallbacks if the platform doesn't provide the
> function.

That's probably fine too.


>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
>> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
>
> Sounds great.  As George suggests, maybe we can drop dri/fb and
> dri/ffb too?  What about d3d?  I don't know much about the driver, but
> I don't see a lot of commits there since 1999 except mechanical
> changes to keep it compiling.

Those driver can go too as far as I'm concerned.  If there aren't
objections over the next 24 hours or so, feel free to start rm'ing.  I
may be off line this weekend.


> Finally, I'd like to land EGLImage support for the dri2 EGL driver,
> which I should be able to do next week.

Sounds great.

-Brian

Re: [Mesa3d-dev] Mesa release for the end of March?

[Brian P. <bri...@gm...>]

On Thu, Feb 18, 2010 at 9:50 PM, Chia-I Wu <ol...@gm...> wrote:
> On Fri, Feb 19, 2010 at 8:25 AM, Brian Paul <br...@vm...> wrote:
>>> Assuming this plan still works for people, I'll make the mesa_7_8_branch
>>> on Friday, February 26th.
>> I think we could get by with a shorter "beta" period.  There's a few
>> more things that would be nice to do for 7.8 which I doubt I'd get to
>> before the 26th:
>> 1. GL_APPLE_object_purgeable - I think the last round of patches
>> looked OK.  Chris?
>> 2. _mesa_memcpy() -> memcpy(), etc. replacement.  There were patches
>> for this that haven't been applied yet.  Maybe someone could pick
>> those up.
>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
>> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
> I like this change.
>
> There are some Makefiles under src/mesa/main/.  Are they still used?  Could we
> remove them?

You can remove them.

-Brian

Re: [Mesa3d-dev] Mesa (master): r300g: remove L8_UNORM from colorbuffer formats

[Roland S. <sr...@vm...>]

This isn't actually true any more. See issue (9) of
ARB_framebuffer_object which defines luminance, luminance_alpha and
intensity as renderable.
(I'm not quite sure how color assignment is done, readpixels and the
like would define L = R + G + B, but I think it will follow the table
from texture image specification instead, hence L = R, I = R).
You are quite right though this is a recent addition, and in fact for
instance i965 can't render to this neither (it can render to red or
alpha formats, but none of the l/i formats) directly, neither can r300
(without shader hacking).

Roland


On 19.02.2010 15:35, Marek Olšák wrote:
> I still think st/xorg should use R8, which is well defined as to which
> component to store, rather than L8. That's also the reason L8 is not
> renderable in OpenGL.
> 
> 
> 2010/2/19 Corbin Simpson <mos...@gm...
> <mailto:mos...@gm...>>
> 
>     Yeah, I would have nak'd this. Will revert when I get home.
> 
>     Posting from a mobile, pardon my terseness. ~ C.
> 
>>     On Feb 19, 2010 12:56 AM, "Michel Dänzer" <mi...@da...
>>     <mailto:mi...@da...>> wrote:
>>
>>     On Thu, 2010-02-18 at 19:24 -0800, Marek OlXXXXk wrote:
>>     > Module: Mesa
>>     > Branch: master
>>     > Commit: fc427d23439a2702068209957f08990ea29fe21b
>>     > URL:  
>>      http://cgit.freedesktop.org/mesa/mesa/commit/?id=fc427d23439a2702068209957f08990ea29fe21b
>>     >
>>     > Author: Marek Olšák <ma...@gm... <mailto:ma...@gm...>>
>>     > Date:   Fri Feb 19 04:23:06 2010 +0100
>>     >
>>     > r300g: remove L8_UNORM from colorbuffer formats
>>     >
>>     > Not renderable in OpenGL anyway.
>>
>>     The Xorg state tracker uses it though.
>>
>>
>>     --
>>     Earthling Michel Dänzer           |              
>>      http://www.vmware.com
>>     Libre software enthusiast         |          Debian, X and DRI
>>     developer
>>
>>     ------------------------------------------------------------------------------
>>     Download Intel&#174; Parallel Studio Eval
>>     Try the new software tools for yourself. Speed compiling, find bugs
>>     proactively, and fine-tune applications for parallel performance.
>>     See why Intel Parallel Studio got high marks during beta.
>>     http://p.sf.net/sfu/intel-sw-dev
>>     _______________________________________________
>>     Mesa3d-dev mailing list
>>     Mes...@li...
>>     <mailto:Mes...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev