[Mesa-dev] [PATCH:mesa] util: Make xmlconfig.c build on Solaris without d_type in dirent (v2)
v2: check for lstat() failing
Fixes: 04bdbbcab3c "xmlconfig: read more config files from drirc.d/"
Signed-off-by: Alan Coopersmith
Reviewed-by: Roland Mainz
Reviewed-by: Ian Romanick
---
src/util/xmlconfig.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/util/xmlconfig.c b/src/util/xmlconfig.c
index 5264f2598b..5907c68012 100644
--- a/src/util/xmlconfig.c
+++ b/src/util/xmlconfig.c
@@ -938,8 +938,16 @@ parseOneConfigFile(struct OptConfData *data, const char
*filename)
static int
scandir_filter(const struct dirent *ent)
{
+#ifndef DT_REG /* systems without d_type in dirent results */
+struct stat st;
+
+if ((lstat(ent->d_name, &st) != 0) ||
+(!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode)))
+ return 0;
+#else
if (ent->d_type != DT_REG && ent->d_type != DT_LNK)
return 0;
+#endif
if (fnmatch("*.conf", ent->d_name, 0))
return 0;
--
2.15.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa] util: Make xmlconfig.c build on Solaris without d_type in dirent
On 10/ 5/18 10:04 AM, Ian Romanick wrote: On 10/03/2018 08:21 PM, Alan Coopersmith wrote: On 10/ 3/18 03:15 PM, Roland Mainz wrote: On Wed, Oct 3, 2018 at 11:51 PM Alan Coopersmith wrote: Introduced-by: commit 04bdbbcab3c4862bf3f54ce60fcc1d2007776f80 Is this formatting something you need for your internal systems? The format we've been using to signal that a change is a fix to a bug introduced by a specific commit is: Fixes: 04bdbbcab3c "xmlconfig: read more config files from drirc.d/" That ensures the fix gets bundled in the correct stable release branches. No, this is me being disconnected enough from Mesa development that I didn't know the right way to do it, and overlooked the note about this on https://mesa3d.org/submittingpatches.html - I'll fix that. Thanks, -alan- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa] util: Make xmlconfig.c build on Solaris without d_type in dirent
On 10/ 3/18 10:57 PM, Roland Mainz wrote:
The term "small" is not right here, for example:
2. HSM (=Hierarchical Storage Management) may need some time
(=minutes) to fetch data from tape
3. You may not have the permission to |stat()| the specific file or
directory, thanks to the wonders of ACLs and/or alien filesystems like
smbfs
This is only scanning for config files in /etc/dri.d & /usr/share/dri.d.
If you've configured those to be on HSM or have weird ACLs, then you get
to enjoy all the pain that comes with that - I'd advise against it.
That version looks OK for me, r=roland.ma...@nrubsig.org
Thanks.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa] util: Make xmlconfig.c build on Solaris without d_type in dirent
On 10/ 3/18 03:15 PM, Roland Mainz wrote:
On Wed, Oct 3, 2018 at 11:51 PM Alan Coopersmith
wrote:
Introduced-by: commit 04bdbbcab3c4862bf3f54ce60fcc1d2007776f80
Signed-off-by: Alan Coopersmith
---
src/util/xmlconfig.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/util/xmlconfig.c b/src/util/xmlconfig.c
index 5264f2598b..608972f812 100644
--- a/src/util/xmlconfig.c
+++ b/src/util/xmlconfig.c
@@ -938,8 +938,16 @@ parseOneConfigFile(struct OptConfData *data, const char
*filename)
static int
scandir_filter(const struct dirent *ent)
{
+#ifndef DT_REG /* systems without d_type in dirent results */
+struct stat st;
+
+lstat(ent->d_name, &st);
+if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
+ return 0;
+#else
What about testing for the return code of |lstat()|&&|errno| before
looking at the value of |st| ?
Oh, I suppose there is a small window in which the file could disappear after
it's read from the directory entry, but before the lstat occurs.
Attached version checks for that.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
>From 21e491c1f0f112ccdf3df1ad8f1d1722fe272fd6 Mon Sep 17 00:00:00 2001
From: Alan Coopersmith
Date: Tue, 2 Oct 2018 22:04:04 -0700
Subject: [PATCH:mesa] util: Make xmlconfig.c build on Solaris without d_type
in dirent (v2)
v2: check for lstat() failing
Introduced-by: commit 04bdbbcab3c4862bf3f54ce60fcc1d2007776f80
Signed-off-by: Alan Coopersmith
---
src/util/xmlconfig.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/util/xmlconfig.c b/src/util/xmlconfig.c
index 5264f2598b..5907c68012 100644
--- a/src/util/xmlconfig.c
+++ b/src/util/xmlconfig.c
@@ -938,8 +938,16 @@ parseOneConfigFile(struct OptConfData *data, const char *filename)
static int
scandir_filter(const struct dirent *ent)
{
+#ifndef DT_REG /* systems without d_type in dirent results */
+struct stat st;
+
+if ((lstat(ent->d_name, &st) != 0) ||
+(!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode)))
+ return 0;
+#else
if (ent->d_type != DT_REG && ent->d_type != DT_LNK)
return 0;
+#endif
if (fnmatch("*.conf", ent->d_name, 0))
return 0;
--
2.15.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa] util: Make xmlconfig.c build on Solaris without d_type in dirent
Introduced-by: commit 04bdbbcab3c4862bf3f54ce60fcc1d2007776f80
Signed-off-by: Alan Coopersmith
---
src/util/xmlconfig.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/util/xmlconfig.c b/src/util/xmlconfig.c
index 5264f2598b..608972f812 100644
--- a/src/util/xmlconfig.c
+++ b/src/util/xmlconfig.c
@@ -938,8 +938,16 @@ parseOneConfigFile(struct OptConfData *data, const char
*filename)
static int
scandir_filter(const struct dirent *ent)
{
+#ifndef DT_REG /* systems without d_type in dirent results */
+struct stat st;
+
+lstat(ent->d_name, &st);
+if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
+ return 0;
+#else
if (ent->d_type != DT_REG && ent->d_type != DT_LNK)
return 0;
+#endif
if (fnmatch("*.conf", ent->d_name, 0))
return 0;
--
2.15.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: Refuse to build with Sun C compiler.
On 12/ 2/15 01:04 AM, Roland Mainz wrote: On Wed, Dec 2, 2015 at 12:38 AM, Alan Coopersmith wrote: On 12/ 1/15 03:07 PM, Jose Fonseca wrote: https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- configure.ac | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configure.ac b/configure.ac index 4016871..b6680d0 100644 --- a/configure.ac +++ b/configure.ac @@ -197,6 +197,13 @@ if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno; then fi fi +dnl We don't support building Mesa with Sun C compiler +dnl https://bugs.freedesktop.org/show_bug.cgi?id=93189 +AC_CHECK_DECL([__SUNPRO_C], [SUNCC=yes], [SUNCC=no]) +if test "x$SUNCC" = xyes; then +AC_MSG_ERROR([Building with Sun C compiler is not supported, use GCC instead.]) +fi + dnl Check for compiler builtins AX_GCC_BUILTIN([__builtin_bswap32]) AX_GCC_BUILTIN([__builtin_bswap64]) Acked-by: Alan Coopersmith Just curious: Why ? Because Mesa developers continue to use extensions & syntax that Studio does not support, and no one is putting in the effort to rewrite the Mesa code to work with Studio and still be maintainable by people without Studio access. We've built Mesa for Solaris with gcc for a while, so this won't impact us, and no one else seems to want Studio support enough to make it work. There's a half dozen bugs in the Mesa bugzilla for non-portable code that breaks on Studio that have been filed recently that this closes. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: Refuse to build with Sun C compiler.
On 12/ 1/15 03:07 PM, Jose Fonseca wrote: https://bugs.freedesktop.org/show_bug.cgi?id=93189 --- configure.ac | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configure.ac b/configure.ac index 4016871..b6680d0 100644 --- a/configure.ac +++ b/configure.ac @@ -197,6 +197,13 @@ if test "x$GCC" = xyes -a "x$acv_mesa_CLANG" = xno; then fi fi +dnl We don't support building Mesa with Sun C compiler +dnl https://bugs.freedesktop.org/show_bug.cgi?id=93189 +AC_CHECK_DECL([__SUNPRO_C], [SUNCC=yes], [SUNCC=no]) +if test "x$SUNCC" = xyes; then +AC_MSG_ERROR([Building with Sun C compiler is not supported, use GCC instead.]) +fi + dnl Check for compiler builtins AX_GCC_BUILTIN([__builtin_bswap32]) AX_GCC_BUILTIN([__builtin_bswap64]) Acked-by: Alan Coopersmith -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa] glsl_compiler: Remove unused extra argument to printf in usage_fail
Flagged by Oracle's parfait static analyzer:
Error: Format string argument mismatch (CWE 628)
In call to printf with format string "usage: %s [options] \n\nPossible options are:\n"
Too many arguments for format string (got more than 1 arguments)
at line 285 of src/glsl/main.cpp in function 'usage_fail'.
Signed-off-by: Alan Coopersmith
---
src/glsl/main.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/main.cpp b/src/glsl/main.cpp
index ccac839..4b39c9e 100644
--- a/src/glsl/main.cpp
+++ b/src/glsl/main.cpp
@@ -281,9 +281,9 @@ usage_fail(const char *name)
const char *header =
"usage: %s [options] \n"
"\n"
"Possible options are:\n";
- printf(header, name, name);
+ printf(header, name);
for (const struct option *o = compiler_opts; o->name != 0; ++o) {
printf("--%s\n", o->name);
}
exit(EXIT_FAILURE);
--
1.7.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa] swrast: Build fix for Solaris
Ah yes, I see Jons patch now in https://bugs.freedesktop.org/show_bug.cgi?id=90147#c9 That looks like it should work for Solaris too, so whichever the Mesa developers prefer... -alan- On 05/15/15 07:16 PM, Jeremy Huddleston Sequoia wrote: Looks right to me. I think this was also mentioned in the bugzilla ticket where this change was committed from. Reviewed-by: Jeremy Huddleston Sequoia On May 15, 2015, at 19:05, Alan Coopersmith wrote: Fixes regression from commit 5b2d3480f57168d50ad24cf0b8c9244414bd3701 Signed-off-by: Alan Coopersmith CC: Jeremy Huddleston Sequoia --- configure.ac |1 + src/mesa/drivers/dri/swrast/swrast.c |4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cd3ba35..135dcb4 100644 --- a/configure.ac +++ b/configure.ac @@ -651,6 +651,7 @@ if test "x$enable_asm" = xyes; then fi AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"]) +AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"]) AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"]) dnl Check to see if dlopen is in default libraries (like Solaris, which diff --git a/src/mesa/drivers/dri/swrast/swrast.c b/src/mesa/drivers/dri/swrast/swrast.c index cbc946c..2d4bb70 100644 --- a/src/mesa/drivers/dri/swrast/swrast.c +++ b/src/mesa/drivers/dri/swrast/swrast.c @@ -62,7 +62,9 @@ #include "swrast/s_context.h" #include -#include +#ifdef HAVE_SYS_SYSCTL_H +# include +#endif const __DRIextension **__driDriverGetExtensions_swrast(void); -- 1.7.9.2 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa] swrast: Build fix for Solaris
Fixes regression from commit 5b2d3480f57168d50ad24cf0b8c9244414bd3701 Signed-off-by: Alan Coopersmith CC: Jeremy Huddleston Sequoia --- configure.ac |1 + src/mesa/drivers/dri/swrast/swrast.c |4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cd3ba35..135dcb4 100644 --- a/configure.ac +++ b/configure.ac @@ -651,6 +651,7 @@ if test "x$enable_asm" = xyes; then fi AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"]) +AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"]) AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"]) dnl Check to see if dlopen is in default libraries (like Solaris, which diff --git a/src/mesa/drivers/dri/swrast/swrast.c b/src/mesa/drivers/dri/swrast/swrast.c index cbc946c..2d4bb70 100644 --- a/src/mesa/drivers/dri/swrast/swrast.c +++ b/src/mesa/drivers/dri/swrast/swrast.c @@ -62,7 +62,9 @@ #include "swrast/s_context.h" #include -#include +#ifdef HAVE_SYS_SYSCTL_H +# include +#endif const __DRIextension **__driDriverGetExtensions_swrast(void); -- 1.7.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] c99_alloca.h: add case for __sun
On 03/ 3/15 07:10 AM, Brian Paul wrote: --- include/c99_alloca.h | 4 1 file changed, 4 insertions(+) diff --git a/include/c99_alloca.h b/include/c99_alloca.h index 575f719..ed66fda 100644 --- a/include/c99_alloca.h +++ b/include/c99_alloca.h @@ -35,6 +35,10 @@ # define alloca _alloca +#elif defined(__sun) + +# include + #else /* !defined(_MSC_VER) */ # include Reviewed-by: Alan Coopersmith -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] c99_alloca.h: Include stdlib.h on all non-Windows.
On 03/ 2/15 08:20 AM, Brian Paul wrote: On 03/01/2015 02:00 PM, Alan Coopersmith wrote: On 03/ 1/15 12:52 PM, Vinson Lee wrote: Fix build on FreeBSD. Bugzilla: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D89364&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=hAYbphGOl9qk5ZTtilbIV6JTR05VlIItJHubG_2VpBQ&s=R-R_SJeKgYFdNDUJIZ4sVeiM8wE49k5Pq4h5nhO2drk&e= Signed-off-by: Vinson Lee --- include/c99_alloca.h | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/include/c99_alloca.h b/include/c99_alloca.h index 7a81c50..575f719 100644 --- a/include/c99_alloca.h +++ b/include/c99_alloca.h @@ -35,13 +35,9 @@ # define alloca _alloca -#elif defined(__MINGW32__) - -# include - #else /* !defined(_MSC_VER) */ -# include +# include #endif /* !defined(_MSC_VER) */ Solaris defines alloca() in , not Alan, is there an #ifdef we can use on Solaris to pull in the right header? Because compiler standard #defines last longer than corporations, #elif defined(__sun) # include should work. (git grep will show you checks for __sun in a bunch of other Mesa files already. All compilers support __sun, gcc also provides __sun__ to fit in with it's normal naming scheme.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 03/ 1/15 02:31 PM, Emil Velikov wrote: - Considering the lack of -fvisibility, what is the normal visibility "level" - hidden or default ? If the latter this means that every library/module built exports a ton of internal symbols. Default, unless you pass the -xldscope=hidden flag to Studio, as the Xserver does: http://cgit.freedesktop.org/xorg/xserver/tree/configure.ac?id=xorg-server-1.17.1#n1840 - Using the __has_attribute macro looks great, although I would suspect that it will take a while for GCC and others to adopt(?). Probably, which is why X.Org uses it in addition to, instead of as a replacement for, the gcc version checks for now: http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e -alan- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 03/ 1/15 10:57 AM, Emil Velikov wrote:
On 01/03/15 18:30, Matt Turner wrote:
On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich wrote:
This patch simplifies the visibility compiler flag detection in configure and
makes it more generic to also support compilers other than gcc.
This simplification relies on the assumption that compilers support
-fvisibility=... if and only if they support
attribute(visibility("...")).
Hmm you're correct. I've naively assumed they both go hand in hand.
The latest Solaris Studio compilers support attribute(visibility), but
not -fvisibility. The absolute latest (12.4, released a few months back)
also support the clang has_attribute() extension for checking what's
supported (which is one of the reasons it's used in the X11/Xfuncproto.h
header in xproto 7.0.27 & later).
https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html
https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html
http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] c99_alloca.h: Include stdlib.h on all non-Windows.
On 03/ 1/15 12:52 PM, Vinson Lee wrote: Fix build on FreeBSD. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89364 Signed-off-by: Vinson Lee --- include/c99_alloca.h | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/include/c99_alloca.h b/include/c99_alloca.h index 7a81c50..575f719 100644 --- a/include/c99_alloca.h +++ b/include/c99_alloca.h @@ -35,13 +35,9 @@ # define alloca _alloca -#elif defined(__MINGW32__) - -# include - #else /* !defined(_MSC_VER) */ -# include +# include #endif /* !defined(_MSC_VER) */ Solaris defines alloca() in , not -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa 2/4] Avoid fighting with Solaris headers over isnormal()
On 02/17/15 10:21 AM, Emil Velikov wrote:
Hi Alan,
On 16/02/15 02:41, Alan Coopersmith wrote:
When compiling in C99 or C++11 modes, Solaris defines isnormal() as
a macro via , which causes the function definition to become
too mangled to compile.
Is this series sufficient to get mesa working again with Solaris ?
No. There are still two problems in src/glsl/nir/nir.h:
1) #pragma once needs to be replaced with a traditional header guard.
Since gcc listed #pragma once as deprecated, the Solaris Studio
compiler team decided it wasn't worth supporting, and this header
causes failures if it's included twice. (None of the other #pragma
once headers seem to cause problems in the build.)
@@ -25,6 +25,9 @@
*
*/
+#ifndef __NIR_H__
+#define __NIR_H__
+
#pragma once
#include "util/hash_table.h"
@@ -1566,3 +1569,4 @@ bool nir_opt_remove_phis(nir_shader *shader);
#ifdef __cplusplus
} /* extern "C" */
#endif
+#endif
2) Studio C++ does not allow structs to contain arrays with no dimensions.
I was able to hack around it by setting the array to zero size and
adding the the -features=zla flag to enable zero-length arrays:
@@ -640,7 +643,7 @@ typedef struct nir_alu_instr {
nir_instr instr;
nir_op op;
nir_alu_dest dest;
- nir_alu_src src[];
+ nir_alu_src src[0];
} nir_alu_instr;
/* is this source channel used? */
@@ -789,7 +792,7 @@ typedef struct {
nir_deref_var *variables[2];
- nir_src src[];
+ nir_src src[0];
} nir_intrinsic_instr;
/**
Also, I'm building with a very limited configuration and haven't checked the
rest: --without-gallium-drivers --disable-dri --disable-dri3
And I have to use CPPFLAGS=" -D__unix__" to make the #ifdefs work in
include/EGL/eglplatform.h, but it looked like Khronos needs to fix that,
not Mesa.
Afaics there is a similar redefinition of isnormal in
src/glsl/nir/nir_constant_expressions.py.
I have no idea what that's used for or if that's used in our builds.
The series looks like stable material imho. If you're planning to push
these yourself please add
Cc: "10.5"
Reviewed-by: Emil Velikov
Thanks
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa 1/4] Remove extraneous ; after DECL_TYPE usage
On 02/17/15 11:47 AM, Ian Romanick wrote:
Does this build problem still exist?
https://bugs.freedesktop.org/show_bug.cgi?id=86944
It does, until this series is applied.
"../../src/glsl/glsl_parser_extras.cpp", line 1455: Error: Badly formed
expression.
is what the third patch in my series fixes:
http://patchwork.freedesktop.org/patch/42582/
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa 1/4] Remove extraneous ; after DECL_TYPE usage
The macro is defined to provide a trailing ; so this caused the expansion to end in ";;" which made the Solaris Studio compilers issue warnings for every line of: "builtin_type_macros.h", line 113: Warning: extra ";" ignored. for every file that included the header, filling build logs with thousands of useless warnings. Signed-off-by: Alan Coopersmith --- src/glsl/builtin_type_macros.h | 66 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/src/glsl/builtin_type_macros.h b/src/glsl/builtin_type_macros.h index 236e1ce..7a21801 100644 --- a/src/glsl/builtin_type_macros.h +++ b/src/glsl/builtin_type_macros.h @@ -110,39 +110,39 @@ DECL_TYPE(sampler2DRectShadow, GL_SAMPLER_2D_RECT_SHADOW,GLSL_TYPE_SA DECL_TYPE(samplerExternalOES, GL_SAMPLER_EXTERNAL_OES, GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_EXTERNAL, 0, 0, GLSL_TYPE_FLOAT) -DECL_TYPE(image1D, GL_IMAGE_1D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image2D, GL_IMAGE_2D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image3D, GL_IMAGE_3D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_3D, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DRect, GL_IMAGE_2D_RECT, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(imageCube, GL_IMAGE_CUBE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(imageBuffer, GL_IMAGE_BUFFER, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_BUF,0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image1DArray,GL_IMAGE_1D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DArray,GL_IMAGE_2D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(imageCubeArray, GL_IMAGE_CUBE_MAP_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DMS, GL_IMAGE_2D_MULTISAMPLE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 0, GLSL_TYPE_FLOAT); -DECL_TYPE(image2DMSArray, GL_IMAGE_2D_MULTISAMPLE_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 1, GLSL_TYPE_FLOAT); -DECL_TYPE(iimage1D,GL_INT_IMAGE_1D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage2D,GL_INT_IMAGE_2D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage3D,GL_INT_IMAGE_3D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_3D, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage2DRect,GL_INT_IMAGE_2D_RECT, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimageCube, GL_INT_IMAGE_CUBE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimageBuffer,GL_INT_IMAGE_BUFFER, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_BUF,0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage1DArray, GL_INT_IMAGE_1D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(iimage2DArray, GL_INT_IMAGE_2D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(iimageCubeArray, GL_INT_IMAGE_CUBE_MAP_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(iimage2DMS, GL_INT_IMAGE_2D_MULTISAMPLE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 0, GLSL_TYPE_INT); -DECL_TYPE(iimage2DMSArray, GL_INT_IMAGE_2D_MULTISAMPLE_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_MS, 0, 1, GLSL_TYPE_INT); -DECL_TYPE(uimage1D,GL_UNSIGNED_INT_IMAGE_1D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage2D,GL_UNSIGNED_INT_IMAGE_2D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_2D, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage3D,GL_UNSIGNED_INT_IMAGE_3D, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_3D, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage2DRect,GL_UNSIGNED_INT_IMAGE_2D_RECT, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_RECT, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimageCube, GL_UNSIGNED_INT_IMAGE_CUBE, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_CUBE, 0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimageBuffer,GL_UNSIGNED_INT_IMAGE_BUFFER, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_BUF,0, 0, GLSL_TYPE_UINT); -DECL_TYPE(uimage1DArray, GL_UNSIGNED_INT_IMAGE_1D_ARRAY, GLSL_TYPE_IMAGE, GLSL_SAMPLER_DIM_1D, 0, 1, GLSL_TYPE_UINT); -DECL_TYPE(uimage2DArray,
[Mesa-dev] [PATCH:mesa 3/4] Use __typeof instead of typeof with Solaris Studio compilers
While the C compiler accepts typeof, C++ requires __typeof. Signed-off-by: Alan Coopersmith --- src/util/u_atomic.h |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index 192cc8d..d15398e 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -215,7 +215,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof(*v) == sizeof(uint64_t) ? atomic_inc_64((uint64_t *)(v)) : \ (assert(!"should not get here"), 0)) -#define p_atomic_inc_return(v) ((typeof(*v)) \ +#define p_atomic_inc_return(v) ((__typeof(*v)) \ sizeof(*v) == sizeof(uint8_t) ? atomic_inc_8_nv ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_inc_16_nv((uint16_t *)(v)) : \ sizeof(*v) == sizeof(uint32_t) ? atomic_inc_32_nv((uint32_t *)(v)) : \ @@ -229,7 +229,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof(*v) == sizeof(uint64_t) ? atomic_dec_64((uint64_t *)(v)) : \ (assert(!"should not get here"), 0)) -#define p_atomic_dec_return(v) ((typeof(*v)) \ +#define p_atomic_dec_return(v) ((__typeof(*v)) \ sizeof(*v) == sizeof(uint8_t) ? atomic_dec_8_nv ((uint8_t *)(v)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_dec_16_nv((uint16_t *)(v)) : \ sizeof(*v) == sizeof(uint32_t) ? atomic_dec_32_nv((uint32_t *)(v)) : \ @@ -243,7 +243,7 @@ _InterlockedExchangeAdd8(char volatile *addend, char value) sizeof(*v) == sizeof(uint64_t) ? atomic_add_64((uint64_t *)(v), (i)) : \ (assert(!"should not get here"), 0)) -#define p_atomic_cmpxchg(v, old, _new) ((typeof(*v)) \ +#define p_atomic_cmpxchg(v, old, _new) ((__typeof(*v)) \ sizeof(*v) == sizeof(uint8_t) ? atomic_cas_8 ((uint8_t *)(v), (uint8_t )(old), (uint8_t )(_new)) : \ sizeof(*v) == sizeof(uint16_t) ? atomic_cas_16((uint16_t *)(v), (uint16_t)(old), (uint16_t)(_new)) : \ sizeof(*v) == sizeof(uint32_t) ? atomic_cas_32((uint32_t *)(v), (uint32_t)(old), (uint32_t)(_new)) : \ -- 1.7.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa 2/4] Avoid fighting with Solaris headers over isnormal()
When compiling in C99 or C++11 modes, Solaris defines isnormal() as
a macro via , which causes the function definition to become
too mangled to compile.
Signed-off-by: Alan Coopersmith
---
src/glsl/ir_constant_expression.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_constant_expression.cpp
b/src/glsl/ir_constant_expression.cpp
index 1e8b3a3..864cb80 100644
--- a/src/glsl/ir_constant_expression.cpp
+++ b/src/glsl/ir_constant_expression.cpp
@@ -44,7 +44,7 @@ static int isnormal(double x)
{
return _fpclass(x) == _FPCLASS_NN || _fpclass(x) == _FPCLASS_PN;
}
-#elif defined(__SUNPRO_CC)
+#elif defined(__SUNPRO_CC) && !defined(isnormal)
#include
static int isnormal(double x)
{
--
1.7.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa 4/4] Make _mesa_swizzle_and_convert argument types in .c match those in .h
Caused Solaris Studio compilers to fail to build with errors about
incompatible function redefinitions.
Signed-off-by: Alan Coopersmith
---
src/mesa/main/format_utils.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c
index 00061de..810bb16 100644
--- a/src/mesa/main/format_utils.c
+++ b/src/mesa/main/format_utils.c
@@ -1423,8 +1423,8 @@ convert_int(void *void_dst, int num_dst_channels,
* \param[in] count the number of pixels to convert
*/
void
-_mesa_swizzle_and_convert(void *void_dst, GLenum dst_type, int
num_dst_channels,
- const void *void_src, GLenum src_type, int
num_src_channels,
+_mesa_swizzle_and_convert(void *void_dst, enum mesa_array_format_datatype
dst_type, int num_dst_channels,
+ const void *void_src, enum
mesa_array_format_datatype src_type, int num_src_channels,
const uint8_t swizzle[4], bool normalized, int count)
{
if (swizzle_convert_try_memcpy(void_dst, dst_type, num_dst_channels,
--
1.7.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] videos of X, DRM, & Mesa talks from LCA2015
The amazing 2015 linux.conf.au video team has already posted all the videos from the talks at this years conference - you can find them on their YouTube channel at https://www.youtube.com/user/linuxconfau2015 or via the links on http://lca2015.linux.org.au/ Talks of particular relevance to Xorg, DRI, and Mesa developers include: Botching up IOCTLs Daniel Vetter (Intel) https://www.youtube.com/watch?v=WnqXHs_tGR4 http://lca2015.linux.org.au/schedule/30266/view_talk Slides: http://people.freedesktop.org/~danvet/presentations/lca-2015.pdf Displayport MST: why do my laptop dockoutputs not work? David Airlie (Red Hat) https://www.youtube.com/watch?v=6301tGNs9Dc http://lca2015.linux.org.au/schedule/30303/view_talk Slides: http://lca2015.linux.org.au/slides/93/lca2015mst.odp Open-source OpenGL on the Raspberry Pi Eric Anholt (Broadcom) https://www.youtube.com/watch?v=EXDeketJNdk http://lca2015.linux.org.au/schedule/30256/view_talk Slides: http://lca2015.linux.org.au/slides/125/lca2015-rpi.pdf Putting the Polish on Glamor Keith Packard (HP) https://www.youtube.com/watch?v=dXR-MVQvQZw http://lca2015.linux.org.au/schedule/30108/view_talk Slides: http://lca2015.linux.org.au/slides/64/glamor.odp Reducing GLSL Compiler Memory Usage (or Fitting 5kg of Potatoes in a 2kg Bag) Ian Romanick (Intel) https://www.youtube.com/watch?v=K-5DTAD2Isk http://lca2015.linux.org.au/schedule/30149/view_talk Slides: http://people.freedesktop.org/~idr/LCA2015/ And semi-related is a talk from former-SFLC-lawyer Karen Sandler on the troubles open source groups have had with non-profit status that have been pushing the X.Org Foundation to join a larger group to leverage their lawyers and accountants in meeting all the needed requirements, resulting in our current moves to become part of SPI: https://www.youtube.com/watch?v=Z5uY01QlyK0 http://lca2015.linux.org.au/schedule/30178/view_talk -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa] Bracket arguments to tr so they work with Solaris tr
On 01/ 4/15 11:34 AM, Emil Velikov wrote: Hi Alan, On 03/01/15 22:28, Alan Coopersmith wrote: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html#index-g_t_0040command_007btr_007d-1842 Without this fix, egl fails to build on Solaris, with the error: :0:22: error: '_EGL_PLATFORM_x11' undeclared (first use in this function) egldisplay.c:207:31: note: in expansion of macro '_EGL_NATIVE_PLATFORM' native_platform = _EGL_NATIVE_PLATFORM; ^ Trivial note - the sed command has picked up the missing -e parameter ;) Oh, whoops. That was left from my failed attempt to replace tr with a -e 'y/..' flag to sed. I'm thinking about using $SED consistently throughout (and add the missing -e) in a separate patch(es). Any objections ? Sounds good to me. Reviewed-by: Emil Velikov If you're planning to push this please add the following line. Alternatively I'll add it as I push it in a couple of days. Cc: 10.3 10.4 It's been a couple years since I've pushed to mesa, so I'm happy to let you do the push so it's done right. Thanks, -alan- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa] Bracket arguments to tr so they work with Solaris tr
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html#index-g_t_0040command_007btr_007d-1842 Without this fix, egl fails to build on Solaris, with the error: :0:22: error: '_EGL_PLATFORM_x11' undeclared (first use in this function) egldisplay.c:207:31: note: in expansion of macro '_EGL_NATIVE_PLATFORM' native_platform = _EGL_NATIVE_PLATFORM; ^ Signed-off-by: Alan Coopersmith --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index b5805f6..a008cbf 100644 --- a/configure.ac +++ b/configure.ac @@ -1584,7 +1584,7 @@ done # libEGL wants to default to the first platform specified in # ./configure. parse that here. if test "x$egl_platforms" != "x"; then -FIRST_PLATFORM_CAPS=`echo $egl_platforms | sed 's| .*||' | tr 'a-z' 'A-Z'` +FIRST_PLATFORM_CAPS=`echo $egl_platforms | sed -e 's| .*||' | tr '[[a-z]]' '[[A-Z]]'` EGL_NATIVE_PLATFORM="_EGL_PLATFORM_$FIRST_PLATFORM_CAPS" else EGL_NATIVE_PLATFORM="_EGL_INVALID_PLATFORM" -- 1.7.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Finishing make distcheck
On 12/11/14 01:02 AM, Emil Velikov wrote:
* Don't ship anything but a tar.xz tarball.
Linux, *BSD and WindowsXP+ have/ship programs that support the format
for more than 5 years.
Solaris 11 has been shipping xz support for the past 3 years, so that's
fine with us too.
P.S. Graduation day tomorrow - hell yeah
Congratulations!
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
If it helps explain things, X.Org's versioning scheme is documented in: http://www.x.org/releases/X11R7.7/doc/xorg-docs/Versions.html -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ Open source project]
On 06/17/14 12:35 PM, Thomas Helland wrote: I think the application date for GSoC is long passed (so no pay :/ ), Yes - we're about to hit the midpoint of GSoC - applications were done months ago, selections made already, and students should be making good progress by now. The X.Org Foundation does offer a more flexible timeline for EVoC projects, which can include Mesa work, but it's also a bit late if someone was applying for EVoC for the summer now, as the typical turnaround of a month to put together an application and get it approved would not leave much time left to do the work before the next school term begins in most places. (It's not impossible to apply still, if your next school term doesn't start until later in the year, just less likely for most students to make the schedule work.) (And a month may be on the short side if you aren't already familiar with Mesa, to take into account learning enough about the project to be able to determine what a reasonable proposal could cover in the time alloted and do the usual submission of a patch or two first to show you have enough skills with the tools, code, & programming language to make a start at it. People already working with the code base have less to learn and work through there than those coming at it for the first time.) -- -Alan Coopersmith- alan.coopersm...@oracle.com X.Org Foundation, Board of Directors - http://www.x.org/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa] Use -z defs instead of --no-undefined on Solaris
While recent versions of the Solaris linker support --no-undefined, older ones do not, and even current ones get confused if the Makefile passes one form and libtool sneaks in the other. Signed-off-by: Alan Coopersmith --- configure.ac |2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 9c64400..29bfbc4 100644 --- a/configure.ac +++ b/configure.ac @@ -354,6 +354,8 @@ dnl case "$host_os" in openbsd* | darwin* ) LD_NO_UNDEFINED="" ;; +solaris*) +LD_NO_UNDEFINED="-Wl,-z,defs" ;; *) LD_NO_UNDEFINED="-Wl,--no-undefined" ;; esac -- 1.7.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Contribution
On 05/10/14 11:52 AM, Anish Kanchan wrote: Hello, I am Anish Kanchan (IRC nick:opensourcer), a student from Mumbai University, India. I wish to contribute to X.ORG <http://X.ORG>. I have gone through the ideas page and saw the list of projects. I have programmed mainly in C++, Java, PHP, MySQL, HTML, CSS and Javascript in my college projects. The Wiki page suggests that all the projects of X.ORG <http://X.ORG> need knowledge of C and C++. I would like to choose a simpler project to begin with. Hence I think "Improved application of GLSL complier optimizations" would be a good choice. Could someone tell me how do I go about it, which documents to read and how to set up the development environment. The GLSL compilers are actually part of the affiliated Mesa project, which has it's own mailing list, mesa-dev (cc'ed here) due to the amount of traffic. Fortunately, Mesa also has a simpler build environment to set up than the Xorg server, as it has less dependencies - you can read about how to do that at: http://www.mesa3d.org/install.html and in the pages under "Developer Topics" in the left bar on that page (scroll down a bit to get to it). -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Mark drmServerInfo.debug_print with printf attribute
On 12/11/13 01:17 PM, Keith Packard wrote:
I stole the conditional for _X_ATTRIBUTE_PRINTF from xproto and
changed the name to _DRM_ATTRIBUTE_PRINTF to avoid future conflicts.
Signed-off-by: Keith Packard
---
xf86drm.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/xf86drm.h b/xf86drm.h
index 1e763a3..0bf205f 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -92,8 +92,15 @@ extern "C" {
typedef unsigned int drmSize, *drmSizePtr; /**< For mapped
regions */
typedef void *drmAddress, **drmAddressPtr; /**< For mapped regions */
+/* Added in X11R6.9, so available in any version of modular xproto */
You should drop that line - those comments are used for us to figure out which
xproto version to list in the pkg-config requirements when using newer _X_*
macros out of Xfuncproto.h, so doesn't make sense here.
Also be warned that using a macro name starting with an _ will cause you to get
complaints about violating the "reserved for the implementation" rule in the
ANSI/ISO C standards from people who consider the implementation to solely be
the compiler, not the OS. https://bugs.freedesktop.org/show_bug.cgi?id=70686
for example.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Janitorial work: no more intel_context.[ch]; tidying
On 10/ 2/13 01:27 PM, Ian Romanick wrote: On 10/02/2013 12:51 PM, Matt Turner wrote: On Wed, Oct 2, 2013 at 11:02 AM, Ian Romanick wrote: (Adding Alan to the CC list.) On 10/01/2013 10:51 PM, Vinson Lee wrote: On Mon, Sep 30, 2013 at 10:21 PM, Kenneth Graunke wrote: On 09/27/2013 06:24 PM, Emil Velikov wrote: * With the recent split of the intel driver codebase, the new i965 headers has been getting a bunch of #pragma once over the standard #ifndef _HEADER_H_... Are those intentional ? Yup, that's intentional. "#pragma once" doesn't require inventing a unique #define name, is less typing, and is faster on some compilers. I actually forgot that it wasn't standard. It's supported basically everywhere, though, so I'd be really shocked if it caused problems. Oracle Solaris Studio does not support "#pragma once". Is there *any* reason to use that compiler over GCC? This isn't the first time that we've discovered it to be lacking some feature that GCC, clang, and Visual Studio all support. :( Before we go down this rabbit hole -- Vinson said it doesn't support #pragma once. He didn't say it caused problems. I don't expect it is, since we're already using it and have been for a long time. It probably just means that you have to to #pragma once along with the standard #ifndef ... #endif wrapper. Do the headers contain anything that breaks if they're read multiple times? If the #pragma once is ignored, does everything just work? Understood. The changes in this patch series use only the pragma, and we've identified some benefits of that approach. I'd like to have those benefits, but this compiler seems to stand in the way. We've had the "do we need to support this compiler" for other compilers in the past. Sometimes the answer is yes, and sometimes the answer is no. There's the benefit you always get of another unique set of compiler warnings helping find bugs - some will overlap other compilers, some won't - how many will be useful is hard to guess. And if there were any Mesa users who cared about performance of the software rasterizer on recent SPARC systems, the Solaris Studio compiler is usually ahead of gcc since they work with the CPU designers during development. As a Solaris package maintainer, I can say that we do like to keep stuff running with Solaris Studio when we can, since we can get direct support for that if compiler issues occur, but looking in our current Mesa 9 packages I see we're using gcc to build those already, so I can't claim it's that essential to us in shipping Mesa here. (I don't remember why gcc is used here, I would have to ask Niveditha, who maintains our Mesa packages.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] R300 'make check' build failure on master and 9.2
On 08/ 6/13 10:12 AM, Ian Romanick wrote: We also need a build bot that will build and 'make check' every commit. Ugh. :( Freedesktop.org already hosts a tinderbox server for X.Org modules - it shouldn't be hard to either add Mesa to that or use that to set up one for Mesa. I think Eric Anholt did the original setup and may be able to help you there. (Though I've just noticed that http://tinderbox.x.org/ is offline at the moment, guess I'll poke the sitewranglers about that.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa 1/2] integer overflow in XF86DRIOpenConnection() [CVE-2013-1993 1/2]
On 05/23/13 11:07 AM, Ian Romanick wrote:
On 05/23/2013 08:44 AM, Alan Coopersmith wrote:
if (rep.length) {
- if (!(*busIdString = calloc(rep.busIdStringLength + 1, 1))) {
+ if (rep.busIdStringLength < INT_MAX)
+ *busIdString = calloc(rep.busIdStringLength + 1, 1);
But calloc takes size_t, and size_t is unsigned. That makes this look a little
weird. The problem is when rep.busIdStringLength is INT_MAX, the problem occurs
when it's UINT_MAX. Right?
Right - UINT_MAX would cause overflow, but we used INT_MAX in most of the checks
for these in the X libraries to avoid issues if other parts of the code try to
treat it as signed, and really, once your string length hits 2gb you're in
ludicrous territory anyway, and best not to waste time trying to map all those
pages.
+ else
+ *busIdString = NULL;
+ if (*busIdString == NULL) {
_XEatData(dpy, ((rep.busIdStringLength + 3) & ~3));
Doesn't this have a similar overflow issue? If rep.busIdStringLength is
UINT_MAX-2, the result is 0.
Yes - in that case though you'll just not throw away enough data, and on
modern systems, trigger an xcb assertion that there's unread data left in
the response. In the X libraries I added a new _XEatDataWords API that
takes the packet length from req.length and applies overflow checks in one
place instead of every caller, but I didn't take the time to figure out
how to add new autoconf checks to Mesa to do that here.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa 2/2] integer overflow in XF86DRIGetClientDriverName() [CVE-2013-1993 2/2]
clientDriverNameLength is a CARD32 and needs to be bounds checked before
adding one to it to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.
Reported-by: Ilja Van Sprundel
Signed-off-by: Alan Coopersmith
---
src/glx/XF86dri.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/glx/XF86dri.c b/src/glx/XF86dri.c
index 8f53bd7..56e3557 100644
--- a/src/glx/XF86dri.c
+++ b/src/glx/XF86dri.c
@@ -305,9 +305,11 @@ XF86DRIGetClientDriverName(Display * dpy, int screen,
*ddxDriverPatchVersion = rep.ddxDriverPatchVersion;
if (rep.length) {
- if (!
- (*clientDriverName =
- calloc(rep.clientDriverNameLength + 1, 1))) {
+ if (rep.clientDriverNameLength < INT_MAX)
+ *clientDriverName = calloc(rep.clientDriverNameLength + 1, 1);
+ else
+ *clientDriverName = NULL;
+ if (*clientDriverName == NULL) {
_XEatData(dpy, ((rep.clientDriverNameLength + 3) & ~3));
UnlockDisplay(dpy);
SyncHandle();
--
1.7.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa 0/2] integer overflows in GLX DRI code [CVE-2013-1993]
The X.Org security team has been notified by a security researcher of bugs in the protocol handling code across libX11 & many of its extension libraries. These could be exploited in X clients that are setuid or otherwise running with raised privileges, if a user could run them with their display set to a Xserver they've modified to exploit them (perhaps a custom Xephyr or remote Xorg). More details about these issues can be found in our advisory posting at http://www.x.org/wiki/Development/Security/Advisory-2013-05-23 . One of the extensions affected is DRI, for which the code is not in a shared libXdri, but copied into several locations, including Mesa's GLX library. This series of patches corrects these bugs in Mesa's copy. Alan Coopersmith (2): integer overflow in XF86DRIOpenConnection() [CVE-2013-1993 1/2] integer overflow in XF86DRIGetClientDriverName() [CVE-2013-1993 2/2] src/glx/XF86dri.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- 1.7.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa 1/2] integer overflow in XF86DRIOpenConnection() [CVE-2013-1993 1/2]
busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buffer.
Reported-by: Ilja Van Sprundel
Signed-off-by: Alan Coopersmith
---
src/glx/XF86dri.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/glx/XF86dri.c b/src/glx/XF86dri.c
index b1cdc9b..8f53bd7 100644
--- a/src/glx/XF86dri.c
+++ b/src/glx/XF86dri.c
@@ -43,6 +43,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include
#include
#include "xf86dristr.h"
+#include
static XExtensionInfo _xf86dri_info_data;
static XExtensionInfo *xf86dri_info = &_xf86dri_info_data;
@@ -201,7 +202,11 @@ XF86DRIOpenConnection(Display * dpy, int screen,
drm_handle_t * hSAREA,
}
if (rep.length) {
- if (!(*busIdString = calloc(rep.busIdStringLength + 1, 1))) {
+ if (rep.busIdStringLength < INT_MAX)
+ *busIdString = calloc(rep.busIdStringLength + 1, 1);
+ else
+ *busIdString = NULL;
+ if (*busIdString == NULL) {
_XEatData(dpy, ((rep.busIdStringLength + 3) & ~3));
UnlockDisplay(dpy);
SyncHandle();
--
1.7.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal: allow hidden security bugs on Mesa's Bugzilla
On 11/20/12 09:29 AM, Benoit Jacob wrote: > Both solutions are poor, and a better solution would be for Mesa's > bugzilla to allow hidden security bugs so we could work there. Given > that security bug discussion can't be open, that is the "least bad" > solution possible. For what it's worth, Mesa wouldn't be the first project on the freedesktop bugzilla to enable this - security bugs filed against X.Org software are kept private to the X.Org security team until we publish our advisory. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] Don't cast the return value of malloc/realloc
On 09/ 5/12 10:16 AM, Matt Turner wrote: > On Wed, Sep 5, 2012 at 7:30 AM, Brian Paul wrote: >> So assigning a void pointer to a non-void pointer is legal in C and illegal >> in C++. I seem to recall some people compiling all of Mesa with C++ in some >> situations in the past. Also, there were some C compiler(s) years ago that >> required these casts (can't remember which). > > That would be interesting to know. The historical problem I remember was pre-ANSI C89, when compilers either didn't have (void *) so had malloc return (char *) or didn't have a header providing a declaration of malloc before C added function prototypes. I don't think any such compilers can still be used to build Mesa. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] FOSDEM2013: DevRoom or not?
On 08/12/12 06:50 AM, Luc Verhaegen wrote: > * By the 28th of september, i need 6 committed speakers, otherwise i > will not apply for a DevRoom. 6 people need to apply for a talk slot > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. > This "definitely" means: > * Don't knowingly plan anything else for this weekend. Which unfortunately due to scheduling this year, means not attending the end of linux.conf.au, since that runs January 28 to February 2nd, on the other end of the planet (a very long flight away from Brussels). > * Come to FOSDEM even if your corporation does not fund you (though > feel free to contact the board individually for funding) Yes, as always, the X.Org Foundation Board is willing to fund travel & lodging expenses for those who don't have other funding (including those working for companies who have declined to pay for travel). Contact bo...@foundation.x.org with requests. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] FOSS.in Call for Participation
FOSS.in, India's biggest open source conference, has their CFP out
for this year's conference (Nov. 29 - Dec.1 in Bangalore):
http://foss.in/participate/call-for-participation
Like FOSDEM, it's all open source projects, not any particular area.
If someone in the region wanted to present on a topic related to the
free graphics stack (X.Org, Mesa, DRI, Wayland, etc.) and the only
thing stopping them was travel expenses, the X.Org Board may be willing
to sponsor a reasonable travel budget for those who are accepted into
the program. (No guarantees until you actually ask us - just saying
we're happy to discuss it, and have provided similar funding in the
past for people who needed it to present at FOSDEM & similar venues.)
Send mail to bo...@foundation.x.org with any questions or proposals.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
On 06/25/12 12:09 AM, Michel Dänzer wrote: > On Sam, 2012-06-23 at 14:55 -0700, Alan Coopersmith wrote: >> On 06/23/12 01:43 PM, Vinson Lee wrote: >>> On Wed, Jun 20, 2012 at 6:49 AM, Alan Coopersmith >>> wrote: >>>> On 06/19/12 11:34 PM, Vinson Lee wrote: >>>>> The GLX headers on Solaris are not recent enough. >>>> >>>> Huh? Which Solaris? Solaris 11 ships with X.Org's glproto 1.4.10 - >>>> how new do you need? Or what headers do you need if not glproto? >>>> >>>> (Not that I know anyone who uses scons, so maybe this doesn't matter.) >>> >>> Compiling src/glx/glxext.c ... >>> "src/glx/glxext.c", line 136: undefined symbol: xGLXBufferSwapComplete2 >> >> Looks like that was defined in 1.4.14 so I guess the headers shipped on >> Solaris 11 are too old. >> >> Though really, this whole scons setup seems like a really really really >> bad idea - going back to the imake model of having to manually keep track >> of what each distro or OS ships, and in this case deciding that because >> one version of an OS ships with an older header than you need that no >> version ever will ship it, and that no user will ever install a newer >> version on their own - this is why X.Org moved from imake to autoconf, >> automake, pkg-config, etc. so that we detected what was actually present, >> not what someone upstream thought would be there. >> >> I admit I've completely ignored everything involving scons as it seemed >> irrelevant to me, but I really have to wonder why anyone thinks it's a >> good idea to take such a huge step backwards in dependency/requirements >> detection and management. > > So you admit you don't really know anything about SCons, but write a > diatribe about its alleged shortcomings anyway? Nice. ;) About "this scons setup" - i.e. the way it's being used here, using the kernel name as an indication of what libraries are available, assuming all kernels with the same name ship with the same set of libraries. (Why isn't "linux" in this list of incompatible kernels? I bet RHEL 5 and Ubuntu 10.04 don't ship with the needed glproto from 2011.) > Of course it's possible to check with pkg-config or whatever with SCons, > and I agree that would probably be a better solution. Great. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
On 06/23/12 01:43 PM, Vinson Lee wrote: > On Wed, Jun 20, 2012 at 6:49 AM, Alan Coopersmith > wrote: >> On 06/19/12 11:34 PM, Vinson Lee wrote: >>> The GLX headers on Solaris are not recent enough. >> >> Huh? Which Solaris? Solaris 11 ships with X.Org's glproto 1.4.10 - >> how new do you need? Or what headers do you need if not glproto? >> >> (Not that I know anyone who uses scons, so maybe this doesn't matter.) >> >> -- >>-Alan Coopersmith- alan.coopersm...@oracle.com >> Oracle Solaris Engineering - http://blogs.oracle.com/alanc > > > Compiling src/glx/glxext.c ... > "src/glx/glxext.c", line 136: undefined symbol: xGLXBufferSwapComplete2 Looks like that was defined in 1.4.14 so I guess the headers shipped on Solaris 11 are too old. Though really, this whole scons setup seems like a really really really bad idea - going back to the imake model of having to manually keep track of what each distro or OS ships, and in this case deciding that because one version of an OS ships with an older header than you need that no version ever will ship it, and that no user will ever install a newer version on their own - this is why X.Org moved from imake to autoconf, automake, pkg-config, etc. so that we detected what was actually present, not what someone upstream thought would be there. I admit I've completely ignored everything involving scons as it seemed irrelevant to me, but I really have to wonder why anyone thinks it's a good idea to take such a huge step backwards in dependency/requirements detection and management. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Do not build glx on Solaris.
On 06/19/12 11:34 PM, Vinson Lee wrote:
> The GLX headers on Solaris are not recent enough.
Huh? Which Solaris? Solaris 11 ships with X.Org's glproto 1.4.10 -
how new do you need? Or what headers do you need if not glproto?
(Not that I know anyone who uses scons, so maybe this doesn't matter.)
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Change vendor string to "Intel(R) Open Source Technology Center".
On 05/31/12 04:28 PM, Roland Mainz wrote:
> On Fri, Jun 1, 2012 at 1:19 AM, Kenneth Graunke wrote:
>>switch (name) {
>>case GL_VENDOR:
>> - return (GLubyte *) "Tungsten Graphics, Inc";
>> + return (GLubyte *) "Intel® Open Source Technology Center";
>> break;
>
> Uhm... isn't "®" a character outside the ASCII range ? Some compiles
> might choke on this, i.e. the Sun Workshop/Forte/Studio compilers
> require -xcsi ("... This option allows the C compiler to accept source
> code written in locales that do not conform to the ISO C source
> character code requirements. These locales include ja_JP.PCK ...") to
> avoid occasional hiccups.
I don't remember having any problems with the Studio compilers using UTF-8
characters, but they do break down if you use other encodings that appear
to cause invalid UTF-8 sequences.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] anongit.freedesktop.org not available?
On 02/ 1/12 08:52 PM, Alexandre Demers wrote: Hi, I've been trying all day to sync sources from anongit.freedesktop.org (dri and mesa) and it always ends up by a time out. Is there a problem with the server or the address? Yes. Others have reported on IRC that it works if you force the hostnames to resolve to 131.252.210.176 instead of the DNS reported 131.252.210.161. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/12] rbug: Silence warning
On 01/ 9/12 02:53 PM, Jakob Bornecrantz wrote:
- struct pipe_shader_state pss = { 0 };
+ struct pipe_shader_state pss;
+ memset(&pss, 0, sizeof(pss));
Those do the same thing, just via a function call instead of compiler builtin.
What warning is being silenced by that change?
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XCB-only GLX protocol?
On 11/28/11 18:56, Jakob Bornecrantz wrote: On Mon, Nov 28, 2011 at 3:13 AM, Ian Romanick wrote: All, I'm starting to work on GLX_ARB_create_context. This extension and the layered GLX_ARB_create_context_profile extension add some GLX protocol. Is there any reason to keep supporting non-XCB protocol? Are there any platforms that can't / don't use XCB for X protocol? I'm not planning to gut any non-XCB code yet, but that would happen eventually. I just don't want to implement all of the protocol twice. That seems like an unnecessary hassle. Opinions? No problems with me but I think you should get sign-off from various platform stakeholders before doing it (BSD, Mac, Cygwin). Jeremy and who does cygwin? From the Solaris platform point of view, XCB is fine with me, as we have xcb 1.6 on Solaris 11, and no longer update the Mesa version in Solaris 10 (which has no XCB included - those who want to build new versions themselves should be able to build xcb for Solaris 10 as well). Most applications still use libX11, but since we ship the libX11 1.4.x built on top of libxcb, the standard xcb/xlib handoff calls should work just fine. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: add hard limits for the number of varyings and uniforms for the linker
On 11/24/11 05:25, Dave Airlie wrote: On UNIX malloc generally hasn't returned NULL since overcommit was invented, what happens now is some time in the future you attempt to use a page and your app dies. s/UNIX/Linux/ - other Unixes still prefer reliability over random OOM crashes. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] FOSDEM 2012 DevRoom!
On 11/14/11 03:28, Luc Verhaegen wrote: Great News! We got ourselves another devroom! We are sharing it with the openICC project, we have currently pencilled in Xorg/Mesa/Wayland for saturday (we should be able to get the devroom in the morning already this year!) and sunday morning, and sunday afternoon is (currently) dedicated to openICC. The initial wiki page has been put in place at: http://wiki.x.org/wiki/fosdem2012 We already have 5.5 speakers in place (Matthieu's proposal was basically to satisfy the deadline i put in place for requesting the devroom), so we need at least 5 more speakers before the 14th of January 2012. So if you are corporate, start, or continue, talking to your managers about getting sent to FOSDEM! And if you don't have corporate funding, and need sponsorship in order to attend (especially if you're volunteering to present, whether about X, Mesa, DRI, or Wayland), please contact bo...@foundation.x.org as soon as possible to make your request. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/auxiliary/util: Solaris also has standard Unix sockets
Signed-off-by: Alan Coopersmith
---
src/gallium/auxiliary/util/u_network.c |9 ++---
src/gallium/auxiliary/util/u_network.h |3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_network.c
b/src/gallium/auxiliary/util/u_network.c
index 77f2c5f..45b3691 100644
--- a/src/gallium/auxiliary/util/u_network.c
+++ b/src/gallium/auxiliary/util/u_network.c
@@ -6,7 +6,8 @@
#if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
# include
# include
-#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) ||
defined(PIPE_OS_APPLE) || defined(PIPE_OS_CYGWIN)
+#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || \
+ defined(PIPE_OS_APPLE) || defined(PIPE_OS_CYGWIN) ||
defined(PIPE_OS_SOLARIS)
# include
# include
# include
@@ -54,7 +55,8 @@ u_socket_close(int s)
if (s < 0)
return;
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_APPLE)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) \
+|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_SOLARIS)
shutdown(s, SHUT_RDWR);
close(s);
#elif defined(PIPE_SUBSYSTEM_WINDOWS_USER)
@@ -169,7 +171,8 @@ u_socket_listen_on_port(uint16_t portnum)
void
u_socket_block(int s, boolean block)
{
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_APPLE)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) \
+|| defined(PIPE_OS_APPLE) || defined(PIPE_OS_SOLARIS)
int old = fcntl(s, F_GETFL, 0);
if (old == -1)
return;
diff --git a/src/gallium/auxiliary/util/u_network.h
b/src/gallium/auxiliary/util/u_network.h
index 187dcab..61fe9a3 100644
--- a/src/gallium/auxiliary/util/u_network.h
+++ b/src/gallium/auxiliary/util/u_network.h
@@ -6,7 +6,8 @@
#if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
# define PIPE_HAVE_SOCKETS
-#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) ||
defined(PIPE_OS_APPLE)
+#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || \
+defined(PIPE_OS_APPLE) || defined(PIPE_OS_SOLARIS)
# define PIPE_HAVE_SOCKETS
#endif
--
1.7.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] Convert additional GNUC_MINOR checks to multiplied version
Signed-off-by: Alan Coopersmith
---
src/mesa/main/imports.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 9cb6c6c..797f357 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -453,7 +453,7 @@ static inline int32_t
_mesa_next_pow_two_32(uint32_t x)
{
#if defined(__GNUC__) && \
- ((__GNUC__ == 3 && __GNUC_MINOR__ >= 4) || __GNUC__ >= 4)
+ ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
uint32_t y = (x != 1);
return (1 + y) << ((__builtin_clz(x - y) ^ 31) );
#else
@@ -472,7 +472,7 @@ static inline int64_t
_mesa_next_pow_two_64(uint64_t x)
{
#if defined(__GNUC__) && \
- ((__GNUC__ == 3 && __GNUC_MINOR__ >= 4) || __GNUC__ >= 4)
+ ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
uint64_t y = (x != 1);
if (sizeof(x) == sizeof(long))
return (1 + y) << ((__builtin_clzl(x - y) ^ 63));
@@ -499,7 +499,7 @@ static inline GLuint
_mesa_logbase2(GLuint n)
{
#if defined(__GNUC__) && \
- ((__GNUC__ == 3 && __GNUC_MINOR__ >= 4) || __GNUC__ >= 4)
+ ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */
return (31 - __builtin_clz(n | 1));
#else
GLuint pos = 0;
--
1.7.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] Fix gcc version checks for _mesa_bitcount
- Fix _GNUC__ typo in both checks - Fix logic error in check for gcc < 3.4 that breaks for gcc 2.x & older Without this fix, builds with gcc 3.4.x end up depending on undefined _mesa_bitcount instead of gcc's __builtin_popcount. NOTE: This is a candidate for the stable branches. Signed-off-by: Alan Coopersmith --- src/mesa/main/imports.c |2 +- src/mesa/main/imports.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c index 345a1c5..2469e42 100644 --- a/src/mesa/main/imports.c +++ b/src/mesa/main/imports.c @@ -514,7 +514,7 @@ _mesa_ffsll(int64_t val) #endif #if !defined(__GNUC__) ||\ - ((_GNUC__ == 3 && __GNUC_MINOR__ < 4) && __GNUC__ < 4) + ((__GNUC__ * 100 + __GNUC_MINOR__) < 304) /* Not gcc 3.4 or later */ /** * Return number of bits set in given GLuint. */ diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h index 20fa148..9cb6c6c 100644 --- a/src/mesa/main/imports.h +++ b/src/mesa/main/imports.h @@ -576,7 +576,7 @@ _mesa_init_sqrt_table(void); #define _mesa_ffs(i) ffs(i) #define _mesa_ffsll(i) ffsll(i) -#if ((_GNUC__ == 3 && __GNUC_MINOR__ >= 4) || __GNUC__ >= 4) +#if ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) /* gcc 3.4 or later */ #define _mesa_bitcount(i) __builtin_popcount(i) #define _mesa_bitcount_64(i) __builtin_popcountll(i) #else -- 1.7.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix _GNUC__ typo in check for gcc 3.x for _mesa_bitcount
On 10/21/11 12:30, Brian Paul wrote: How about doing something like: #if __GNUC__ * 10 + __GNUC_MINOR__ < 34 I find that a bit easier to follow. The X.Org headers I'm more familiar with do something very much like that, just with a little protection against the possibility of gcc someday hitting double-digit releases (4.10 for instance): #if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 303) It looks like mesa already has that style used as well, in src/gallium/include/pipe/p_config.h & include/KHR/khrplatform.h. I'll submit a new patch to adopt this style for the mesa_bitcount checks. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix _GNUC__ typo in check for gcc 3.x for _mesa_bitcount
On 10/20/11 18:30, Jason Wood wrote: On 10/20/2011 06:58 PM, Alan Coopersmith wrote: Without this fix, builds with gcc 3.4.x end up depending on undefined _mesa_bitcount instead of gcc's __builtin_popcount. NOTE: This is a candidate for the stable branches. Signed-off-by: Alan Coopersmith --- src/mesa/main/imports.c | 2 +- src/mesa/main/imports.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c index 345a1c5..1c44727 100644 --- a/src/mesa/main/imports.c +++ b/src/mesa/main/imports.c @@ -514,7 +514,7 @@ _mesa_ffsll(int64_t val) #endif #if !defined(__GNUC__) ||\ - ((_GNUC__ == 3&& __GNUC_MINOR__< 4)&& __GNUC__< 4) + ((__GNUC__ == 3&& __GNUC_MINOR__< 4)&& __GNUC__< 4) I realize this patch is a typo fix, but isn't this logically equivalent to: (__GNUC__ == 3&& __GNUC_MINOR__< 4) maybe what you are really after is: (__GNUC__ == 3&& __GNUC_MINOR__< 4) || __GNUC__< 3 Yes, I'd noticed that too, and think it would break gcc 2.x if that's still supported at all (please tell me no one expects gcc 1.x to still work), but I wasn't sure if even 2.x was still expected to work and all the options I thought of were much messier than that, so I'd left it for another time/person. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix _GNUC__ typo in check for gcc 3.x for _mesa_bitcount
Without this fix, builds with gcc 3.4.x end up depending on undefined _mesa_bitcount instead of gcc's __builtin_popcount. NOTE: This is a candidate for the stable branches. Signed-off-by: Alan Coopersmith --- src/mesa/main/imports.c |2 +- src/mesa/main/imports.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c index 345a1c5..1c44727 100644 --- a/src/mesa/main/imports.c +++ b/src/mesa/main/imports.c @@ -514,7 +514,7 @@ _mesa_ffsll(int64_t val) #endif #if !defined(__GNUC__) ||\ - ((_GNUC__ == 3 && __GNUC_MINOR__ < 4) && __GNUC__ < 4) + ((__GNUC__ == 3 && __GNUC_MINOR__ < 4) && __GNUC__ < 4) /** * Return number of bits set in given GLuint. */ diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h index 20fa148..ade5441 100644 --- a/src/mesa/main/imports.h +++ b/src/mesa/main/imports.h @@ -576,7 +576,7 @@ _mesa_init_sqrt_table(void); #define _mesa_ffs(i) ffs(i) #define _mesa_ffsll(i) ffsll(i) -#if ((_GNUC__ == 3 && __GNUC_MINOR__ >= 4) || __GNUC__ >= 4) +#if ((__GNUC__ == 3 && __GNUC_MINOR__ >= 4) || __GNUC__ >= 4) #define _mesa_bitcount(i) __builtin_popcount(i) #define _mesa_bitcount_64(i) __builtin_popcountll(i) #else -- 1.7.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Add solaris detection for PIPE_ARCH_LITTLE_ENDIAN/PIPE_ARCH_BIG_ENDIAN
Signed-off-by: Alan Coopersmith --- src/gallium/include/pipe/p_config.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index b3a7b33..7cd42c6 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -129,6 +129,15 @@ # define PIPE_ARCH_BIG_ENDIAN #endif +#elif defined(__sun) +#include + +#if defined(_LITTLE_ENDIAN) +# define PIPE_ARCH_LITTLE_ENDIAN +#elif defined(_BIG_ENDIAN) +# define PIPE_ARCH_BIG_ENDIAN +#endif + #else #if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) -- 1.7.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Only use gcc visibility support with gcc4+.
On 10/19/11 13:44, Tom Fogal wrote:
I had a colleague hitting issues compiling with an old gcc3.2
system. These patches got them through.
---
include/GL/gl.h |2 +-
src/mesa/main/compiler.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/GL/gl.h b/include/GL/gl.h
index 998a83a..e65e1bc 100644
--- a/include/GL/gl.h
+++ b/include/GL/gl.h
@@ -67,7 +67,7 @@
#elif defined(__CYGWIN__)&& defined(USE_OPENGL32) /* use native windows
opengl32 */
# define GLAPI extern
# define GLAPIENTRY __stdcall
-#elif defined(__GNUC__)|| (defined(__SUNPRO_C)&& (__SUNPRO_C>= 0x590))
+#elif (defined(__GNUC__)&& __GNUC__>= 4) || (defined(__SUNPRO_C)&&
(__SUNPRO_C>= 0x590))
# define GLAPI __attribute__((visibility("default")))
That seems to match what X.Org's does for gcc
visibility attributes (the SUNPRO bits differ since Xorg supported
visibility attributes there in versions before they added compatibility
with the gcc style attributes):
#if defined(__GNUC__) && (__GNUC__ >= 4) && !defined(__CYGWIN__)
# define _X_EXPORT __attribute__((visibility("default")))
# define _X_HIDDEN __attribute__((visibility("hidden")))
# define _X_INTERNAL__attribute__((visibility("internal")))
#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
# define _X_EXPORT __global
# define _X_HIDDEN __hidden
# define _X_INTERNAL__hidden
#else /* not gcc >= 4 and not Sun Studio >= 8 */
# define _X_EXPORT
# define _X_HIDDEN
# define _X_INTERNAL
#endif /* GNUC >= 4 */
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
On 09/28/11 09:58 AM, Miles Bader wrote: On , Matt Turner wrote: [1] http://lists.x.org/archives/xorg-devel/2011-June/022724.html Thanks, that explains the significance of 2.62 -- but it doesn't actually explain the problem; it just says "In order to build it, I would have to accept GPLv3 (which is not acceptable)". _Why_ is the GPLv3 "not acceptable", when the GPLv2 was? Note his employer, which is well known as not accepting the GPLv3, possibly due to it being a mobile phone manufacturer, and the GPLv3's free patent license grant not fitting well with the current mobile phone environment in which every manufacturer is involved in more patent infringement lawsuits & countersuits than anyone wants to consider. Since most developers on the X & Mesa projects are doing it as part of our paid employment, we are subject to the constraints of the licenses our employers are willing to accept, and no amount of logic or arguments from outsiders can trump company policy. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl_glx.c: use unsigned instead of uint
On 09/18/11 10:26, Matt Turner wrote:
We've had a hack to fix this in Gentoo on Solaris for a while.
Signed-off-by: Matt Turner
---
Not sure what the deal is with uint, or why it wouldn't work on Solaris.
Not sure where uint is expected to be defined - Solaris provides the C99
standard type names, uint8_t, uint32_t, etc., plus some common extensions
such as uint_t, ulong_t, etc.
unsigned of course works everywhere.
Reviewed-by: Alan Coopersmith
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEATH to old drivers!
On 08/26/11 01:52, matthew green wrote:
> [*] keeping up with DRM in linux is hard work. you guys are
> very active.
Absolutely agreed there, but the only working DRM module we ship
at the moment is a KMS/DRI2 version of i915, so I have no objections
to losing the Mesa support for the DRI1 modules suggested.
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the "S3TC issue"
On 08/09/11 02:29, Rudolf Polzer wrote:
> Is US patent law really that retarded?
US patent law shares a common feature with most other patent systems:
No matter how carefully you word the patent or read the patent, the
only way to really find out whether something is a patent violation
is to go to court and see if a judge or jury, all made up of non-engineers
who don't understand the details, decide you're guilty of patent infringement.
All attempts to apply carefully reasoned logic to patents fail when they hit
this one illogical and unpredictable step, with potentially expensive results.
The US patent system has a bonus feature though - if you knew about that patent
in advance, then they can triple the amount of money you lose in the lawsuit,
which is why most companies advise their engineers to avoid knowing anything
about another companies patents, much less how to engineer around them.
Sadly, the much needed patent reform doesn't seem to be coming, while the
patent trolls and lawsuits keep rising.
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the "S3TC issue"
On 08/08/11 00:58, Egon Ashrafinia wrote: > I mean, the main problem is that this is a Software Patent, correct? Always > as I > know, only in the United States of America, correct? Incorrect. There's also quite a few other countries which allow software patents directly, such as Japan, South Korea, Australia, etc. Even if you believe the oversimplified (and incorrect) view that the EU has no software patents, European courts have enforced patents such as the MP3 ones when built into a hardware device such as an MP3 player. If you want to ensure Mesa is never built into a phone, or included as part of a preinstalled Linux bundle on a laptop, doing the wrong thing with patents is a good way to accomplish that. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] threads and X.org/AIGLX drivers
On 05/10/11 11:53 PM, Dave Airlie wrote: > The problem appears to be that we are using llvmpipe as our swrast > renderer and on systems that fallback to that we end up with threads > inside the X server, that we didn't spawn. It appears SIGIO gets > delivered to one of these threads while the main thread keeps on > trucking and fail ensues. I wasn't around when you were asking on IRC last night, but we do have a driver that uses threads (required by the API to get ACPI events from our kernel unfortunately) and it had similar problems, including crashes in places like ATIMach64SetCursorPosition when that thread that caught SIGIO for a mouse event, processed down to the point that it tried to do an outb, but didn't have IOPL privilege, since that's set per-thread on Solaris. The fix it used was xf86BlockSIGIO() before starting the thread, and then unblocking only in the main thread afterwards: http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/driver/xf86-input-hotkey/sun-src/hotkey.c#224 -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Make st_pipe_vertex_format return type in st_draw.h match st_draw.c
Fixes compiler error from Sun compilers: "state_tracker/st_draw.c", line 185: identifier redeclared: st_pipe_vertex_format current : function(unsigned int, unsigned int, unsigned int, unsigned char) returning enum pipe_format previous: function(unsigned int, unsigned int, unsigned int, unsigned char) returning unsigned int : "state_tracker/st_draw.h", line 73 Signed-off-by: Alan Coopersmith --- src/mesa/state_tracker/st_draw.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/state_tracker/st_draw.h b/src/mesa/state_tracker/st_draw.h index 5d3c278..a7b50ce 100644 --- a/src/mesa/state_tracker/st_draw.h +++ b/src/mesa/state_tracker/st_draw.h @@ -69,7 +69,7 @@ st_feedback_draw_vbo(struct gl_context *ctx, /* Internal function: */ -extern GLuint +extern enum pipe_format st_pipe_vertex_format(GLenum type, GLuint size, GLenum format, GLboolean normalized); -- 1.7.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix GET_PROGRAM_NAME() on Solaris to not try to modify a read-only string
On 04/ 8/11 01:18 PM, Jakob Bornecrantz wrote: > On Fri, Apr 8, 2011 at 10:12 PM, Jakob Bornecrantz > wrote: >> On Fri, Apr 8, 2011 at 10:04 PM, Alan Coopersmith >> wrote: >>> Signed-off-by: Alan Coopersmith >> >> Obvious question to this is was the string returned from >> GET_PROGRAM_NAME freed in the past? > > Bah, read the code again while we only leak one string its still a > leak and valgrind will complain (libraries that have these type of > leaks is a pet peeve of mine). But making it not leak will be > ridiculous, bah humbug. Other then that I see no problems with the > patch, while you don't have my ACK/RB I'm not NACK:ing it either. Will it? It's not truly leaked since it's stored in a static for re-use. Unfortunately, GET_PROGRAM_NAME() does different things on different OS'es, and the current model doesn't free it on any. I suppose we could also define FREE_PROGRAM_NAME() and define it to do nothing on OS'es where it returns a pointer to a static string from libc, but that's a bit overkill for the handful of bytes in the average case. (If your execname is more than 1k, you're doing it wrong.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix GET_PROGRAM_NAME() on Solaris to not try to modify a read-only string
Signed-off-by: Alan Coopersmith
---
src/mesa/drivers/dri/common/xmlconfig.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c
index 0312c07..0226b38 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.c
+++ b/src/mesa/drivers/dri/common/xmlconfig.c
@@ -64,7 +64,25 @@ extern char *program_invocation_name,
*program_invocation_short_name;
the basename to match BSD getprogname() */
#include
#include
-#define GET_PROGRAM_NAME() basename(getexecname())
+
+static const char *__getProgramName () {
+static const char *progname;
+
+if (progname == NULL) {
+ const char *e = getexecname();
+ if (e != NULL) {
+ /* Have to make a copy since getexecname can return a readonly
+ string, but basename expects to be able to modify its arg. */
+ char *n = strdup(e);
+ if (n != NULL) {
+ progname = basename(n);
+ }
+ }
+}
+return progname;
+}
+
+#define GET_PROGRAM_NAME() __getProgramName()
#endif
#if !defined(GET_PROGRAM_NAME)
--
1.7.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Functions/Entrypoints to be supported by XServer 2D driver.
X server drivers are usually discussed on one of the xorg mailing lists, not mesa-dev. You may want to check out the posted documentation on www.x.org before asking questions, such as: http://www.x.org/releases/X11R7.6/doc/xorg-server/Xserver-spec.html http://www.x.org/releases/X11R7.6/doc/xorg-server/DESIGN.html (also available as .txt or .pdf if you change the end of the URL) Though those documents are not kept up to date very well. On 01/27/11 06:41 PM, kumar vemuri wrote: > > Is this the wrong forum to post this question? Can someone suggest the > right one if so... > > thx > K > > On Thu, 2011-01-27 at 13:20 +0530, kumar vemuri wrote: >> Hi, >> >> Am new to linux graphics driver dev and is my spare time project. >> Can someone answer some fundamental questions. >> >> Its regarding the 2D device dependent driver . >> >> a. My understanding is that this driver is needed for GPU accelerated 2D >> rendering also. Hence its needed even if DRI is not enabled for 3D. Its >> basically the 2D driver for the GPU. Is my understanding correct? >> >> b. What are the functions that need to be implemented by this driver? Is >> there a header file that is exported by the device independent part of >> Xserver which lists all the functions that needs to >> support? >> >> c. Any suggestions on how to start writing this 2D driver will certainly >> be helpful. >> >> Thanks >> K >> > > > _______ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libdri.a
As with the other question, Xorg has mailing lists for the X servers, but any X server using .a modules instead of .so modules is so old and obsolete you're not likely to get help with it anywhere. On 01/27/11 06:42 PM, kumar vemuri wrote: > Is this a wrong forum to post this question ? Can someone suggest the > right forum if so? > > thx > K > > On Thu, 2011-01-27 at 07:45 +0530, kumar vemuri wrote: >> Hi, >> >> A few questions on libdri.a which is a device-independent DRI module >> loaded by the xserver during initialization. >> >> a. Can someone give some more detail on the functionality of this >> module? >> b. Can someone also point me to the source code of the libdri.a and the >> way to build it? >> c. I see a file called libdridrm.a being used in Gallium infrastructure. >> Are there any commonalities between libdridrm.a and libdri.a? >> >> >> Thx >> K >> > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Switching from talloc
On 01/27/11 07:46 AM, Owain Ainsworth wrote: > As someone who was making a fuss about talloc at XDS2010 (then dropped > off the map due to being insanely busy), i am entirely in favour of > this. > > No time to do any code review right now but spiritually I like this. Same here - talloc is just a portability headache for me I keep having to work around, but have absolutely no time to deal with. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa-demos] Allow builders to specify GLEW_CFLAGS & GLEW_LIBS
On 12/30/10 09:27 AM, tom fogal wrote: > Alan Coopersmith writes: >> configure --help says that builders can set those variables to override >> pkgconfig settings, but configure.ac was overwriting those before calling >> PKG_CHECK_MODULES >> >> Signed-off-by: Alan Coopersmith >> --- >> configure.ac |8 +++- >> 1 files changed, 3 insertions(+), 5 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index d6753a9..36e42f8 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -81,17 +81,15 @@ AC_CHECK_LIB([glut], >> [], >> [glut_enabled=no]) >> >> -GLEW_CFLAGS="" >> -GLEW_LIBS="-lGLEW" >> dnl Include a fallback path for GLEW for the moment while not all distros >> dnl have picked up the .pc file. >> PKG_CHECK_MODULES(GLEW, [glew], [], [ >>AC_CHECK_HEADER([GL/glew.h], >> - [], >> - AC_MSG_ERROR([GLEW required])) >> + [GLEW_CFLAGS=""], >> + AC_MSG_ERROR([GLEW required])) > > Isn't this going to mean that GLEW's w/o the .pc file cannot be used? > The .pc is too new for that, IMHO; I think there's only been one > release with it. No - in fact it should make it easier to use GLEW's without the .pc as builders can manually set GLEW_CFLAGS & GLEW_LIBS, to specify the right settings and then PKG_CHECK_MODULES should just use them. > Can we just remove the two lines that explicitly set these vars? No, because then they're left unset for people without .pc files who don't manually set them, so they don't get the GLEW_LIBS="-lGLEW" setting. That's why I moved them down to be set in the case that they weren't already set (in which case PKG_CHECK_MODULES uses them), the .pc file wasn't found (in which case PKG_CHECK_MODULES uses it), and the AC_CHECK_HEADER & AC_CHECK_LIB succeed - the places I added them are the "action-if-found" options to those macros. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH:mesa-demos] Allow builders to specify GLEW_CFLAGS & GLEW_LIBS
configure --help says that builders can set those variables to override pkgconfig settings, but configure.ac was overwriting those before calling PKG_CHECK_MODULES Signed-off-by: Alan Coopersmith --- configure.ac |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index d6753a9..36e42f8 100644 --- a/configure.ac +++ b/configure.ac @@ -81,17 +81,15 @@ AC_CHECK_LIB([glut], [], [glut_enabled=no]) -GLEW_CFLAGS="" -GLEW_LIBS="-lGLEW" dnl Include a fallback path for GLEW for the moment while not all distros dnl have picked up the .pc file. PKG_CHECK_MODULES(GLEW, [glew], [], [ AC_CHECK_HEADER([GL/glew.h], - [], - AC_MSG_ERROR([GLEW required])) + [GLEW_CFLAGS=""], + AC_MSG_ERROR([GLEW required])) AC_CHECK_LIB([GLEW], [glewInit], - [], + [GLEW_LIBS="-lGLEW"], AC_MSG_ERROR([GLEW required])) ]) DEMO_CFLAGS="$DEMO_CFLAGS $GLEW_CFLAGS" -- 1.7.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TLS autodetection support in the X server
On 12/22/10 02:30 PM, tom fogal wrote: > I'm not really sure about any policy of adding a macro and requiring > it in another package; I had to bump the version number so that the X > server could be sure the macro exists. Not sure if that's the correct > thing to do. Please educate me. That is what we do when we add new macros to xorg-macros, but > +# === > +# http://www.nongnu.org/autoconf-archive/ax_tls.html > +# === > +# > +# SYNOPSIS > +# > +# XORG_TLS (renamed from AX_TLS) We generally don't copy macros from the autoconf-archive into xorg-macros, we just use them as is - adding *.m4 files to packages that need them (especially when it's just one or two packages, not most of X.Org's 200+ packages). See for instance, xserver/m4/ac_define_dir.m4 Is there any reason not to do that here? Why should we add multiple levels of indirection to keep in sync? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Anonymous unions (Was: [Bug 30789] mesa git fails to build)
José Fonseca wrote: > What you guys feel about anonymous unions? > > I happened to committed some code with anonymous unions, but it caused > gcc to choke when -std=c99 option is specified, which is only specified > with automake but scons. > > After some search, it looks like anonymous unions are not part of C99, > but are part of C++ and will reportedly be part of C1X [1]. I think all > major compilers support it. I don't think the Sun compilers support it, for the few of us who build with those, but Mesa is generally unbuildable on Solaris anyway when I'm too busy elsewhere to keep up with repairing it. (I know git master has been broken for a few months, but haven't gotten around to fixing, sorry.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Old toys [DRI1 drivers] .....
randrianas...@gmail.com wrote: > Can freedesktop/X.org organise something like Google summer (winter?) of > Code, > with some tasks, need for moving those drivers forward? Good documentation > about _today_ mesa's internals and interfaces hopefully will speed up > process? X.Org has a "Endless Vacation of Code" program which allows students to submit proposals at any time of year for work on the X stack (which we generally include Mesa & DRI in) - so if there's a student who wants to work on this, they just need to write up a proposal and submit it as described at: http://www.x.org/wiki/XorgEVoC This is *not* a general code bounties program for any developer who wants to earn extra cash, but like Google's program, specifically for students to learn about real-world code while contributing to open source instead of having to look elsewhere for a job between semesters or even during the school year. We're a lot more flexible than Google simply because we generally deal with one or two students at a time, not 5,000. As for documentation, that was part of Matt Turner's Google Summer of Code project this year for adding KMS support to glint, so hopefully we'll have that soon. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System Member of the X.Org Foundation Board of Directors ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] fpclassify is available on C99-compliant Solaris releases too
Signed-off-by: Alan Coopersmith --- src/mesa/main/querymatrix.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/querymatrix.c b/src/mesa/main/querymatrix.c index a6b04e9..ca292aa 100644 --- a/src/mesa/main/querymatrix.c +++ b/src/mesa/main/querymatrix.c @@ -70,7 +70,8 @@ fpclassify(double x) } } -#elif defined(__APPLE__) || defined(__CYGWIN__) || defined(__FreeBSD__) +#elif defined(__APPLE__) || defined(__CYGWIN__) || defined(__FreeBSD__) || \ + (defined(__sun) && defined(__C99FEATURES__)) /* fpclassify is available. */ -- 1.5.6.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
