Re: [Mesa3d-dev] [PATCH] Only export one set of glu symbol names: mangled or unmangled
"Mandalemula, Rajesh" writes:
> +# Make the exports file with the mangled or unmangled names per $CFLAGS
> +glu.exports: glu.exports.in
Where does glu.exports.in come from? It is not in the tree. Did you
forget to 'git add' it?
>From the output, it looks like it should be
#ifdef USE_MGL_NAMESPACE
mgluBeginCurve
mgluBeginPolygon
...
#else
gluBeginCurve
gluBeginPolygon
...
#endif
if so, then it looks like it would fix 26335 as well. Could the mklib
be adjusted to just use glu.exports on Darwin as well, then, and then
glu.exports.darwin be removed from the tree?
Thanks,
-tom
> + @if [ "`expr "$(CC)" : ".*gcc"`" -ne 0 ] ; then \
> + $(CC) -E -I $(TOP)/include/GL $(CFLAGS) - < $< | \
> + awk '/^[^#]+/ {print}' > $@; \
> + else \
> + $(CC) -E -I $(TOP)/include/GL $(CFLAGS) $< | \
> + awk '/^[^#]+/ {print}' > $@; \
> + fi
> +
> # Make the library:
> -$(TOP)/$(LIB_DIR)/$(GLU_LIB_NAME): $(OBJECTS)
> +$(TOP)/$(LIB_DIR)/$(GLU_LIB_NAME): $(OBJECTS) glu.exports
> $(MKLIB) -o $(GLU_LIB) -linker '$(CXX)' -ldflags '$(LDFLAGS)' \
> -major $(GLU_MAJOR) -minor $(GLU_MINOR) -patch $(GLU_TINY) =
> \
> -cplusplus $(MKLIB_OPTIONS) -install $(TOP)/$(LIB_DIR) \
> @@ -144,6 +154,7 @@
>
>
> clean:
> + -rm -f glu.exports
> -rm -f *.o */*.o */*/*.o
> -rm -f *.lo */*.lo */*/*.lo
> -rm -f *.la */*.la */*/*.la
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium failing to build on darwin/ppc
Jeremy Huddleston writes: > > On Apr 3, 2010, at 12:34, tom fogal wrote: > > > Vinson Lee writes: > >> Leopard uses gcc-4.0, which didn't have built-in support for atomic > >> variables. > > > > u_atomic.h should probably check for a supported compiler; Jeremy, does > > the attached patch produce an understandable error instead of a link > > error? > > Yeah, that bails appropriately, but the message should probably be soemthing > more like: > > #error "galium requires a compiler that supports gcc atomics." I see Vinson committed a better fix to the 7.8 branch. However, Vinson, I think you made a typo: #elif defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 401) That version should be "410", not "401", right? -tom -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium failing to build on darwin/ppc
Vinson Lee writes: > Leopard uses gcc-4.0, which didn't have built-in support for atomic > variables. u_atomic.h should probably check for a supported compiler; Jeremy, does the attached patch produce an understandable error instead of a link error? In terms of a solution, Jeremy, you could implement PPC assembly for the few primitives available there. Looks easy for someone who knows PPC well. There's a comment in that file that mentions a mutex-based implementation... but then I don't see one. Looks like there's some dri radeon code which is using the gcc primitives directly instead of through the gallium wrapper. I'm not familiar enough w/ it to know if that's correct or not (.. anyway, you're probably not building dri/radeon on OS X, right?). -tom > > From: Jeremy Huddleston [jerem...@freedesktop.org] > Sent: Saturday, April 03, 2010 11:22 AM > To: mesa3d-...@lists.sf.net > Subject: [Mesa3d-dev] gallium failing to build on darwin/ppc > > Is there any known reason why gallium would fail to build on darwin/ppc? I h > aven't looked into it myself since I figured there might be an easy answer al > ready > > http://trac.macports.org/ticket/24345 diff --git a/src/gallium/auxiliary/util/u_atomic.h b/src/gallium/auxiliary/util/u_atomic.h index 3c42477..0dedaa3 100644 --- a/src/gallium/auxiliary/util/u_atomic.h +++ b/src/gallium/auxiliary/util/u_atomic.h @@ -89,6 +89,10 @@ p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new) */ #if defined(PIPE_ATOMIC_GCC_INTRINSIC) +#if defined(__GNUC__) && !((__GNUC__ >= 4) && (__GNUC_MINOR__ >= 1)) +# error "gcc atomics not available! Bailing to prevent confusing link error." +#endif + #define PIPE_ATOMIC "GCC Sync Intrinsics" #ifdef __cplusplus -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs
Jeremy Huddleston writes: > > BTW, what config are you using, and what prevents you from using > > autoconf? > > I can't use autoconf because it is nowhere near capable of handling > darwin, and I haven't wanted to address the issue until the > transition to autotools was completed. We're building swrast on Darwin using autoconf, and have been since 7.4. I know of an issue with glu on OS X 10.4, but other than that things were fine, last I checked (been a while, admittedly). Could you please report bugs / ping this ML with your autoconf build issues on Darwin? -tom -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Re: master: undef/unmangled EGL functions are part of libOSMesa
Brian Paul writes: > Tom wrote: > > > tom fogal wrote: > > > > $ lib nm libOSMesa.so | grep "EGL" > > > >U glEGLImageTargetRenderbufferStorageOES > > > >U glEGLImageTargetTexture2DOES > > > > > > > > this prevents using libOSMesa, since one gets link errors about the > > > > symbol. > > > > Regenerating gl_mangle.h was all that was needed. Thanks for the hint, > > I've committed the regenerated file. This needed application to 7.8 as well. I generated the patch again on top of 7.8's HEAD, though I think it's the same. My commit bit went through. Symbol mangling updates seem trivial and recurring; can I just commit them? -tom From 292a9e83750d3fe86a492a05a2bde10a8a7c43c5 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Thu, 25 Mar 2010 16:48:59 -0600 Subject: [PATCH] Regenerate gl_mangle.h --- include/GL/gl_mangle.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index b292840..43d2e89 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -393,6 +393,8 @@ #define glEdgeFlagPointerListIBM MANGLE(EdgeFlagPointerListIBM) #define glEdgeFlagPointer MANGLE(EdgeFlagPointer) #define glEdgeFlagv MANGLE(EdgeFlagv) +#define glEGLImageTargetRenderbufferStorageOES MANGLE(EGLImageTargetRenderbufferStorageOES) +#define glEGLImageTargetTexture2DOES MANGLE(EGLImageTargetTexture2DOES) #define glElementPointerAPPLE MANGLE(ElementPointerAPPLE) #define glElementPointerATI MANGLE(ElementPointerATI) #define glEnableClientStateIndexedEXT MANGLE(EnableClientStateIndexedEXT) -- 1.7.0.2 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Separate demos repository
Eric Anholt writes: [snip -- move demos to separate repo] *shrug*, doesn't affect me much, but sounds like a good idea. > I'm not sure if we want the repository to contain all of previous > Mesa history. Right now that history costs 145MB on disk for a deep > checkout. If that's a problem for people, we could use the same tool > that xcb did whose name I forget to to construct a history of just > progs/ You're thinking of git filter-branch. It can, indeed, drastically reduce repository size. Probably this: git filter-branch --subdirectory-filter progs -- --all is what you want. Might want to delete (some?) branches and tags afterwards too. HTH, -tom -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
Tom Stellard writes: > Where is a good place for me to start looking through the code? Is > there a reference Gallium driver I can look at to get a good idea of > how the drivers are structured? I'm sure one of the actual gallium developers can give you more detail/correct me, but: src/gallium/drivers is where you want to start looking. You'll note there's an `r300' directory, which is how your card is supported, of course. The reference driver is in the `softpipe' subdirectory. You can also compare with "classic" Mesa, referred to as swrast, by building --with-driver=xlib. Search the archives, as well. LunarG posted a bunch of videos from a recent hrm... 'gallium conference', I'd guess you'd call it? They're probably enlightening for the current state of gallium. I'd suggest doing this before reading code, it's probably better higher-level documentation. HTH, -tom -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Export glXGPA symbols
They seem to have become hidden with the visibility changes, at least
--with-driver=xlib.
-tom
From cd28ec06842e502e2e41459ed1c56a95ff642d8d Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Wed, 17 Mar 2010 10:57:44 -0600
Subject: [PATCH] Export glXGPA symbols.
---
src/mesa/drivers/x11/glxapi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/x11/glxapi.c b/src/mesa/drivers/x11/glxapi.c
index e11aff1..c758b12 100644
--- a/src/mesa/drivers/x11/glxapi.c
+++ b/src/mesa/drivers/x11/glxapi.c
@@ -1426,7 +1426,7 @@ _glxapi_get_proc_address(const char *funcName)
* This function does not get dispatched through the dispatch table
* since it's really a "meta" function.
*/
-__GLXextFuncPtr
+__GLXextFuncPtr PUBLIC
glXGetProcAddressARB(const GLubyte *procName)
{
__GLXextFuncPtr f;
@@ -1442,7 +1442,7 @@ glXGetProcAddressARB(const GLubyte *procName)
/* GLX 1.4 */
-void (*glXGetProcAddress(const GLubyte *procName))()
+PUBLIC void (*glXGetProcAddress(const GLubyte *procName))()
{
return glXGetProcAddressARB(procName);
}
--
1.7.0.2
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Re: master: undef/unmangled EGL functions are part of libOSMesa
Ian Romanick writes: > tom fogal wrote: > > $ lib nm libOSMesa.so | grep "EGL" > > 00064254 t _mesa_EGLImageTargetRenderbufferStorageOES > > 000b30c0 t _mesa_EGLImageTargetTexture2DOES > >U glEGLImageTargetRenderbufferStorageOES > >U glEGLImageTargetTexture2DOES > > 0029bb70 T mglEGLImageTargetRenderbufferStorageOES > > 0029bb90 T mglEGLImageTargetTexture2DOES > > > > this prevents using libOSMesa, since one gets link errors about the > > symbol. > > The trick here is that these are actually GL functions. Kristian > added support for these a couple weeks ago, but probably didn't add > mangling support. Regenerating gl_mangle.h was all that was needed. Thanks for the hint, -tom From b1894830897c7dc4b756ed048cc3be8970862897 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Mon, 15 Mar 2010 19:47:19 -0600 Subject: [PATCH] Regenerate gl_mangle.h. Needed due to new entry points from the EGL_KHR_gl_renderbuffer_image implementation. --- include/GL/gl_mangle.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index b292840..43d2e89 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -393,6 +393,8 @@ #define glEdgeFlagPointerListIBM MANGLE(EdgeFlagPointerListIBM) #define glEdgeFlagPointer MANGLE(EdgeFlagPointer) #define glEdgeFlagv MANGLE(EdgeFlagv) +#define glEGLImageTargetRenderbufferStorageOES MANGLE(EGLImageTargetRenderbufferStorageOES) +#define glEGLImageTargetTexture2DOES MANGLE(EGLImageTargetTexture2DOES) #define glElementPointerAPPLE MANGLE(ElementPointerAPPLE) #define glElementPointerATI MANGLE(ElementPointerATI) #define glEnableClientStateIndexedEXT MANGLE(EnableClientStateIndexedEXT) -- 1.7.0.2 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCHes] RFC: detect TLS during configuration
Dan Nicholson writes: > On Sun, Mar 14, 2010 at 5:38 PM, tom fogal wrote: > > [I] volunteer[ed] to detect platform TLS support, + enable it in > > Mesa / the X server if available. > > > > One thing I'm worried about is using an AC macro archive macro here; > > it's GPL + an exception [. . .] > > I don't think license of the build files affects the license of the > code. We're already using lots of macros from autoconf that are almost > certainly GPL. Okay, great. > > OTOH, the macro is dead simple. > > > > Comments? > > I think I'd prefer if you added the macro directly to acinclude.m4 > instead of adding more macro files. If we're going to do that, I'd > rather have an explicit m4 directory. I don't think mesa quite needs > that, though. Okay, I can integrate it directly. > Changing TLS to autodetect might be a good thing down the road, but > I think we need to at least have the xserver following the settings > before we make this change. Otherwise, nearly everybody is suddenly > going to get TLS enabled in the DRI drivers who don't know they need > to start passing another option to the xserver. Ahh, I see my memory was wrong; I figured a TLS driver could be used regardless. Digging up the old thread [1], it seems like it'd be possible, but currently not implemented as such. So, yes, I agree, autodetection shouldn't be applied until the X server keys into it. > So, I'd rather see these two patches broken up differently. > > 1. Export glx_tls from gl.pc > 2. Autodetect TLS usage Will do. -tom [1] http://lists.x.org/archives/xorg-devel/2009-November/003411.html -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCHes] RFC: detect TLS during configuration
It was a long while back that I wondered && somehow ended up
volunteering to detect platform TLS support, + enable it in Mesa / the
X server if available.
I got distracted before finishing the X parts, but rebased the Mesa
parts, which are attached.
One thing I'm worried about is using an AC macro archive macro here;
it's GPL + an exception that "configure" (the output) is unrestricted.
I'm not sure that'll be kosher for Mesa.
OTOH, the macro is dead simple.
Comments?
-tom
From eec65ace078b2b66e76ba79e9f67fa72d386 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Fri, 13 Nov 2009 21:19:18 -0700
Subject: [PATCH 1/2] RFC: Add macro to test for TLS from the AC macro archive.
This adds a macro to check for platform support of thread local
storage (TLS).
Note that the macro is under the GPL, meaning that this would
place Mesa's autoconf-based build system under the GPL as well.
The macro is placed in a separate file and included via
acinclude.m4. This methodology allows for easy upgrades should
the macro ever be modified upstream. The alternative is to place
the macro inline within acinclude.m4.
---
acinclude.m4 |2 +
ax_tls.m4| 74 ++
2 files changed, 76 insertions(+), 0 deletions(-)
create mode 100644 ax_tls.m4
diff --git a/acinclude.m4 b/acinclude.m4
index a5b389d..da6620d 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -117,3 +117,5 @@ if test "$enable_pic" != no; then
fi
AC_SUBST([PIC_FLAGS])
])# MESA_PIC_FLAGS
+
+m4_sinclude([ax_tls.m4])
diff --git a/ax_tls.m4 b/ax_tls.m4
new file mode 100644
index 000..7aa3383
--- /dev/null
+++ b/ax_tls.m4
@@ -0,0 +1,74 @@
+# ===
+# http://www.nongnu.org/autoconf-archive/ax_tls.html
+# ===
+#
+# SYNOPSIS
+#
+# AX_TLS
+#
+# DESCRIPTION
+#
+# Provides a test for the compiler support of thread local storage (TLS)
+# extensions. Defines TLS if it is found. Currently only knows about GCC
+# and MSVC. I think SunPro uses the same as GCC, and Borland apparently
+# supports either.
+#
+# LICENSE
+#
+# Copyright (c) 2008 Alan Woodland
+#
+# This program is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation, either version 3 of the License, or (at your
+# option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
+# Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# As a special exception, the respective Autoconf Macro's copyright owner
+# gives unlimited permission to copy, distribute and modify the configure
+# scripts that are the output of Autoconf when processing the Macro. You
+# need not follow the terms of the GNU General Public License when using
+# or distributing such scripts, even though portions of the text of the
+# Macro appear in them. The GNU General Public License (GPL) does govern
+# all other use of the material that constitutes the Autoconf Macro.
+#
+# This special exception to the GPL applies to versions of the Autoconf
+# Macro released by the Autoconf Archive. When you make and distribute a
+# modified version of the Autoconf Macro, you may extend this special
+# exception to the GPL to apply to your modified version as well.
+
+AC_DEFUN([AX_TLS], [
+ AC_MSG_CHECKING(for thread local storage (TLS) class)
+ AC_CACHE_VAL(ac_cv_tls, [
+ax_tls_keywords="__thread __declspec(thread) none"
+for ax_tls_keyword in $ax_tls_keywords; do
+ case $ax_tls_keyword in
+ none) ac_cv_tls=none ; break ;;
+ *)
+ AC_TRY_COMPILE(
+[#include
+ static void
+ foo(void) {
+ static ] $ax_tls_keyword [ int bar;
+ exit(1);
+ }],
+ [],
+ [ac_cv_tls=$ax_tls_keyword ; break],
+ ac_cv_tls=none
+ )
+ esac
+done
+])
+
+ if test "$ac_cv_tls" != "none"; then
+dnl AC_DEFINE([TLS], [], [If the compiler supports a TLS storage class define it to that here])
+AC_DEFINE_UNQUOTED([TLS], $ac_cv_tls, [If the compiler supports a TLS storage class define it to that here])
+ fi
+ AC_MSG_RESULT($ac_cv_tls)
+])
--
1.7.0.2
From 5ccda10bd39bb89a3449bfabf2deb2dee54196bc Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Fri, 13 Nov 2009 21:25:45 -0700
Subject: [PATCH 2/2] autoconf: Detect platform suppor
Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast
Xavier Chantry writes: > On Mon, Mar 15, 2010 at 12:41 AM, tom fogal wrote: > > > > You can emulate the [undefined link errors] by building with > > -Wl,--no-undefined (or maybe -no-undefined, something like that, > > see ld(1)). > > With -Wl,--no-undefined, I get so many errors that it did not fit in > my terminal buffer :P > > With -Wl,--no-allow-shlib-undefined it's a bit better but it is still scary : Oops, sorry; I was thinking of that flag, but I forgot about the shlib variant && expected --no-undefined to do --no-allow-shlib-undefined. Anyway, mea culpa, glad you figured out what I meant && not what I said ;) > /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker > 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \ > ../../common/driverfuncs.o ../common/utils.o swrast.o swrast_sp > an.o > ../../../../../src/mesa/libmesa.a-ldrm -lexpat -lm -lpthread > -ldl > mklib: Making Linux shared library: swrast_dri.so > LDFLAGS : -Wl,--no-allow-shlib-undefined > /lib/libpthread.so.0: undefined reference to `_dl_allocate_...@glibc_private' > /lib/libpthread.so.0: undefined reference to > `_dl_get_tls_static_i...@glibc_private' These look like TLS issues. Did you provide --enable-glx-tls to configure? Looks like you probably want to, for your platform. -tom -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast
Xavier Chantry writes: > 14:47 < lb1> the fact is that if you remove a function from mesa .c file, > everything will succeed, but the resulting driver will fail to l > oad > 14:47 < lb1> because it cannot resolve that symbol > 14:48 < lb1> not sure why > 14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on > undefined symbols > 14:48 < lb1> maybe the makefiles disable that checking > > Can anyone shed any light on this, why the driver always succeeds to > build and link even in the case of undefined symbols ? That's just the default compiler/linker setup on Linux. This is in contrast to, say, OS X, where undefined symbols cause link errors. You can emulate the above by building with -Wl,--no-undefined (or maybe -no-undefined, something like that, see ld(1)). > The second question is why the dlopen errors are not visible by > default and require LIBGL_DEBUG=verbose to be displayed. > It does not make sense to always print these errors by default ? Doesn't effect me personally, but errors coming up on stderr does seem like reasonable default behavior to me. Is it actually the case that these are always errors though (i.e. if a dlopen fails, does a higher level try loading a different driver which might succeed?)? -tom -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] master: undef/unmangled EGL functions are part of libOSMesa
>From a build of master (41eab95b3bc29a4fe6fd08b7f1f80cef5bdc097f) [1]:
$ lib nm libOSMesa.so | grep "EGL"
00064254 t _mesa_EGLImageTargetRenderbufferStorageOES
000b30c0 t _mesa_EGLImageTargetTexture2DOES
U glEGLImageTargetRenderbufferStorageOES
U glEGLImageTargetTexture2DOES
0029bb70 T mglEGLImageTargetRenderbufferStorageOES
0029bb90 T mglEGLImageTargetTexture2DOES
this prevents using libOSMesa, since one gets link errors about the
symbol.
Similar output for libMesaGL.
I shouldn't get any EGL when using --disable-egl, right?. Maybe this
is just the luxury edition...
Side note: libGLU is linked against libOSMesa, so there are issues
using that in a mangled setting as well. Seems strange that GLU would
need OSMesa symbols, but I'll admit to not keeping up with devel
lately.
-tom
[1]
./configure \
CFLAGS="-g -DUSE_MGL_NAMESPACE" \
CXXFLAGS="-g -DUSE_MGL_NAMESPACE" \
--prefix=${PF}\
--without-demos \
--with-driver=osmesa \
--disable-gallium \
--disable-egl \
--with-max-width=16384\
--with-max-height=16384 \
--enable-glx-tls || exit 1
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] code generation for dynamic extensions broken ?
George Sapountzis writes: > On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick wrote: > > George Sapountzis wrote: > > > >> When using libGL from mesa 7.7 and swrast_dri.so from getproc-test, > >> the extension string does contain GL_MESA_test_extension but the test > >> segfaults. > > > > There are a few places where this could break. > > > > - The generated dispatch stub function is wrong. > > - The dispatch offset used by the driver is wrong. > > - The dispatch remapping used by the driver is wrong. > > It turned out that there were two bugs in glapi. One with using > non-exec memory and the other with using an un-relocated function > template for entry-point generation. I put fixes at: > > http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug Some comments: e38a234.. shouldn't get merged as-is, right? I mean, there must be some sort of mesa_debug macro or similar, so that debug messages are configurable. ditto for d0b35e9. d6c973c is a strange patch; the additions to GLAPI_SOURCES seem unrelated to the patch itself. 977d5d: it seems like there should be some other way to disable this. I've been trying to make time to have these XMLs be exhaustive in their coverage of GL and GLX extensions, for example, which is good for other reasons. Most importantly: have you tested with mangled symbols (compile w/ USE_MGL_NAMESPACE defined)? It looks like the functions added in 682971c need #ifdef MANGLE cases. A few months back, I noticed some cases of doing function lookup without considering mangled symbols, but couldn't reproduce it in my setup. I think it had to do with loading the symbols from a DRI driver. It might have even been fine, i.e. a higher level scrubbed out the mangling. I guess I'm saying that if you tested mangling && it still works, great, `done' in my book :) Cheers, -tom -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
Ian Romanick writes: > Since we're not using CVS, would it be possible to start naming the > release branches with just the release version? Likewise for release > tags? Specifically, I'm proposing to use 7.8 for this next branch > and 7.8.0 for the release tag. +1. It's a pain to type out the full name all the time ;) -tom -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] OS ABI Tag.
Pat Suwalski writes: > On 11/02/10 05:28 PM, tom fogal wrote: > > If all your after is a way to select OpenGL implementation at > > runtime for *your* app, I have some GLEW patches you might be > > interested in. Of course, your scheme works globally / for all OGL > > apps on the system, which may be valuable to you. > > Yes, it needs to run on any kind of hardware, including Sony's Vaio's > with the "Speed/Stamina" switch that switches from i945->nvidia. Your "it" is ambiguous and does not actually clarify the situation. > >> - print '#endif /* GLX_USE_TLS */' > > > > Isn't this going to allow a TLS-enabled Mesa to run on a > > non-TLS-capable kernel? > > Have you seen one in the last 5 years? > > That was the point of my "going forward" question. A few months ago I wondered why TLS wasn't enabled by default. In the ensuing discussion, it came to light that some popular platforms still don't support TLS. As you say, I'd guess it's hard to find a *Linux* system w/o TLS support. That said, it does seem a bit silly to *remove* such a feature; maybe it'll be usable on other platforms soon enough. Why not report a bug to your other GL vendors, complaining that they don't include a kernel ABI requirement tag? -tom -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] OS ABI Tag.
Pat Suwalski writes: > I would like an opinion on the patch I've attached. > > In the past in my company, we have always had the Mesa libGL, > nVidia libGL, and ATI libGL installed in /usr/lib, /usr/lib/nvidia, > and /usr/lib/ati respectively. We would then simply change > /etc/ld.so.conf(.d) to give the appropriate libGL preference. [snip] If all your after is a way to select OpenGL implementation at runtime for *your* app, I have some GLEW patches you might be interested in. Of course, your scheme works globally / for all OGL apps on the system, which may be valuable to you. > def printRealFooter(self): > print '' > - print '#if defined(GLX_USE_TLS) && defined(__linux__)' > - print ' .section ".note.ABI-tag", "a"' > - print ' .p2align 2' > - print ' .long 1f - 0f /* name length */' > - print ' .long 3f - 2f /* data length */' > - print ' .long 1 /* note length */' > - print '0: .asciz "GNU" /* vendor name */' > - print '1: .p2align 2' > - print '2: .long 0 /* note data: the ABI tag */' > - print ' .long 2,4,20/* Minimum kernel version w/TLS */' > - print '3: .p2align 2/* pad out section */' > - print '#endif /* GLX_USE_TLS */' > - print '' Isn't this going to allow a TLS-enabled Mesa to run on a non-TLS-capable kernel? -tom -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Fix a typo in mesa3d.org HTML
From 99fbfe43dad3efae04749ab9da164c0e849bd836 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Fri, 5 Feb 2010 13:11:25 -0700 Subject: [PATCH] Fix a typo in mesa3d.org HTML. --- docs/repository.html |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/repository.html b/docs/repository.html index ed38528..15621b7 100644 --- a/docs/repository.html +++ b/docs/repository.html @@ -1,6 +1,6 @@ -Cocd Repository +Code Repository -- 1.6.3.3 -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] OSMesa symbol exports
A couple symbols are missing from the osmesa.def file. On Windows, this causes OSMesaGetProcAddress to be named "_osmesagetprocaddr...@4", which breaks some of our code to dynamically load OpenGL. The attached patch fixes the symbol names, verified via depends.exe. It's against 7_7_branch but probably applies elsewhere. If there's a 7.6.2 planned, could this get applied there as well? Thanks, -tom From 170587484549958420d115904f74588be54792fc Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Fri, 5 Feb 2010 11:45:03 -0700 Subject: [PATCH] Add OSMesaColorClamp and OSMesaGetProcAddress to symbol defs. Without this patch, the two symbols get an underscore prepended and an "@4" appended when compiling with VC8. --- src/mesa/drivers/osmesa/osmesa.def |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/osmesa/osmesa.def b/src/mesa/drivers/osmesa/osmesa.def index 71e9687..06afab7 100644 --- a/src/mesa/drivers/osmesa/osmesa.def +++ b/src/mesa/drivers/osmesa/osmesa.def @@ -2,6 +2,7 @@ VERSION 4.1 EXPORTS + OSMesaColorClamp OSMesaCreateContext OSMesaCreateContextExt OSMesaDestroyContext @@ -11,3 +12,4 @@ EXPORTS OSMesaGetIntegerv OSMesaGetDepthBuffer OSMesaGetColorBuffer + OSMesaGetProcAddress -- 1.6.5.1.msysgit.1 -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] (Red|Green|Blue)Bits gl_renderbuffer API change
I'm seeing a compilation error with Mesa-7.7 compiling OSMesa on windows. wmesa.c is attempting to query RedBits, GreenBits, and BlueBits from a struct gl_renderbuffer, none of which exist in the struct. Has this API changed recently? What is the correct way to query this information? Thanks, -tom -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
Mike Stroyan writes:
> The changes to load EGL drivers by pattern matching had the side
> effect of not looking in the directories specified by LD_LIBRARY_PATH
> or -rpath or ldconfig .
This is silly. If you give dlopen a library name:
dlopen("libWhatever.so", flags);
then *it* will automatically search LD_LIBRARY_PATH. By giving an
absolute path, one circumvents this behavior.
Even better, the relative-pathness obeys platform specifics, like
searching DYLD_LIBRARY_PATH (and fallbacks) on OS X.
A better fix is thus to not give an absolute path for EGL.
-tom
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa_7_7_branch -> master merges
I think we've touched on a core git workflow issue here, and its likely others have hit this && have a solution, so I've added the git ML to the CC list. Git: the situation in this repo is a fast-moving master that is including many changes to internal interfaces. Stable branches just get bugfixes, and are periodically merged to master. However, the more the heads diverge, the more difficult it is for a bugfix to merge into the head. The major issue is that more experienced developers should really weigh in on these merges, because they tend to automagically undo some of the interface changes. Yet during such a delay, master inevitably moves, and the bugfixer has to do even more work to "redo" the merge (and potentially get more review!). Of course, if there are two bugfixers trying to make separate changes in the same time period, this gets worse. Is there a workflow that can solve this issue? writes: > On Mon, 2010-01-25 at 09:52 -0800, tom fogal wrote: > > writes: > > [snip] > > > The ideal would be to peer-review the merges before committing, > > > but it seems difficult to do that with git, while preserving merge > > > history and not redoing merges. > > > > Google has developed an infrastructure to do peer review using git. > > `Gerrit': [snip] > Review infrastructures are nice. I'd have some bias towards > http://www.reviewboard.org/ by the similar reasons ;) Heh, yeah I can understand the bias ;) Personally, I'm not keen on a review tool I can't use from the command line, or at least not-the-web. Then again, my reviews wouldn't really be important in Mesa, so my opinion is irrelevant here ;) > But automated infrastructures aside, my worry with reviewing merges is > the actual constraints that git has. For example, let's suppose the > following scenario: > > 1) Developer A merges a stable branch into master. > 2) After spending a bunch of time fixing conflicts the best he can, he > emails the patch to mesa3d-dev for peer review. > 3) Developer B checks in a change into master. > 4) Developer A takes feedback from list, updates the code, and commits. > 5) Developer A cannot push because remote head has moved. > > So what can Developer A do now? > > a) Redo the merge, using the new master head. > b) Rebase the merge on top of the new head (I'm not sure it works, or > that it preserves branch history) > c) Double merge, i.e., merge its local head with the new master head. Hrm, I was thinking of some sort of staging branch, but I can't think of a good way to make it work. The crux of the issue seems to be that a developer needs to somehow give a version control promise that they will do the merge, even if the merge isn't done yet, because otherwise anyone else coming afterwards will duplicate the work (potentially incorrectly). That would mean some kind of lock though, which sounds like a terrible idea... -tom -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa_7_7_branch -> master merges
writes: [snip] > The ideal would be to peer-review the merges before committing, > but it seems difficult to do that with git, while preserving merge > history and not redoing merges. Google has developed an infrastructure to do peer review using git. `Gerrit': http://code.google.com/p/gerrit/ My understanding is that the basic idea is like bzr's PQM, except the gatekeeper is human. I haven't delved into it more deeply, because the server system sounds like one of those java/tomcat/servlet monstrosities && that scares me, but it's probably worth checking out if you feel strongly about this kind of thing. Bias up front: I'm really looking to get the opinion of a non-googler as to the efficacy/setup pain of the system, so I'm trying to get you to be my guinea pig ;) -tom -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] c99 again [was: Re: [PATCH] Fix compressed texture loads for non-minimal pitches]
Luca Barbieri writes: > I thought MSVC supported C99, but that seems not to be the case. > > However, it seems to have partial C99 support, and according to MSDN > the particular case of for loop initializers C99 behaviour may be > selected with /Zc:forScope. Wow, I never knew about that option. Cool -- thanks! [snip] > BTW, how about the Intel C/C++ compiler for Windows? It seems it > may support C99+GCC extensions and also output Windows debugging > information. Are you suggesting Mesa standardize on the Intel compiler on Windows? I'd like to politely request that Mesa not go this route. A particular application I work on is quite large, with a substantial software stack (Mesa included) as third party dependencies. Everything else is using MSVC, and I don't relish having a mixed-toolchain setup -- MSVC with all its compile modes is harsh enough. Simply supporting Intel on Windows, of course, isn't a bad thing. -tom -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Build failure on AIX/xlc with current master
cess.c \ + glsl/pp/sl_pp_purify.c \ + glsl/pp/sl_pp_token.c \ + glsl/pp/sl_pp_token_util.c \ + glsl/pp/sl_pp_version.c + +GLSL_CL_SOURCES = \ + glsl/cl/sl_cl_parse.c + # Sources for building non-Gallium drivers MESA_SOURCES = \ @@ -327,7 +347,9 @@ MESA_SOURCES = \ $(SWRAST_SETUP_SOURCES) \ $(COMMON_DRIVER_SOURCES)\ $(ASM_C_SOURCES) \ - $(SLANG_SOURCES) + $(SLANG_SOURCES) \ + $(GLSL_PP_SOURCES) \ + $(GLSL_CL_SOURCES) # Sources for building Gallium drivers MESA_GALLIUM_SOURCES = \ @@ -372,7 +394,6 @@ GLSL_LIBS = \ $(TOP)/src/glsl/pp/libglslpp.a \ $(TOP)/src/glsl/cl/libglslcl.a - ### Include directories INCLUDE_DIRS = \ From 77284afce08278b92f8ebd380c1e9b3c44d87d1f Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Wed, 6 Jan 2010 22:15:55 -0700 Subject: [PATCH] Fix generated tarballs. glsl directory needs a `Makefile.template' or the build will fail. --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index eb8dcc1..9db1776 100644 --- a/Makefile +++ b/Makefile @@ -226,7 +226,7 @@ MAIN_FILES = \ $(DIRECTORY)/include/GL/vms_x_fix.h\ $(DIRECTORY)/include/GL/wglext.h\ $(DIRECTORY)/include/GL/wmesa.h \ - $(DIRECTORY)/src/glsl/Makefile \ + $(DIRECTORY)/src/glsl/Makefile* \ $(DIRECTORY)/src/glsl/*/Makefile\ $(DIRECTORY)/src/glsl/*/SConscript\ $(DIRECTORY)/src/glsl/*/*.[ch] \ -- 1.6.3.3 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] mesa: Fallback on C byteswap.
This has been attached to bug 25663 for a bit now, but didn't get
reviewed here. It seems like a smarter way to go about setting up
the CPU_TO_LE32 macro, because it should do a correct but potentially
suboptimal thing on platforms we don't know about (instead of breaking
the build).
-tom
From 2109e24f7a3f603116e5e074569d77c666fbbe2f Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Wed, 16 Dec 2009 16:56:59 -0700
Subject: [PATCH] mesa: Fallback on C byteswap.
Only attempt using a platform-specific byteswap routine on
platforms where we know it will work.
---
src/mesa/main/compiler.h |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index a296404..7ca3c97 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -235,15 +235,12 @@ extern "C" {
#elif defined(__APPLE__)
#include
#define CPU_TO_LE32( x ) CFSwapInt32HostToLittle( x )
-#elif (defined(_AIX) || defined(__blrts))
+#else
#define CPU_TO_LE32( x )x = ((x & 0x00ff) << 24) | \
((x & 0xff00) << 8) | \
((x & 0x00ff) >> 8) | \
((x & 0xff00) >> 24);
-#else /*__linux__ */
-#include
-#define CPU_TO_LE32( x ) bswap32( x )
-#endif /*__linux__*/
+#endif
#define MESA_BIG_ENDIAN 1
#else
#define CPU_TO_LE32( x ) ( x )
--
1.6.3.3
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Compile with -fvisibility-hidden by default
writes:
> On Sun, 2010-01-03 at 12:55 -0800, Kristian Høgsberg wrote:
> > On Sun, Jan 3, 2010 at 3:24 PM, José Fonseca wrote:
> > > On Sun, 2010-01-03 at 08:45 -0800, Brian Paul wrote:
> > >> 2010/1/2 Chia-I Wu :
> > >> > On Sat, Jan 02, 2010 at 07:01:02PM -0500, Kristian Høgsberg wrote:
> > >> >> We have all functions that need to be visible marked with PUBLIC and
> > >> >> this is trimming around 4% off the DRI driver .so size.
> > >>
> > >> This would have to be checked on Windows. I think the x86 dispatch
> > >> code is sensitive to the Windows calling conventions implied by
> > >> GLAPIENTRY.
> > >
> > > Brian is right.
> > >
> > > GLAPI controls symbol visibility, both on unices (i.e.,
> > > _attribute__((visibility("default" and windows (i.e.,
> > > _declspec(dllexport).
[snip]
> > Ok, from all this I didn't see anything against enabling
> > -fvisibility-hidden by default so I've committed the patch. Also, the
> > _mesa_* entrypoints are only GLAPIENTRY, not GLAPI, so they are
> > already hidden.
>
> FWIW I also think that-fvisibility-hidden by default is a good a thing.
[snip]
I think an export map is a better way to handle visibility in libGL's
case. One will eventually have to go down the road of annotating every
function to note which symbols are exported or not. Most symbols will
not be.
OpenGL's symbols are fairly standardized, sans new revisions and
extensions and the like. Therefore generating the export map is
trivial. Symbol visibility is most useful with C++ libraries [1],
where features like templates and symbol mangling make generating such
a table into a nontrivial operation.
I've started work on this [2], but haven't jumped back to it since
that email. That work was started because I noted that the existing
symbol hiding strategy (i.e. based on GLAPIENTRY / GLAPI, I'd guess?)
was letting too many symbols through. I believe we'll get a lower (0?)
`false positive' rate by using a table of exported functions.
I also think this will be easily applicable to MSVC [3]; the
aforementioned ([2]) not-yet-existent python script just needs to
generate slightly different output on Windows.
-tom
[1] http://gcc.gnu.org/wiki/Visibility
[2] http://old.nabble.com/-PATCH--RFC%3A-ABI-cleanup-for-libGL.-td26907236.html
[2] http://msdn.microsoft.com/en-us/library/34c30xs1.aspx
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] RFC: ABI cleanup for libGL.
Brian Paul writes: > tom fogal wrote: > > I'd like to trim down the libGL ABI. Appended is the start of an > > approach that is going to work, and I just need to put in the time > > to complete everything. > > > > Thoughts? > > This looks pretty good. Just a few comments. > > 1. The other glapi generator scripts are written in Python. It would > be nice if we'd keep with that convention, rather than use sh. Okay. > 2. We'll need a way to add extra symbols to the export map in some > cases. For example, the libOSMesa.so library needs to access some > symbols in libGL.so, such as swrast_CreateContext(), etc. This could > be as simple as supporting an additional exports file that gets > appended onto the gl_exports file. It would be nice for me/my projects if libOSMesa.so was completely standalone. Can we just include all of those needed symbols while building it? Of course, you're probably referencing one example among many, and such a feature is simple, so I'll include it regardless. -tom -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Regenerate gl_mangle.h.
Was working on something else, noticed it was out of date. Attached. -tom From 6c911847202c21a228719b9f7efeced7453743b1 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Wed, 23 Dec 2009 11:24:52 -0700 Subject: [PATCH] Regenerate gl_mangle.h. --- include/GL/gl_mangle.h | 43 +++ 1 files changed, 43 insertions(+), 0 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index 59f6149..b292840 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -30,6 +30,7 @@ /*REGENERATE_TO_END---ALL LINES BELOW HERE GET REPLACED ON REGENERATION */ #define glAccum MANGLE(Accum) +#define glActiveProgramEXT MANGLE(ActiveProgramEXT) #define glActiveStencilFaceEXT MANGLE(ActiveStencilFaceEXT) #define glActiveTextureARB MANGLE(ActiveTextureARB) #define glActiveTexture MANGLE(ActiveTexture) @@ -60,6 +61,7 @@ #define glBeginTransformFeedback MANGLE(BeginTransformFeedback) #define glBeginTransformFeedbackNV MANGLE(BeginTransformFeedbackNV) #define glBeginVertexShaderEXT MANGLE(BeginVertexShaderEXT) +#define glBeginVideoCaptureNV MANGLE(BeginVideoCaptureNV) #define glBindAttribLocationARB MANGLE(BindAttribLocationARB) #define glBindAttribLocation MANGLE(BindAttribLocation) #define glBindBufferARB MANGLE(BindBufferARB) @@ -93,6 +95,8 @@ #define glBindVertexArrayAPPLE MANGLE(BindVertexArrayAPPLE) #define glBindVertexArray MANGLE(BindVertexArray) #define glBindVertexShaderEXT MANGLE(BindVertexShaderEXT) +#define glBindVideoCaptureStreamBufferNV MANGLE(BindVideoCaptureStreamBufferNV) +#define glBindVideoCaptureStreamTextureNV MANGLE(BindVideoCaptureStreamTextureNV) #define glBinormal3bEXT MANGLE(Binormal3bEXT) #define glBinormal3bvEXT MANGLE(Binormal3bvEXT) #define glBinormal3dEXT MANGLE(Binormal3dEXT) @@ -126,6 +130,7 @@ #define glBlendFuncSeparate MANGLE(BlendFuncSeparate) #define glBlitFramebufferEXT MANGLE(BlitFramebufferEXT) #define glBlitFramebuffer MANGLE(BlitFramebuffer) +#define glBufferAddressRangeNV MANGLE(BufferAddressRangeNV) #define glBufferDataARB MANGLE(BufferDataARB) #define glBufferData MANGLE(BufferData) #define glBufferParameteriAPPLE MANGLE(BufferParameteriAPPLE) @@ -202,6 +207,7 @@ #define glColor4uiv MANGLE(Color4uiv) #define glColor4us MANGLE(Color4us) #define glColor4usv MANGLE(Color4usv) +#define glColorFormatNV MANGLE(ColorFormatNV) #define glColorFragmentOp1ATI MANGLE(ColorFragmentOp1ATI) #define glColorFragmentOp2ATI MANGLE(ColorFragmentOp2ATI) #define glColorFragmentOp3ATI MANGLE(ColorFragmentOp3ATI) @@ -276,6 +282,7 @@ #define glCopyConvolutionFilter1D MANGLE(CopyConvolutionFilter1D) #define glCopyConvolutionFilter2DEXT MANGLE(CopyConvolutionFilter2DEXT) #define glCopyConvolutionFilter2D MANGLE(CopyConvolutionFilter2D) +#define glCopyImageSubDataNV MANGLE(CopyImageSubDataNV) #define glCopyMultiTexImage1DEXT MANGLE(CopyMultiTexImage1DEXT) #define glCopyMultiTexImage2DEXT MANGLE(CopyMultiTexImage2DEXT) #define glCopyMultiTexSubImage1DEXT MANGLE(CopyMultiTexSubImage1DEXT) @@ -302,6 +309,7 @@ #define glCreateProgramObjectARB MANGLE(CreateProgramObjectARB) #define glCreateShader MANGLE(CreateShader) #define glCreateShaderObjectARB MANGLE(CreateShaderObjectARB) +#define glCreateShaderProgramEXT MANGLE(CreateShaderProgramEXT) #define glCullFace MANGLE(CullFace) #define glCullParameterdvEXT MANGLE(CullParameterdvEXT) #define glCullParameterfvEXT MANGLE(CullParameterfvEXT) @@ -379,6 +387,7 @@ #define glDrawRangeElementsEXT MANGLE(DrawRangeElementsEXT) #define glDrawRangeElements MANGLE(DrawRangeElements) #define glDrawTransformFeedbackNV MANGLE(DrawTransformFeedbackNV) +#define glEdgeFlagFormatNV MANGLE(EdgeFlagFormatNV) #define glEdgeFlag MANGLE(EdgeFlag) #define glEdgeFlagPointerEXT MANGLE(EdgeFlagPointerEXT) #define glEdgeFlagPointerListIBM MANGLE(EdgeFlagPointerListIBM) @@ -408,6 +417,7 @@ #define glEndTransformFeedback MANGLE(EndTransformFeedback) #define glEndTransformFeedbackNV MANGLE(EndTransformFeedbackNV) #define glEndVertexShaderEXT MANGLE(EndVertexShaderEXT) +#define glEndVideoCaptureNV MANGLE(EndVideoCaptureNV) #define glEvalCoord1d MANGLE(EvalCoord1d) #define glEvalCoord1dv MANGLE(EvalCoord1dv) #define glEvalCoord1f MANGLE(EvalCoord1f) @@ -445,6 +455,7 @@ #define glFogCoorddv MANGLE(FogCoorddv) #define glFogCoordfEXT MANGLE(FogCoordfEXT) #define glFogCoordf MANGLE(FogCoordf) +#define glFogCoordFormatNV MANGLE(FogCoordFormatNV) #define glFogCoordfvEXT MANGLE(FogCoordfvEXT) #define glFogCoordfv MANGLE(FogCoordfv) #define glFogCoordhNV MANGLE(FogCoordhNV) @@ -544,6 +555,7 @@ #define glGetBufferParameteri64v MANGLE(GetBufferParameteri64v) #define glGetBufferParameterivARB MANGLE(GetBufferParameterivARB) #define glGetBufferParameteriv MANGLE(GetBufferParameteriv) +#define glGetBufferParameterui64vNV MANGLE(GetBufferParameterui64vNV) #define glGetBufferPointervARB MANGLE
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
Allen Akin writes: > On Mon, Dec 21, 2009 at 10:49:14AM -0700, tom fogal wrote: > | ... GL really > | needs a query that allows an application developer to figure out if a > | feature is accelerated by the hardware or not. Since it lacks this, > | the advertising of extensions is just about the only thing we, as app > | developers, can use as a heuristic. [snip -- it's hard to know what to report] > The only reliable way to solve the problem is to benchmark the > operations you want to use, in precisely the conditions you intend > to use them, and then make a judgement as to whether the performance > is good enough. This tends to be application-specific, so previous > attempts to make a centralized database of results failed. I > wouldn't say it's impossible, but it is very difficult. That's not nearly good enough either. Rendering a 128^3 dataset in a 400x400 window (which is *tiny* for us) on some Apple platforms (I think some Intels, older 10.5 with some ATI cards) can take upwards of ten minutes, during which the application is hung. On Linux systems with really old nvidia drivers, it crashes the system. On Linux systems with old nvidia drivers, it crashes the X server. On Linux systems with new nvidia drivers, a watchdog timer kicks in after 4 seconds and the screen visibly blinks, corruption is observed in other apps such as firefox, etc. Further, drivers can do whatever they want on just about any GL call. We recently added such a `benchmark' feature to our application, choosing the LoD dynamically based on the time to render the previous few frames. Many drivers will take, e.g. ~50ms for the majority of frames, and then spike with e.g. a 300ms frame before dropping back down to 50. This `solution' is like asking app developers to benchmark JITted code; there's far too much variability for it to actually work. I would much rather deal with a state explosion. > I haven't tracked this subject since I left the ARB, but maybe the > Khronos folks have done some more work on it. What is the appropriate forum for this? > As you say, using extension advertisements seems to be the most > common workaround, though it's far from perfect. As I argue initially and above, since it is the only possibility at this point, I'm going to argue strongly that extension advertisement implies some sort of standard on performance. Alex reported the HW capabilities in reference to this, which in our case would mean we can use the HW-supported NPOT textures. However in the absence of, say, a vendor extension for reporting this, I'd rather just implicitly enable our workaround at the app level. -tom -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
Corbin Simpson writes: > So, yet another thing that r300 sucks balls at: NPOT textures. We've > been talking it over on IRC, and here's the options. > > 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept > non-NPOT dimensions on textures. This sucks because it means that we > don't get GL 2.0, which means most apps (bless their non-compliant > souls) will refuse to attempt GLSL, which means that there's really > no point in continuing this driver. What's the performance of NPOT when implemented in the driver? I work on real-time visualization apps; the one in particular I'm thinking of does texture sampling of potentially-NPOT textures via GLSL. If sampling a NPOT texture is not going to run in hardware, the app is useless. Further, our app keeps track of the amount of GL memory allocated for textures, FBOs and the like. If a texture is going to be silently extended, that messes with our management routines [1]. We don't have the resources to maintain a card database of "this card with this driver advertises but implements it in software", though such a thing is desperately needed. It would be much easier for us if "advertising means we implement it in HW". Incorrect reporting of NPOT in particular is so prevalent that we have a settings dialog that allows a user to "force power of two textures", causing us to silently extend our textures before uploading them. Many of our users don't even know what a GPU is. What else can we do, though? Anyway, all that said, if performance suffers in any way I vote for not advertising the extension or GL 2.0. If an application is broken, an application is broken. Maybe add a debug statement so that the application author can figure out what they've done wrong, should they ever find the desire to fix their code. I realize this is getting beyond the scope of your inquiry. GL really needs a query that allows an application developer to figure out if a feature is accelerated by the hardware or not. Since it lacks this, the advertising of extensions is just about the only thing we, as app developers, can use as a heuristic. -tom [1] ... maybe this isn't such a big deal. GL's memory management is lame/opaque and as such we haven't found a way to utilize this information usefully, yet. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
Keith Whitwell writes: > Ideally that would mean being able to produce a single patch or patch > series that contains the changes to the headers *and* the changes to > the spec, so th at all is being considered together. That means in > turn having the spec in the git tree. Ideally we'd have an online > version as well, in a wiki style. I'm interested in suggestions for > how to make this happen. Ideally we *wouldn't* pollute the header > files with so much text and markup that they become unreadable - > ie. I don't really like the idea of doing the spec with doxygen - I'd > prefer the headers to be human-readable. Thoughts? I'm partial to / been considering both asciidoc and sphinx in my own projects. http://www.methods.co.nz/asciidoc/ http://sphinx.pocoo.org/ Both are text-based formats that are intended to be readable `raw', but are processable into more presentable formats. The git documentation: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html is done with asciidoc. Python documentation: http://docs.python.org/library/index.html is done with sphinx. -tom > > From: Corbin Simpson [mostawesomed...@gmail.com] > Sent: Friday, December 18, 2009 7:11 PM > To: Christoph Bumiller > Cc: mesa3d-dev@lists.sourceforge.net > Subject: Re: [Mesa3d-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHA > DE_FIRST_CONVENTION > > NAK to this series. Keith hasn't responded, although I expect that he > would also NAK this. I would much rather have quads just never respect > flatshade_first as part of the spec, than jump through these weird > param hoops. > > Should somebody be documenting the API? I keep on having these kinds > of stupid edge questions come up; r300 apparently is the quirkiest > hardware of that generation. > > ~ C. > > On Fri, Dec 18, 2009 at 2:15 AM, Christoph Bumiller > wrote: > > Marek Olák schrieb: > >> Hi, > >> > >> GL_ARB_provoking_vertex states that quads are not required to abide > >> the provoking vertex convention, and the actual hardware and/or driver > >> behavior can be queried with > >> GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION. > >> > >> I'd like to add a new PIPE_CAP_* to query for this capability in > >> Gallium, as it appears R3xx-R5xx hardware doesn't support the first > >> vertex convention for quads and I'd like the driver to behave > >> correctly. Fortunately, other primitive types are supported. > >> > >> I decided to use the name "quads follow flatshade_first convention" > >> instead of "provoking vertex convention" because the actual state > >> variable in pipe_rasterizer_state is called flatshade_first. > >> > >> The attached patch: > >> - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION > >> - adds the query in the Mesa state tracker > >> - and updates softpipe and llvmpipe to return 1 when this cap is > >> queried, and r300g to explicitly return 0 > >> > > You can add a "return 1" for nv50, too, in case you do push this patch. > > I just tested and for quads I can also make them use either the first or > > the last vertex's colour, i.e. flatshade convention is respected. > > > > Thanks, Christoph. > >> Please review/push. > >> > >> Cheers. > >> > >> Marek > >> > >> > >> > >> > >> -- > > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and ea > sy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> > >> > >> > >> > >> ___ > >> Mesa3d-dev mailing list > >> Mesa3d-dev@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > > > > > --- > --- > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and eas > y > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > ___ > > Mesa3d-dev mailing list > > Mesa3d-dev@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > > > > > -- > Only fools are easily impressed by what is only > barely beyond their reach. ~ Unknown > > Corbin Simpson > > > - > - > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A stre
Re: [Mesa3d-dev] swrast: _ae_invalidate_state segfault executing a VBO
tom fogal writes: > A user of ours is hitting a segfault in our application, which ships > Mesa-7.5 currently. > > The stack trace is attached. It looks to me like Qt is invoking > the system's libGL, which loads a DRI driver, and then somehow that > DRI driver ends up calling routines in our private libOSMesa. The > libOSMesa that gets built is mangled, should that matter. It appears > as if the user is running Fedora 11. Update -- the user reports that everything works fine when LIBGL_ALWAYS_INDIRECT is set in their environment. -tom -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] swrast: _ae_invalidate_state segfault executing a VBO
A user of ours is hitting a segfault in our application, which ships Mesa-7.5 currently. The stack trace is attached. It looks to me like Qt is invoking the system's libGL, which loads a DRI driver, and then somehow that DRI driver ends up calling routines in our private libOSMesa. The libOSMesa that gets built is mangled, should that matter. It appears as if the user is running Fedora 11. I looked in _ae_invalidate_state, and the only opportunity I see for a segfault is dereferencing a context pointer. It seems like this is internal state though, and further this happens *while* initializing a context, so that seems suspect. That said, it seems rather strange that a DRI driver is jumping into our private mangled-OSMesa to initialize a context. Are we getting bit by a flat namespace here? It appears libOSMesa is exporting many vbo_ functions, but AFAICT these should be internal symbols: $ nm -AC libOSMesa.so | grep vbo_ ... libOSMesa.so:000f35df T vbo_exec_vtx_destroy libOSMesa.so:000f6aae T vbo_exec_vtx_flush libOSMesa.so:000f3472 T vbo_exec_vtx_init I'll note that some vbo_ functions do seem to be internal. Side note -- how does an `AEcontext' differ from, say, a `GLcontext', or, conceptually, from a glX context? -tom Traceback (most recent call last): File "", line 27, in ImportError: No module named os.path [?1034h[Thread debugging using libthread_db enabled] Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.12-gdb.py", line 26, in from libstdcxx.v6.printers import register_libstdcxx_printers File "/usr/lib/python2.6/site-packages/gdb/libstdcxx/v6/printers.py", line 19, in import itertools ImportError: No module named itertools [New Thread 0xb7c0cb70 (LWP 30038)] [Thread 0xb7c0cb70 (LWP 30038) exited] [New Thread 0xb720bb70 (LWP 30054)] [Thread 0xb720bb70 (LWP 30054) exited] Program received signal SIGSEGV, Segmentation fault. 0x01ddbfa3 in _ae_invalidate_state () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 #0 0x01ddbfa3 in _ae_invalidate_state () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #1 0x01d3ee95 in vbo_exec_invalidate_state () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #2 0x01d3edd9 in vbo_exec_init () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #3 0x01d3ec0e in _vbo_CreateContext () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #4 0x01b1e467 in ?? () from /usr/lib/dri/swrast_dri.so No symbol table info available. #5 0x0671df90 in ?? () from /usr/lib/libGL.so.1 No symbol table info available. #6 0x06701740 in ?? () from /usr/lib/libGL.so.1 No symbol table info available. #7 0x06701a43 in glXCreateContext () from /usr/lib/libGL.so.1 No symbol table info available. #8 0x004ec1dc in QGLContext::chooseContext(QGLContext const*) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #9 0x004bbb4a in QGLContext::create(QGLContext const*) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #10 0x004ea6fc in QGLWidget::setContext(QGLContext*, QGLContext const*, bool) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #11 0x004b6adf in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #12 0x004eb916 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #13 0x004b8368 in QGLWidget::QGLWidget(QWidget*, QGLWidget const*, QFlags) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #14 0x004edd00 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #15 0x004b6a85 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #16 0x004eb916 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #17 0x004b8508 in QGLWidget::QGLWidget(QWidget*, QGLWidget const*, QFlags) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #18 0x0040774f in vtkQtGLWidget::vtkQtGLWidget(QWidget*) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libvtkqt.so No symbol table info available. #19 0x004094cc in vtkQtRenderWindow::vtkQtRenderWindow(QWidget*, QFlags) () from /home/rese
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
Dan Nicholson writes: > On Tue, Nov 24, 2009 at 3:55 PM, tom fogal wrote: > > > > I like your automake-esque solution. How's the attached patch? Note > > that I tested the approach but not Mesa on AIX yet (please don't > > apply). > > Yeah, that's great. One of my _really_ rainy day projects was to > convert all the mesa recursion targets to use the automake style since > we know that's been thrown at tons of systems out in the wild. > > Reviewed-by: Dan Nicholson I think this fell through the cracks (I see the old makefile in 7.6.1-rc2). Note that I did send a followup mail after testing that the approach works fine on AIX. Could someone apply this to mesa_7_6_branch? Thanks, -tom From 6fb5d204d98fd8a5c48724069f1ea9ee3cca2e4e Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Tue, 24 Nov 2009 16:46:31 -0700 Subject: [PATCH] Simplify hackery added to fix AIX build. Borrow an idiom from the GNU build system which can handle `for' loops over empty lists. --- progs/Makefile | 26 +++--- 1 files changed, 11 insertions(+), 15 deletions(-) diff --git a/progs/Makefile b/progs/Makefile index d5852fa..5bc444e 100644 --- a/progs/Makefile +++ b/progs/Makefile @@ -4,7 +4,7 @@ TOP = .. include $(TOP)/configs/current -SUBDIRS = "$(strip "$(PROGRAM_DIRS)")" +SUBDIRS = $(PROGRAM_DIRS) default: message subdirs @@ -15,22 +15,18 @@ message: subdirs: - @if test -n "$(SUBDIRS)" ; then \ - for dir in $(SUBDIRS) ; do \ - if [ -d $$dir ] ; then \ -(cd $$dir && $(MAKE)) || exit 1 ; \ - fi \ - done \ - fi + @list='$(SUBDIRS)'; for dir in $$list ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE)) || exit 1 ; \ + fi \ + done # Dummy install target install: clean: - -...@if test -n "$(SUBDIRS)" ; then \ - for dir in $(SUBDIRS) tests ; do \ - if [ -d $$dir ] ; then \ -(cd $$dir && $(MAKE) clean) ; \ - fi \ - done \ - fi + @list='$(SUBDIRS)'; for dir in $$list tests ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE) clean) ; \ + fi \ + done -- 1.6.3.3 -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] minor u_math.h speedup fun
Matt Turner writes: > On Sat, Nov 28, 2009 at 2:13 PM, Yang Zhao wrote: > > The speed-up is definitely there, but __builtin_popcount() > > will still be drastically faster when architecture-specific > > optimizations are enabled: > > I don't think this is the case (except for with SSE4's popcnt > instruction, which your CFLAGS seem to be enabling.) > > Even when compiling with the Intel CC, which can undoubtedly > can optimize code for Core 2 better than gcc, fast_bitcount is > significantly faster. IMHO, the best long term solution is to use gcc's builtin, and ping the gcc folks with the implementation and benchmark results of fast_bitcount. If it's really better, they'll eventually adopt it on the platforms where that makes sense. This would benefit a larger community, and would hopefully mean that nobody needs to come across this again in years when common CPUs might be completely different -- Mesa would just benefit transparently from someone in the gcc community noticing the need for a new tuning. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium/util: add util_bswap32()
writes: > On Thu, 2009-11-26 at 08:36 -0800, tom fogal wrote: > > If nothing else though, it'd be good if bswap32 was defined > > once and utilized in both places. > > Gallium3D and Mesa3D don't depend on each other. Ahh, I did not realize that. Mea culpa / LGTM / sorry for the noise. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium/util: add util_bswap32()
Christoph Bumiller writes:
> Hi. Now that there's util_bitcount in u_math, I'd like to have a
> bswap helper as well,
> I need to swap the stipple pattern on nv50. Any objections ?
[snip]
> src/gallium/auxiliary/util/u_math.h | 17 +
> 1 files changed, 17 insertions(+), 0 deletions(-)
[snip]
> + * Reverse byte order of a 32 bit word.
> + */
> +static INLINE uint32_t
> +util_bswap32(uint32_t n)
> +{
> +#if defined(PIPE_CC_GCC)
> + return __builtin_bswap32(n);
> +#else
> + return (n >> 24) |
> + ((n >> 8) & 0xff00) |
> + ((n << 8) & 0x00ff) |
> + (n << 24);
Is there a reason you can't just use CPU_TO_LE32 from
src/mesa/main/compiler.h?
Of course, 1) that's only if you need your data in little endian
format, and 2) it's based on a compile-time test, w/ a big warning
about that at the definition. So you might prefer to avoid using it
directly. If nothing else though, it'd be good if bswap32 was defined
once and utilized in both places.
-tom
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Can mesa library be built on aix 5.3 platform
1. Please CC the list in replies. 2. You've again sent me a mail in a `gbk' charset, which was really in iso-8859-1 or something similar, and all of that was needlessly encoded via base64. This is the last reply you'll get from me without fixing your mail client. majun writes: > Glad to receive your Emai. From your Email, if I can get these > informations: > 1. Before mesa_7_6, there is no mesa library which can support aix > 5.3. AFAICT, Mesa used to support AIX. I gather that few people use AIX, so the support atrophied a bit until some recent testing revealed the build was broken. I haven't been here all that long though. > 2. Only mesa_7_6_branch can support aix 5.3, but this version is > latest, and I can not download, so I will wait. You can download the current Mesa 7.6 tip from git. See: http://www.mesa3d.org/repository.html > In your Emai, I can not understand what isOSMesa is, Can you explain > it for me? I can but won't bother. Google is your friend. I apparently don't have a good link on ML etiquette bookmarked. This will do in the meantime: http://www.freebsd.org/doc/en/articles/mailing-list-faq/etiquette.html though it is of course specific to FreeBSD. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
tom fogal writes: > Dan Nicholson writes: > > On Tue, Nov 24, 2009 at 12:37 PM, tom fogal wrot= > e: > > > Dan Nicholson writes: > > >> On Thu, Nov 19, 2009 at 8:28 AM, Brian Paul wrote= > : > > >> > tom fogal wrote: > > >> >> Brian Paul writes: > > >> >> Secondly, the AIX build is failing in progs/Makefile. > > > > > 31f7e8efb25a77e3bdfb6e9850cf31e339060976 is definitely correct as the > > quotes would cause all the directories to be a single argument. Can > > you try the automake way, which I believe is used to workaround this > > exact issue? It constructs the for loop using a shell variable instead > > of a make variable. > > > subdirs: > > @list=3D'$(SUBDIRS)'; for dir in $$list; do echo $$dir; done > > This works great with AIX (and of course GNU) make. [snip] > I like your automake-esque solution. How's the attached patch? Note > that I tested the approach but not Mesa on AIX yet (please don't > apply). > > From: Tom Fogal > Date: Tue, 24 Nov 2009 16:46:31 -0700 > Subject: [PATCH] RFC: Simplify hackery added to fix AIX build. [snip] I just verified on AIX, and this patch works (in our configuration, at least) fine. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
Dan Nicholson writes: > On Tue, Nov 24, 2009 at 12:37 PM, tom fogal wrote: > > Dan Nicholson writes: > >> On Thu, Nov 19, 2009 at 8:28 AM, Brian Paul wrote: > >> > tom fogal wrote: > >> >> Brian Paul writes: > >> >>> Please test and report any problems ASAP. If there aren't any issues > >> >>> we'd like to release 7.6.1 on Friday or Saturday. > > [snip] > >> >> Secondly, the AIX build is failing in progs/Makefile. > > > > PROGRAM_DIRS = > > ^ (there's a space here [1] ;) > > > > in a config/ though. *shrug*. As I said, it doesn't matter much for > > me. > > Actually, I don't know why this is a problem. On my system with GNU > make (which you're using, too) having just spaces after the = gets > stripped. We're using the native make on AIX, not GNU make. Speaking of which, I guess AIX make *does* support $(strip ...). > $ cat > Makefile << "EOF" > DIRS = # bunch of spaces here > SUBDIRS = $(DIRS) > dirs: > @echo '"$(SUBDIRS)"' > @test -n "$(SUBDIRS)" && echo non-empty || echo empty > EOF > $ make dirs This test does in fact work fine. However, if you do: @for d in "$(SUBDIRS)" ; do \ echo "$$d" \ done after the @test -n line, AIX make chokes. > What is the actual error you're seeing? -bash-3.00$ cat Makefile DIRS = SUBDIRS = $(DIRS) dirs: @echo '"$(SUBDIRS)"' @test -n "$(SUBDIRS)" && echo non-empty || echo empty @for dir in $(SUBDIRS) ; do \ echo "$$dir" \ done -bash-3.00$ make "" empty /usr/bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. make: 1254-004 The error code from the last command is 2. Stop. -bash-3.00$ If I quote the $(SUBDIRS) in the @for line, I get the error "`for' is not matched.". > 31f7e8efb25a77e3bdfb6e9850cf31e339060976 is definitely correct as the > quotes would cause all the directories to be a single argument. Can > you try the automake way, which I believe is used to workaround this > exact issue? It constructs the for loop using a shell variable instead > of a make variable. > > subdirs: > @list='$(SUBDIRS)'; for dir in $$list; do echo $$dir; done This works great with AIX (and of course GNU) make. > >> Tom, what arguments do you pass to configure? > > > > FWIW on AIX we do something like this: > > > > ./configure CC=xlc CXX=xlC CFLAGS=-qcpluscmt -qlanglvl=extc99 > > -DUSE_MGL_NAMESPACE CXXFLAGS=-DUSE_MGL_NAMESPACE > > --prefix=/usr/common/homes/f/fogal1/sw > > --without-demos --with-driver=xxx --disable-gallium --with-max-width=16384 > > --with-max-height=16384 --disable-glw --disable-glu --disable-egl > > > > Except it happens twice, the first time with xxx=xlib and the latter > > with xxx=osmesa. If you're *really* curious, see the function > > 'build_mesa' in: > > > > http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit > > That's strange since --without-demos will substitute PROGRAM_DIRS="". > I think there's something else funky going on. The issue is SUBDIRS = $(PROGRAM_DIRS) in progs/Makefile, I think (but haven't verified). That seems to cause AIX make to think that SUBDIRS is a string with a single space, which != the empty string, and thus the test -n fails. I like your automake-esque solution. How's the attached patch? Note that I tested the approach but not Mesa on AIX yet (please don't apply). -tom From 8e97a68d0f85d72f81f4652dcfd0cb1665beec87 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Tue, 24 Nov 2009 16:46:31 -0700 Subject: [PATCH] RFC: Simplify hackery added to fix AIX build. Borrow an idiom from the GNU build system which can handle `for' loops over empty lists. --- progs/Makefile | 26 +++--- 1 files changed, 11 insertions(+), 15 deletions(-) diff --git a/progs/Makefile b/progs/Makefile index d5852fa..5bc444e 100644 --- a/progs/Makefile +++ b/progs/Makefile @@ -4,7 +4,7 @@ TOP = .. include $(TOP)/configs/current -SUBDIRS = "$(strip "$(PROGRAM_DIRS)")" +SUBDIRS = $(PROGRAM_DIRS) default: message subdirs @@ -15,22 +15,18 @@ message: subdirs: - @if test -n "$(SUBDIRS)" ; then \ - for dir in $(SUBDIRS) ; do \ - if [ -d $$dir ] ; then \ -(cd $$dir && $(MAKE)) || exit 1 ; \ - fi \ - done \ - fi + @list='$(SUBDIRS)'; for dir in $$list ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE)) || exit 1 ; \ + fi
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
Dan Nicholson writes: > On Thu, Nov 19, 2009 at 8:28 AM, Brian Paul wrote: > > tom fogal wrote: > >> Brian Paul writes: > >>> Please test and report any problems ASAP. Â If there aren't any issues > >>> we'd like to release 7.6.1 on Friday or Saturday. [snip] > >> Secondly, the AIX build is failing in progs/Makefile. Â The > >> quoting introduced in 115edf24a9128b79dfa5f30482c990e2cb898357 > >> and removed in 31f7e8efb25a77e3bdfb6e9850cf31e339060976 was > >> important. Â Otherwise, SUBDIRS will end up being " " or maybe " " > >> and test -n will (annoyingly) fail, causing the `for'-over-nothing > >> to execute. > > > > The $(strip ...) syntax is GNU-make specific, I think. Â If it > > causes trouble for anyone we'll revisit it. > > Sorry, I meant to comment on this earlier, but I was really busy. It happens, no worries. > I think the reason that the make variable ends up with a space > in it instead of being empty is the automatic demos checking in > configure. I think it would be better to fix it there so that you > either get a list of directories or an empty variable. I don't have > time to test, but I think this would fix it: I think you're right, but unfortunately that's not the only change that needs to be made. configs/default (IIRC) sets PROGRAM_DIRS as well, which I think is the issue Brian ran into that caused him to originally revert this part of the patch. I toyed with the idea of making: PROGRAM_DIRS = demos blah whatever into: PROGRAM_DIRS ="demos blah whatever" in configs/default, but I felt that was too fragile; anyone that then modified configs/default (or a config that included it, where they wanted to change this) would need to know about this weird stringification-with-no-spaces requirement, and no other variables need that behavior. > -PROGRAM_DIRS="$demos" > +PROGRAM_DIRS=`echo $demos | $SED 's/^ *//'` ... we might consider doing something like this instead of $(strip) in the makefile; this seems more portable (i.e. would work w/o GNU make). ... all that said, we could, of course, just go with something like this and ignore the non-autoconf case. I certainly don't care about the non-GBS for my work. It leaves the lurking case where one can't: PROGRAM_DIRS = ^ (there's a space here [1] ;) in a config/ though. *shrug*. As I said, it doesn't matter much for me. > Tom, what arguments do you pass to configure? FWIW on AIX we do something like this: ./configure CC=xlc CXX=xlC CFLAGS=-qcpluscmt -qlanglvl=extc99 -DUSE_MGL_NAMESPACE CXXFLAGS=-DUSE_MGL_NAMESPACE --prefix=/usr/common/homes/f/fogal1/sw --without-demos --with-driver=xxx --disable-gallium --with-max-width=16384 --with-max-height=16384 --disable-glw --disable-glu --disable-egl Except it happens twice, the first time with xxx=xlib and the latter with xxx=osmesa. If you're *really* curious, see the function 'build_mesa' in: http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit -tom [1] As a professor I had once liked to say, "It's hard to see nothing." -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Can mesa library be built on aix 5.3 platform
Please send your mails in plain text, preferably without any encoding. Your base64 ends up raw in my replies, so I've just deleted it. Anyway, I *just* fixed AIX 5.3 support last week. Use git master, git mesa_7_6_branch, or just wait for the 7.6.1 release. I'd love to hear how it works for you; we're only using OSMesa, so I think a generic libGL doesn't see much testing on AIX. Cheers, -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
Brian Paul writes: > tom fogal wrote: > > Brian Paul writes: > >> Please test and report any problems ASAP. If there aren't any issues > >> we'd like to release 7.6.1 on Friday or Saturday. [snip] > > The (second) attached patch fixes [the quoting issue], I believe > > in both cases. At least, with Mesa-7.6.1-rc1 I get the error > > mentioned in 31f7.. from `make linux', and now I don't (and it > > still works on AIX). > > OK, I've applied both patches. Thanks! > The $(strip ...) syntax is GNU-make specific, I think. If it causes > trouble for anyone we'll revisit it. Oops, yes, it is; I should have mentioned. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
Brian Paul writes:
> Please test and report any problems ASAP. If there aren't any issues
> we'd like to release 7.6.1 on Friday or Saturday.
We've had the attached AIX patch locally for a while now. Sorry I
didn't send it earlier. I wrote a small C program to compare it to
Linux's bswap_32 and it seems to work, but I'll note it's untested in
Mesa; for build-dep reasons, we need an Xlib-based Mesa, but we never
call that code at runtime. Further, I inserted #error blah in the
define used here, and the Mesa build succeeded... so this is obviously
never even called in the configurations I am concerned with.
Secondly, the AIX build is failing in progs/Makefile. The quoting
introduced in 115edf24a9128b79dfa5f30482c990e2cb898357 and removed in
31f7e8efb25a77e3bdfb6e9850cf31e339060976 was important. Otherwise,
SUBDIRS will end up being " " or maybe " " and test -n will
(annoyingly) fail, causing the `for'-over-nothing to execute.
The (second) attached patch fixes it, I believe in both cases. At
least, with Mesa-7.6.1-rc1 I get the error mentioned in 31f7.. from
`make linux', and now I don't (and it still works on AIX).
-tom
From c473f6a879ced3288ac6cfe9e5cd20a391e5684a Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Wed, 18 Nov 2009 19:54:20 -0700
Subject: [PATCH 1/2] Define 32bit byteswap for AIX.
Fixes `xlib' driver build on AIX.
---
src/mesa/main/compiler.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 9319505..522295a 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -235,7 +235,12 @@ extern "C" {
#elif defined(__APPLE__)
#include
#define CPU_TO_LE32( x ) CFSwapInt32HostToLittle( x )
-#else /*__linux__ __APPLE__*/
+#elif defined(_AIX)
+#define CPU_TO_LE32( x )x = ((x & 0x00ff) << 24) | \
+((x & 0xff00) << 8) | \
+((x & 0x00ff) >> 8) | \
+((x & 0xff00) >> 24);
+#else /*__linux__ */
#include
#define CPU_TO_LE32( x ) bswap32( x )
#endif /*__linux__*/
--
1.6.3.3
From b2956c004c0a84dd88ba14c4276eba6154f59861 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Wed, 18 Nov 2009 20:19:29 -0700
Subject: [PATCH 2/2] Fix quoting issue with empty set of PROGRAM_DIRS.
Quotes are important to make sure the argument to test -n really
is the empty string, but that requires stringifying PROGRAM_DIRS.
---
progs/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/progs/Makefile b/progs/Makefile
index 3700707..d5852fa 100644
--- a/progs/Makefile
+++ b/progs/Makefile
@@ -4,7 +4,7 @@ TOP = ..
include $(TOP)/configs/current
-SUBDIRS = $(PROGRAM_DIRS)
+SUBDIRS = "$(strip "$(PROGRAM_DIRS)")"
default: message subdirs
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] glXGPA with mangled Mesa
Mangled or no, "glXGetProcAddressARB" exists in Mesa's libGL. From a mangled install: $ nm ~/sw/mesa-git/lib/libMesaGL.so.1 | grep -i glxgetprocad 0004d321 T glXGetProcAddressARB 0004d366 T mglXGetProcAddress $ grep "glXGetProcAddress" ~/sw/mesa-git/include/GL/glx_mangle.h #define glXGetProcAddress mglXGetProcAddress $ Arguably, this is correct, since the Linux OpenGL ABI specifies that this entry point *must* be defined. OTOH, this would prevent an application from linking both /usr/lib/libGL.so && a custom-built mangled Mesa GL, yes? Or rather, if an application developer called "glXGetProcAddressARB", they might expect to call mangled Mesa but instead call their /usr/lib's GPA-ARB. This is unfortunately still relevant, because an app I work on cannot rely on glXGPA existing; at least one user's OGL implementation only has glXGPA-ARB (i.e. doesn't support 1.4). The attached diff is one fix. Is it the correct one? -tom diff --git a/include/GL/glx_mangle.h b/include/GL/glx_mangle.h index 4439a96..fa664a7 100644 --- a/include/GL/glx_mangle.h +++ b/include/GL/glx_mangle.h @@ -76,6 +76,7 @@ /* GLX 1.4 */ #define glXGetProcAddress mglXGetProcAddress +#define glXGetProcAddressARB mglXGetProcAddressARB #endif -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Error building MesaLib 7.6 onto Win32 with Microsoft Visual Studio 2005 and 2008
Delle writes: > Delle wrote: > > > > When I try to buld Mesa version 7.6 onto Win32 I get this error message: > > > > Compiling... > > api_exec.c > > ..\..\..\..\src\mesa\main\api_exec.c(831) : error C2440: '=' : cannot > > convert from 'GLboolean (__cdecl *)(GLsync)' to 'GLboolean (__stdcall > > *)(GLsync)' > > ..\..\..\..\src\mesa\main\api_exec.c(832) : error C2440: '=' : cannot > > convert from 'void (__cdecl *)(GLsync)' to 'void (__stdcall *)(GLsync)' > > ..\..\..\..\src\mesa\main\api_exec.c(833) : error C2440: '=' : cannot > > convert from 'GLsync (__cdecl *)(GLenum,GLbitfield)' to 'GLsync (__stdcall > > *)(GLenum,GLbitfield)' It looks like the calling convention is wrong. I think you can change the default calling convention in the MSVC project file; changing it to stdcall might fix this. api_exec.c or some other code included therein is probably explicitly setting the calling convention for these functions though. Try to track down where that happens and change it to stdcall. I'm sure a patch would be welcome, especially if you could identify why this started happening. Cheers, -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Android support
Chia-I Wu writes: > Hi list, > > I am working on a project to bring Mesa to Android on x86 (intel) > netbooks > > http://www.gitorious.org/android-eeepc [snip] > Android supports OpenGL ES 1.0. So my work is basically opengl-es-v2 > branch, plus support for some new extensions and a new EGL driver, > egl_android, for Android > > http://www.gitorious.org/android-eeepc/mesa/commits/android [snip] > This is JFYI, in case someone finds it interesting. I also hope it > gives more motivations to test out the opengl-es-v2 branch :) This is really cool, Chia-I. How does the android-eeepc stack differ from the stock android stack? Is there a chance of your OpenGL|ES 2.0 work filtering into the latter? We've got an app we'd like to port to `another' mobile platform, but shaders are a sine qua non for us. AFAICT Apple's offerings are the only thing on the market which offer anything beyond fixed functionality. If it was reasonably possible to get your code working on an Android phone, such a device would probably be our next target... Thanks, -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] glX TLS disabled by default?
Dan Nicholson writes: > On Mon, Nov 9, 2009 at 9:52 AM, tom fogal wrote: > > Mark Kettenis writes: > >> > From: Adam Jackson > >> > Date: Mon, 09 Nov 2009 10:51:13 -0500 > >> > > >> > On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote: > >> > > >> > > I vaguely recall there being some interaction with the X > >> > > server. If Mesa is built for TLS, then the X server must also > >> > > be built for TLS. [. . .] [snip] > > In the case that we're building against an X server, is there > > perhaps some kind of configure-time test we could do? Â Then the > > Mesa default could be `autodetect' instead. > > Make it a variable in gl.pc and query it from the xserver configure. Sorry, that was ambiguous; I wasn't trying to ask how this might be done. I was wondering if the X server already provided this information in some way Mesa could figure it out. I imagine someone would have piped up if such support already existed though, so I guess I should volunteer. > gl.pc: > ... > glx_tls = yes > > xserver/configure: > if test "x$GLX_USE_TLS" = xauto; then > GLX_USE_TLS=`$PKG_CONFIG --variable=glx_tls gl` > test -z "$GLX_USE_TLS" && GLX_USE_TLS=no > fi .. but now that you mention it, wouldn't it be the reverse? That is, we'd want the X server to provide a .pc with `tls = something', and have Mesa query the server's .pc? I guess it depends on which is `lower' in the software stack, which I've been assuming is the X server (correct me?). -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] glX TLS disabled by default?
Mark Kettenis writes: > > From: Adam Jackson > > Date: Mon, 09 Nov 2009 10:51:13 -0500 > > > > On Sat, 2009-11-07 at 16:29 -0800, Ian Romanick wrote: > > > > > tom fogal wrote: > > > > Is there any reason TLS for glX is disabled by default? [snip] > > > I vaguely recall there being some interaction with the X server. > > > If Mesa is built for TLS, then the X server must also be built > > > for TLS. [. . .] > > > > There's no intrinsic reason that the GLX loader couldn't support > > both, I suppose, but it would be kind of lame. [plus selinux issue] > > Is the TLS you're talking about here an abreviation for Thread Local > Storage? If so then even OpenBSD doesn't have (sensible) support for > it. Yes, it is. In the case that we're building against an X server, is there perhaps some kind of configure-time test we could do? Then the Mesa default could be `autodetect' instead. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] glX TLS disabled by default?
Is there any reason TLS for glX is disabled by default? Most systems support TLS these days, do they not? Further, I'm not sure if this is shared but my opinion is that the default configurations should cater to the common case. -tom From dd4f53ad4aa0001e0bf0837fca2915bbc066f1ef Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Sat, 7 Nov 2009 12:48:01 -0700 Subject: [PATCH] Enable glX TLS by default. Not actually sure the patch itself is right; is the @<:@ stuff some sort of markup? Or escapes of some kind? Or.. ? --- configure.ac |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index cc588d5..9a5875e 100644 --- a/configure.ac +++ b/configure.ac @@ -638,10 +638,10 @@ dnl dnl More DRI setup dnl AC_ARG_ENABLE([glx-tls], -[AS_HELP_STRING([--enable-glx-tls], -[enable TLS support in GLX @<:@default=disabled@:>@])], +[AS_HELP_STRING([--disable-glx-tls], +[disable TLS support in GLX @<:@default=enabled@:>@])], [GLX_USE_TLS="$enableval"], -[GLX_USE_TLS=no]) +[GLX_USE_TLS=yes]) dnl Directory for DRI drivers AC_ARG_WITH([dri-driverdir], [AS_HELP_STRING([--with-dri-driverdir=DIR], -- 1.6.3.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Proposed Mesa 7.7 / 7.6.1 release schedule
Ian Romanick writes: > As promised, I'm sending out a proposed release schedule before the > 11th hour. [snip -- final 12/21] > Does this sound good to everyone? Works for me. Thanks for the notice; it's very useful for those of us on the fringes of development. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
Brian Paul writes: > tom fogal wrote: > > Sorry, should have used an intro comment mail. > > > > (Assuming all's well,) It would be great if these two could make it > > onto a branch (e.g. 7.6) in addition to master. > > Both look good to me. You can commit, right? In theory, but it hasn't gone through yet: https://bugs.freedesktop.org/show_bug.cgi?id=23311 -tom -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
Sorry, should have used an intro comment mail. (Assuming all's well,) It would be great if these two could make it onto a branch (e.g. 7.6) in addition to master. -tom Tom Fogal writes: > AIX uses ".a" for both static and shared library extensions. > --- > configure.ac |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
AIX uses ".a" for both static and shared library extensions. --- configure.ac |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 7518976..44fb779 100644 --- a/configure.ac +++ b/configure.ac @@ -230,6 +230,8 @@ else LIB_EXTENSION='dylib' ;; cygwin* ) LIB_EXTENSION='dll' ;; +aix* ) +LIB_EXTENSION='a' ;; * ) LIB_EXTENSION='so' ;; esac -- 1.6.3.3 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 2/2] Fix build when PROGRAM_DIRS is empty.
SUBDIRS just takes PROGRAM_DIRS value. If PROGRAM_DIRS gets set to the empty string (as can happen when building only OSMesa), a 'for' loop will lack anything to iterate over, causing a parse error. This fixes the issue by making sure SUBDIRS is the null string when PROGRAM_DIRS is, and wrapping the for loops in if's, causing them only to execute if there are directories to iterate over. --- progs/Makefile | 26 +++--- 1 files changed, 15 insertions(+), 11 deletions(-) diff --git a/progs/Makefile b/progs/Makefile index c99f4ee..064e5a2 100644 --- a/progs/Makefile +++ b/progs/Makefile @@ -4,7 +4,7 @@ TOP = .. include $(TOP)/configs/current -SUBDIRS = $(PROGRAM_DIRS) +SUBDIRS ="$(PROGRAM_DIRS)" default: message subdirs @@ -15,18 +15,22 @@ message: subdirs: - @for dir in $(SUBDIRS) ; do \ - if [ -d $$dir ] ; then \ - (cd $$dir && $(MAKE)) || exit 1 ; \ - fi \ - done + @if test -n "$(SUBDIRS)" ; then \ + for dir in $(SUBDIRS) ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE)) || exit 1 ; \ + fi \ + done \ + fi # Dummy install target install: clean: - -...@for dir in $(SUBDIRS) tests ; do \ - if [ -d $$dir ] ; then \ - (cd $$dir && $(MAKE) clean) ; \ - fi \ - done + -...@if test -n "$(SUBDIRS)" ; then \ + for dir in $(SUBDIRS) tests ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE) clean) ; \ + fi \ + done \ + fi -- 1.6.3.3 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Importing "real" strtod code
Ian Romanick writes:
> The root cause of bug #23308 has been determined to be the use of
> strtod in our assembly and GLSL parsers. When LANG is set to a
> locale that changes the radix from "." to, say, ",", floating point
> numbers are not parsed correctly.
>
> It seems that the correct fix is to have _mesa_strtod actually
> implement strtod and ignore the locale setting.
What about
char *lang = getenv("LANG");
setenv("LANG", "POSIX", 1);
strtod(...);
setenv("LANG", lang, 1);
i.e. push / pop the LANG value?
-tom
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Regenerate gl_mangle.h.
Attached. -tom From 87ce26ad777157de905c33d24e4b24ba09dd9c90 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Tue, 6 Oct 2009 12:16:39 -0600 Subject: [PATCH] Regenerate gl_mangle.h. --- include/GL/gl_mangle.h | 42 ++ 1 files changed, 42 insertions(+), 0 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index 54147f7..59f6149 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -108,12 +108,20 @@ #define glBlendColorEXT MANGLE(BlendColorEXT) #define glBlendColor MANGLE(BlendColor) #define glBlendEquationEXT MANGLE(BlendEquationEXT) +#define glBlendEquationi MANGLE(BlendEquationi) +#define glBlendEquationIndexedAMD MANGLE(BlendEquationIndexedAMD) #define glBlendEquation MANGLE(BlendEquation) #define glBlendEquationSeparateATI MANGLE(BlendEquationSeparateATI) #define glBlendEquationSeparateEXT MANGLE(BlendEquationSeparateEXT) +#define glBlendEquationSeparatei MANGLE(BlendEquationSeparatei) +#define glBlendEquationSeparateIndexedAMD MANGLE(BlendEquationSeparateIndexedAMD) #define glBlendEquationSeparate MANGLE(BlendEquationSeparate) +#define glBlendFunci MANGLE(BlendFunci) +#define glBlendFuncIndexedAMD MANGLE(BlendFuncIndexedAMD) #define glBlendFunc MANGLE(BlendFunc) #define glBlendFuncSeparateEXT MANGLE(BlendFuncSeparateEXT) +#define glBlendFuncSeparatei MANGLE(BlendFuncSeparatei) +#define glBlendFuncSeparateIndexedAMD MANGLE(BlendFuncSeparateIndexedAMD) #define glBlendFuncSeparateINGR MANGLE(BlendFuncSeparateINGR) #define glBlendFuncSeparate MANGLE(BlendFuncSeparate) #define glBlitFramebufferEXT MANGLE(BlitFramebufferEXT) @@ -148,6 +156,7 @@ #define glClientActiveTexture MANGLE(ClientActiveTexture) #define glClientActiveVertexStreamATI MANGLE(ClientActiveVertexStreamATI) #define glClientAttribDefaultEXT MANGLE(ClientAttribDefaultEXT) +#define glClientWaitSync MANGLE(ClientWaitSync) #define glClipPlane MANGLE(ClipPlane) #define glColor3b MANGLE(Color3b) #define glColor3bv MANGLE(Color3bv) @@ -320,6 +329,7 @@ #define glDeleteRenderbuffersEXT MANGLE(DeleteRenderbuffersEXT) #define glDeleteRenderbuffers MANGLE(DeleteRenderbuffers) #define glDeleteShader MANGLE(DeleteShader) +#define glDeleteSync MANGLE(DeleteSync) #define glDeleteTexturesEXT MANGLE(DeleteTexturesEXT) #define glDeleteTextures MANGLE(DeleteTextures) #define glDeleteTransformFeedbacksNV MANGLE(DeleteTransformFeedbacksNV) @@ -341,6 +351,7 @@ #define glDisableIndexedEXT MANGLE(DisableIndexedEXT) #define glDisable MANGLE(Disable) #define glDisableVariantClientStateEXT MANGLE(DisableVariantClientStateEXT) +#define glDisableVertexAttribAPPLE MANGLE(DisableVertexAttribAPPLE) #define glDisableVertexAttribArrayARB MANGLE(DisableVertexAttribArrayARB) #define glDisableVertexAttribArray MANGLE(DisableVertexAttribArray) #define glDrawArraysEXT MANGLE(DrawArraysEXT) @@ -354,7 +365,9 @@ #define glDrawBuffers MANGLE(DrawBuffers) #define glDrawElementArrayAPPLE MANGLE(DrawElementArrayAPPLE) #define glDrawElementArrayATI MANGLE(DrawElementArrayATI) +#define glDrawElementsBaseVertex MANGLE(DrawElementsBaseVertex) #define glDrawElementsInstancedARB MANGLE(DrawElementsInstancedARB) +#define glDrawElementsInstancedBaseVertex MANGLE(DrawElementsInstancedBaseVertex) #define glDrawElementsInstancedEXT MANGLE(DrawElementsInstancedEXT) #define glDrawElementsInstanced MANGLE(DrawElementsInstanced) #define glDrawElements MANGLE(DrawElements) @@ -362,6 +375,7 @@ #define glDrawPixels MANGLE(DrawPixels) #define glDrawRangeElementArrayAPPLE MANGLE(DrawRangeElementArrayAPPLE) #define glDrawRangeElementArrayATI MANGLE(DrawRangeElementArrayATI) +#define glDrawRangeElementsBaseVertex MANGLE(DrawRangeElementsBaseVertex) #define glDrawRangeElementsEXT MANGLE(DrawRangeElementsEXT) #define glDrawRangeElements MANGLE(DrawRangeElements) #define glDrawTransformFeedbackNV MANGLE(DrawTransformFeedbackNV) @@ -378,6 +392,7 @@ #define glEnableIndexedEXT MANGLE(EnableIndexedEXT) #define glEnable MANGLE(Enable) #define glEnableVariantClientStateEXT MANGLE(EnableVariantClientStateEXT) +#define glEnableVertexAttribAPPLE MANGLE(EnableVertexAttribAPPLE) #define glEnableVertexAttribArrayARB MANGLE(EnableVertexAttribArrayARB) #define glEnableVertexAttribArray MANGLE(EnableVertexAttribArray) #define glEndConditionalRender MANGLE(EndConditionalRender) @@ -409,6 +424,7 @@ #define glExecuteProgramNV MANGLE(ExecuteProgramNV) #define glExtractComponentEXT MANGLE(ExtractComponentEXT) #define glFeedbackBuffer MANGLE(FeedbackBuffer) +#define glFenceSync MANGLE(FenceSync) #define glFinalCombinerInputNV MANGLE(FinalCombinerInputNV) #define glFinishAsyncSGIX MANGLE(FinishAsyncSGIX) #define glFinishFenceAPPLE MANGLE(FinishFenceAPPLE) @@ -469,9 +485,11 @@ #define glFramebufferTextureEXT MANGLE(FramebufferTextureEXT) #define glFramebufferTextureFaceARB MANGLE(FramebufferTextureFaceARB) #define
Re: [Mesa3d-dev] [PATCH 0/4] Speed up _glapi_add_dispatch.
Chia-I Wu writes:
> On Mon, Oct 05, 2009 at 11:16:17AM -0600, tom fogal wrote:
> > Chia-I Wu writes:
> > > The third patch fixes a potential segfault. Calling a dynamic
> > > dispatch which is not supported by a DRI driver would crash an
> > > application. It is a bug of the application, since it should
> > > test the corresponding extension before calling such functions.
> > > But it is a simple fix to make such functions become no-op, just
> > > any static function that is not supported by the DRI driver.
> >
> > IMHO, an app *should* segfault in this case. It's a big red "you
> > have a bug" flag for developers, and I have definitely found it
> > useful at times.
>
> When glFooBar is never being SET_FooBar in mesa, it is dispatched to
> generic_nop. The change is mainly to make a dynamic dispatch behave
> exactly the same way. You can see the warnings when MESA_DEBUG is
> set.
>
> Having it crash is helpful sometimes, but it is less OpenGL-ism IMHO.
While I agree MESA_DEBUG is useful to me, a user emailing me saying
that "your application crashed" gets me to the problem a lot quicker
than "the window stays white; nothing ever renders into it".
Seems like this is a matter of opinion at this point, so maybe we
should just let Brian / whoever will commit it decide.
> Also, MANGLE was not and is not supported here on non-x86 platforms
> because of glprocs.h.
Hrm? I might have recently broken our AIX support, then..
> > > +static void
> > > +_glapi_update_dynamic_entry(struct _glapi_function *entry, GLuint offset,
> > >
> > > +const char *parameter_signature)
> > > +{
> > > + if (entry->parameter_signature)
> > > + free((char *) entry->parameter_signature);
> >
> > If we need to cast away the constness of parameter_signature ... maybe
> > parameter_signature should not point to something which is const.
>
> The const-ness is a hint that no function should modify the value
> directly. It can be modified only through the update function.
>
> But I am fine either way. I just feel like to keep the patch simpler.
Again, sounds like a decision not to be made by either of us.
Regardless, I think you're right that it belongs in a separate patch.
> > > - entry[i]->parameter_signature = str_dup(real_sig);
> > > - fill_in_entrypoint_offset(entry[i]->dispatch_stub, offset);
> > > - entry[i]->dispatch_offset = offset;
> > > + if (entry[i] == NULL) {
> > > +entry[i] = _glapi_add_dynamic_entry(function_names[i]);
> > > +if (entry[i] == NULL) {
> > > + /* FIXME: Possible memory leak here.
> > > + */
> >
> > What's leaked? You've simply copied/maintained the existing
> > comment; presumably you know what's going on here now and could
> > expand on the comment.
>
> The error is that, there might already be some dynamic dispatches
> generated when we bail out. The generated dynamic dispatches are
> useable. It can be considered a leak or not.
>
> This patch is about refactoring. I do not intend to introduce
> functional changes if possible. If I do, I will try to document it.
Sorry, I didn't mean to imply that you should fix the leak. I did mean
to imply that it would be nice if you could update the comment from
`possible memory leak' to `we might be leaking any dispatches that were
generated above by returning here w/o cleaning them up' (or similar).
> > Secondly, any chance of using stdlib's bsearch here?
>
> I just had a look at _mesa_bsearch. It seems bsearch is not
> universally available? I think the inline version is also slightly
> faster.
I would bet a custom binary search would outperform any bsearch call,
because there's always going to be a need for a function pointer in the
latter. My preference is still on reusing the existing infrastructure,
until a demonstrated performance benefit justifies not doing so.
Anyway, regardless of which way some of these decisions go, this looks
good to me / your responses have convinced me. I've also applied it
and got one of my dynamic loading test programs to work.
Signed-off-by: Tom Fogal
FWIW.
-tom
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/4] Speed up _glapi_add_dispatch.
Chia-I Wu writes:
> The first two patches refactor glapi_getproc.c. They provide helper
> functions to static dispatches and dynamic dispatches respectively,
> and update the rests to use them. There is only one functional
> change, the handling of MANGLE. Please see the comments in patch 1.
Thanks for this; comments inline.
> The third patch fixes a potential segfault. Calling a dynamic
> dispatch which is not supported by a DRI driver would crash an
> application. It is a bug of the application, since it should test
> the corresponding extension before calling such functions. But it
> is a simple fix to make such functions become no-op, just any static
> function that is not supported by the DRI driver.
IMHO, an app *should* segfault in this case. It's a big red "you have
a bug" flag for developers, and I have definitely found it useful at
times.
That said, I could definitely see the motivation for having a
MESA_DISPATCH_NOOP environment variable, which causes the behavior you
mention here.
[snip]
> The only real difference is in the handling of MANGLE. While
> _glapi_add_dispatch ignored mangled name, add_function_name was
> called with mangled name in _glapi_get_proc_address. It looks like a
> bug, and is fixed.
Yes; thanks. I've known about this for a month or two, but found it by
looking at code and have not been able to devise a case where it can
happen (the OSMesa path apparently does not hit most of this code). If
you have a test for this...
> +#ifdef USE_X86_ASM
> +extern const GLubyte gl_dispatch_functions_start[];
> +#endif
I'm a little concerned that something like this is changing. Your
introductory comment doesn't mention anything about modifying anything
to do with the dispatch itself; it seems like a table is changing from
an unordered -> ordered, and an algorithm from linear search -> binary
search. Thus changing the declaration type / decl. location of the
table itself doesn't seem like it would happen.
Not to say it's incorrect, just that I'd like to hear why something
like this is changing, given the ostensible purpose of the patch
series.
> static const glprocs_table_t *
> -find_entry( const char * n )
> +_glapi_find_static_entry(const char *funcName)
> {
> GLuint i;
> for (i = 0; static_functions[i].Name_offset >= 0; i++) {
>const char *testName = gl_string_table + static_functions[i].Name_offs
> et;
> -#ifdef MANGLE
> - /* skip the "m" prefix on the name */
> - if (strcmp(testName, n + 1) == 0)
> -#else
> - if (strcmp(testName, n) == 0)
> -#endif
> - {
> - return &static_functions[i];
> - }
> + if (strcmp(testName, funcName) == 0)
> + return &static_functions[i];
The "MANGLE" case is missing here, no?
> -#if !defined(XFree86Server) && !defined(XGLServer)
> -#ifdef USE_X86_ASM
> -
> -#if defined( GLX_USE_TLS )
> -extern GLubyte gl_dispatch_functions_start[];
> -extern GLubyte gl_dispatch_functions_end[];
> -#else
> -extern const GLubyte gl_dispatch_functions_start[];
> -#endif
> -
> -#endif /* USE_X86_ASM */
Likewise, again, with the `unexpected changes'.
> @@ -537,12 +539,14 @@ _glapi_get_proc_address(const char *funcName)
> GLuint i;
>
> #ifdef MANGLE
> - if (funcName[0] != 'm' || funcName[1] != 'g' || funcName[2] != 'l')
> + if (funcName[0] != 'm')
>return NULL;
> -#else
> + /* skip the "m" prefix on the name */
> + funcName++;
> +#endif
> +
> if (funcName[0] != 'g' || funcName[1] != 'l')
>return NULL;
I like the updated logic here.
> Subject: [PATCH 2/4] glapi: Refactor dynamic dispatches.
>
> Provide helper functions for handling dynamic dispatches. There is no
> functional change.
[snip]
> +static struct _glapi_function *
> +_glapi_find_dynamic_entry(const char *funcName)
> +{
> + struct _glapi_function *entry = NULL;
> + GLuint i;
> + for (i = 0; i < _glapi_num_dynamic_functions; i++) {
> + if (strcmp(_glapi_dynamic_functions[i].name, funcName) == 0) {
> + entry = &_glapi_dynamic_functions[i];
> + break;
> + }
> + }
This function needs an #ifdef MANGLE case as well, no? Or are dynamic
symbols never given the "m" prefix? If so, it seems like we're
relegating responsibility for removing the prefix to the caller. I'm
not sure I have a preference either way, but such a note should make an
intro comment to the function.
> /**
> + * Update the dispatch offset and parameter signature of a dynamic entry.
> + */
> +static void
> +_glapi_update_dynamic_entry(struct _glapi_function *entry, GLuint offset,
> +const char *parameter_signature)
> +{
> + if (entry->parameter_signature)
> + free((char *) entry->parameter_signature);
If we need to cast away the constness of parameter_signature ... maybe
parameter_signature should not point to something which is const.
> @@ -455,55 +509,40 @@ _glapi_add_dispatch( const char * const * function_name
[snip]
> - if (strcmp(ExtEntryT
Re: [Mesa3d-dev] Mesa 7.6 released
Ian Romanick writes: > Mesa 7.6 is now available. This is a bug-fix release. For details, > see the release notes at http://www.mesa3d.org/relnotes-7.6.html ? 7.6 is a bug-fix release? Also, the relnotes (for both releases) do not seem to have propagated to the website yet. Attached is a diff for master's news.html. -tom diff --git a/docs/news.html b/docs/news.html index 07ad42e..5deb712 100644 --- a/docs/news.html +++ b/docs/news.html @@ -10,6 +10,17 @@ News +September 28, 2009 + +Mesa 7.6 is released. This is a new feature +release. Those especially concerned about stability may want to wait for the +follow-on 7.6.1 bug-fix release. + + +Mesa 7.5.2 is released. This is a stable +release fixing bugs since the 7.5.1 release. + + September 3, 2009 -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] dump a debug image?
I'm trying to debug a strange readback issue in a large software system. I find it quite useful to dump an image of what's in the framebuffer at various points in the process. I've grabbed a write_ppm method out of an (OS?)Mesa demo, and I call it periodically to see what I've got in the buffer. There's a point in time where I have a good buffer, and then there's a point in time where, if I had to guess, I'd say some code is interpreting the buffer as `GRB' data. I'd like to dump the buffer while I'm in Mesa at this point -- e.g. every time _swrast_ReadPixels gets called, write out an image with what Mesa would return. Seems like someone else might have found a use for something similar before. Is there anything in Mesa to help me out here, or should I just ad hoc hack in the image dump myself? Thanks, -tom -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6 branch coming
Ian Romanick writes: > Keith Whitwell wrote: > > On Thu, 2009-09-03 at 15:13 -0700, Michel Dänzer wrote: > >> On Thu, 2009-09-03 at 14:43 -0700, Ian Romanick wrote: > >>> 2. It becomes increasing difficult to merge (as opposed to cherry-pick) > >>> from one branch to the other as the branches diverge. Michel has run > >>> into this. [snip] > > There are a couple of points in favour of the periodic merge approach, [snip] > >>From that point on, it is natural to want to be 100% sure that bug-fixes > > have been preserved, and periodically merging the 7.6 branch to master > > guarantees that none of those bugfixes will be lost/forgotten. > > > > This doesn't prevent people who want to work a different way from > > developing bugfixes on master and cherry-picking them to stable, but > > it's not a natural workflow for the case where a bug is spotted on > > stable and needs to be fixed on stable. > > That depends entirely on whether or not the bug also exists on master. [snip] > The natural work flow is [. . .] FWIW, git includes an overview of how git.git runs in gitworkflows(7). It describes a system where bugfixes are applied to the oldest possible location in history, and graduate upwards (towards instability). Cherry-picks are still used for the occasional mistakes that get applied to unstable places but should be stable. Sounds like this would require more discipline on the part of developers. Not that I'm going as far as to advocate their approach, but it does have the benefit that we know it works... else we wouldn't be having this discussion ;) -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] mesa: Compact state key for TexEnv program cache
writes:
> On Wed, 2009-09-02 at 09:05 -0700, Keith Whitwell wrote:
> > On Wed, 2009-09-02 at 08:48 -0700, José Fonseca wrote:
> > > On Wed, 2009-09-02 at 05:11 -0700, Chris Wilson wrote:
> > > > By rearranging the bitfields within the key we can reduce the size
> > > > of the key from 644 to 196 bytes, reducing the cost of both the
> > > > hashing and equality tests.
> > > > ---
> > > > src/mesa/main/texenvprogram.c |7 ---
> > > > 1 files changed, 4 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/src/mesa/main/texenvprogram.c b/src/mesa/main/texenvprogra
> m.c
> > > > index 5913957..3851937 100644
> > > > --- a/src/mesa/main/texenvprogram.c
> > > > +++ b/src/mesa/main/texenvprogram.c
> > > > @@ -82,8 +82,8 @@ texenv_doing_secondary_color(GLcontext *ctx)
> > > > #define DISASSEM (MESA_VERBOSE & VERBOSE_DISASSEM)
> > > >
> > > > struct mode_opt {
> > > > - GLuint Source:4; /**< SRC_x */
> > > > - GLuint Operand:3; /**< OPR_x */
> > > > + GLubyte Source:4; /**< SRC_x */
> > > > + GLubyte Operand:3; /**< OPR_x */
> > > > };
> > >
> > > This doesn't compact anything. This chunk stay as is.
> >
> > The size of the struct decreases from 4 bytes to one.
[snip -- simplified example]
> Interesting. Gcc is trying to do something smart with alignment.
In that case, wouldn't adding
__attribute__((__packed__))
to the struct def have the same effect (and not rely on a side effect
of how gcc's alignment algorithm works)?
I'm not sure of the MSVC equivalent, but I imagine an equivalent
exists.
-tom
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Merging asm-shader-rework-1 branch today
Ian Romanick writes: > Philipp Heise wrote: > > Ian Romanick wrote: > >> Roland Scheidegger wrote: > >> > >>> glprogs/R200_interaction.vp > >>> GL_PROGRAM_ERROR_STRING_ARB: line 1, char 43: error: syntax error, > >>> unexpected $undefined > >> Okay. I posted a patch to bug #23457 that should fix this. [snip] > > The problem is not the header of the vp, but the additional > > carriage return at the end of each line > > Oh good grief! It's always the little things. Hmm... Unix uses > \n, and DOS uses \r\n. Don't Macs use \r? If that's the case, the > proposed patch could cause the line numbers to be incorrect if the > shaders are authored on Macs. You're thinking of old Macs: OS 9 and probably below. OS 10 uses '\n'. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] max viewport size in main/config.h
Brian Paul writes: > tom fogal wrote: > > Brian Paul writes: > >> Dan Nicholson wrote: > >>> On Thu, Aug 13, 2009 at 7:10 PM, tom fogal wrote: > >>>> Brian Paul writes: > >>>>> tom fogal wrote: > >>>>>> Perhaps we could have [...] a --with-max-width=16384 [which] could > >>>>>> accomodate our case without inflating the standard buffer sizes. > > [snip] > >>>> 3 patches attached. > >>>> > >>>> 1. aforementioned define change > >>>> 2. autoconf changes as described here + warning > >>>> 3. FAQ entry for this. [snip] > > Any chance 1 && 2 could be cherry picked to the 7.5 branch? > > Done. Thank you! > Do you have git-write ability, Tom? I do not. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] max viewport size in main/config.h
Brian Paul writes: > Dan Nicholson wrote: > > On Thu, Aug 13, 2009 at 7:10 PM, tom fogal wrote: > >> Brian Paul writes: > >>> tom fogal wrote: > >>>> Perhaps we could have [...] a --with-max-width=16384 [which] could > >>>> accomodate our case without inflating the standard buffer sizes. [snip] > >> 3 patches attached. > >> > >> 1. aforementioned define change > >> 2. autoconf changes as described here + warning > >> 3. FAQ entry for this. > >> > >> They apply cleanly to both master and mesa_7_5_branch. > > > > For the autoconf patch, the custom has been to put macros into the > > DEFINES variable. Otherwise, looks good. > > I've made that change and committed the patches. Excellent, thank you! Any chance 1 && 2 could be cherry picked to the 7.5 branch? -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] max viewport size in main/config.h
Brian Paul writes:
> tom fogal wrote:
> > Is there interest in bumping [the MAX_WIDTH/HEIGHT] limit up? Are
> > there issues we're not considering when we do this?
> >
> > Perhaps we could have [...] a --with-max-width=16384 [which] could
> > accomodate our case without inflating the standard buffer sizes.
>
> I should add this to the FAQ because I answer it every 6 months or
> so...
[snip]
> I'd be OK with modifying config.h to read:
>
> #ifndef MAX_WIDTH
> #define MAX_WIDTH 4096
> #endif
>
> Then allowing a config option like --with-max-width=16384 which
> defines MAX_WIDTH, MAX_HEIGHT. Feel free to submit a patch.
Sure. 3 patches attached.
1. aforementioned define change
2. autoconf changes as described here + warning
3. FAQ entry for this.
They apply cleanly to both master and mesa_7_5_branch.
Thanks,
-tom
From b63ce6b6ede7f97f8c2c5bf74e7efdd5630c3995 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Thu, 13 Aug 2009 19:23:54 -0600
Subject: [PATCH] Allow external settings of MAX_WIDTH/HEIGHT.
Conditionalize MAX_WIDTH / MAX_HEIGHT defines so that users can
set them via CFLAGS.
---
src/mesa/main/config.h |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index f77a29a..e4995c3 100644
--- a/src/mesa/main/config.h
+++ b/src/mesa/main/config.h
@@ -138,9 +138,14 @@
/**
* Maximum viewport/image width. Must accomodate all texture sizes too.
*/
-#define MAX_WIDTH 4096
+
+#ifndef MAX_WIDTH
+# define MAX_WIDTH 4096
+#endif
/** Maximum viewport/image height */
-#define MAX_HEIGHT 4096
+#ifndef MAX_HEIGHT
+# define MAX_HEIGHT 4096
+#endif
/** Maxmimum size for CVA. May be overridden by the drivers. */
#define MAX_ARRAY_LOCK_SIZE 3000
--
1.5.6.5
From 0c9173a432f157b482cdfeea16022f771599d4cc Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Thu, 13 Aug 2009 19:40:30 -0600
Subject: [PATCH] Add configure options for MAX_WIDTH/HEIGHT.
This adds two --with configure options for setting defines for
MAX_WIDTH and MAX_HEIGHT. It's conceivably just as easy to define
these in CFLAGS manually, but this way users don't need to know
about internal Mesa details.
---
configure.ac | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9b65d96..0f50c6d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1159,6 +1159,21 @@ AC_ARG_WITH([xorg-driver-dir],
[XORG_DRIVER_INSTALL_DIR="${libdir}/xorg/modules/drivers"])
AC_SUBST([XORG_DRIVER_INSTALL_DIR])
+AC_ARG_WITH([max-width],
+[AS_HELP_STRING([--with-max-width=N],
+[Maximum framebuffer width (4096)])],
+[CFLAGS="${CFLAGS} -DMAX_WIDTH=${withval}";
+ AS_IF([test "${withval}" -gt "4096"],
+ [AC_MSG_WARN([Large framebuffer: see s_tritemp.h comments.])])]
+)
+AC_ARG_WITH([max-height],
+[AS_HELP_STRING([--with-max-height=N],
+[Maximum framebuffer height (4096)])],
+[CFLAGS="${CFLAGS} -DMAX_HEIGHT=${withval}";
+ AS_IF([test "${withval}" -gt "4096"],
+ [AC_MSG_WARN([Large framebuffer: see s_tritemp.h comments.])])]
+)
+
dnl
dnl Gallium Intel configuration
dnl
--
1.5.6.5
From 26a80fb75601b9790f63fa4c6d3510601527f1a2 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Thu, 13 Aug 2009 19:51:57 -0600
Subject: [PATCH] Add a FAQ about internal buffer sizes.
---
docs/faq.html | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/docs/faq.html b/docs/faq.html
index 11b5d43..65e279a 100644
--- a/docs/faq.html
+++ b/docs/faq.html
@@ -316,6 +316,19 @@ Basically, applying a translation of (0.375, 0.375, 0.0) to your coordinates
will fix the problem.
+3.6 How can I change the maximum framebuffer size in Mesa's
+swrast backend?
+
+These can be overridden by using the --with-max-width and
+--with-max-height options. The two need not be equal.
+
+Do note that Mesa uses these values to size some internal buffers,
+so increasing these sizes will cause Mesa to require additional
+memory. Furthermore, increasing these limits beyond 4096
+may introduce rasterization artifacts; see the leading comments in
+src/mesa/swrast/s_tritemp.h.
+
+
--
1.5.6.5
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] max viewport size in main/config.h
Our package includes Mesa as part of its build, and we use swrast for rendering in certain cases. For quite some time now, we've been patching the Mesa source to define the MAX_WIDTH/HEIGHT in config.h to be a bit larger: currently 16k^2. Is there interest in bumping this limit up? Are there issues we're not considering when we do this? Perhaps we could have a config.h.in which gets generated during configuration, and a --with-max-width=16384 could accomodate our case without inflating the standard buffer sizes. Thanks, -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] egl: Silence warnings on x86-64.
tom fogal writes: > Chia-I Wu writes: > > On Tue, Jul 28, 2009 at 11:10:43AM -0600, tom fogal wrote: > > > Hrm. I would argue that both places should read something more like: > > > #if C99 is supported > > > # include > > > #else > > > /* some typedefs */ > > > #endif > > > > I prefer your c99/non-c99 method, both in eglcompiler.h and mesa's > > main compiler.h. But my concern is that I only have gcc to test. [snip] > I'd volunteer to test compiler.h on vs2008 though, and presumably the > code would be the same in both places so that'd be enough. FWIW, I've verified that master compiles on vs2005 with: #if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) # include #elif defined(_MSC_VER) typedef __int8 int8_t; ... #else # include #endif in both compiler.h and eglcompiler.h (though I'm not sure I'm compiling egl). This is the code/approach currently implemented in eglcompiler.h, as these patches were committed. I do get some link errors from functions in queryobj.c, but this doesn't seem related -- I got them 'out of the box' as well. Cheers, -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] egl: Silence warnings on x86-64.
Chia-I Wu writes: > > On Tue, Jul 28, 2009 at 09:14:04PM -0600, tom fogal wrote: > > Chia-I Wu writes: > > > On Tue, Jul 28, 2009 at 11:10:43AM -0600, tom fogal wrote: > > > > Hrm. I would argue that both places should read something more like: > > > > #if C99 is supported > > > > # include > > > > #else > > > > /* some typedefs */ > > > > #endif > > > > Or perhaps something more robust / maintained by a third party > > > > entity (like the `msinttypes' project you mention; boost has a > > > > similar header which probably isn't C++-specific; I'm sure there's > > > > others out there) could be integrated. > > > > Anyway, presumably the above #if sequence would "just work" when > > > > (if?) MS finally decides to support enough C99 to update that > > > > define. > > > I prefer your c99/non-c99 method, both in eglcompiler.h and mesa's > > > main compiler.h. But my concern is that I only have gcc to test. > > > Only if I have more platforms (i.e. visual studio) to test, or > > > someone would like to help, I am not comfortable enough to send a > > > patch that changes compiler.h. > > > I'll be honest, even after half-paying-attention here for awhile, I'd > > have to google EGL to know what it is, let alone how to enable it. I'd > > volunteer to test compiler.h on vs2008 though, and presumably the code > > would be the same in both places so that'd be enough. > > hmm, I couldn't come up with a sane way to handle the #else part. > The best I can do is to prefer stdint.h on c99 compiler, as can be > seen in the attachment. The only thing needs to be tested becomes > does VS guarantee the existence of stdint.h when it claims c99? I can't imagine a compiler vendor would report c99 support but not actually support it. > -#if defined(_MSC_VER) > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > +# include > +#elif defined(_MSC_VER) > typedef __int8 int8_t; > typedef unsigned __int8uint8_t; > typedef __int16int16_t; Why not just "#else"? Anyway, I'll give it a try sometime today. Thanks, -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] egl: Silence warnings on x86-64.
Chia-I Wu writes: > On Tue, Jul 28, 2009 at 11:10:43AM -0600, tom fogal wrote: > > Hrm. I would argue that both places should read something more like: > > #if C99 is supported > > # include > > #else > > /* some typedefs */ > > #endif > > Or perhaps something more robust / maintained by a third party > > entity (like the `msinttypes' project you mention; boost has a > > similar header which probably isn't C++-specific; I'm sure there's > > others out there) could be integrated. > > Anyway, presumably the above #if sequence would "just work" when > > (if?) MS finally decides to support enough C99 to update that > > define. > > I prefer your c99/non-c99 method, both in eglcompiler.h and mesa's > main compiler.h. But my concern is that I only have gcc to test. > Only if I have more platforms (i.e. visual studio) to test, or > someone would like to help, I am not comfortable enough to send a > patch that changes compiler.h. I'll be honest, even after half-paying-attention here for awhile, I'd have to google EGL to know what it is, let alone how to enable it. I'd volunteer to test compiler.h on vs2008 though, and presumably the code would be the same in both places so that'd be enough. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] egl: Silence warnings on x86-64.
Chia-I Wu writes: > On Mon, Jul 27, 2009 at 10:07:37AM -0600, tom fogal wrote: > > > /** > > > + * Get standard integer types > > > + */ > > > +#if defined(_MSC_VER) > > > + typedef __int8 int8_t; > > > + typedef unsigned __int8uint8_t; > > [snip] > > > +#else > > > +# include > > > +#endif > > I think this would make more sense predicated on __STDC_VERSION__ > > compared to 199901L (i.e. c99 path and non-c99 path). > > This is the part of C that I never know how to do right, and therefore I > stole it from mesa/main/compiler.h. > > I read it as > > #if defined(_MSC_VER) > /* some typedefs */ > #elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) > #include > #else > /* no better way, hope the best */ > #include > #endif Hrm. I would argue that both places should read something more like: #if C99 is supported # include #else /* some typedefs */ #endif Or perhaps something more robust / maintained by a third party entity (like the `msinttypes' project you mention; boost has a similar header which probably isn't C++-specific; I'm sure there's others out there) could be integrated. Anyway, presumably the above #if sequence would "just work" when (if?) MS finally decides to support enough C99 to update that define. -tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] egl: Silence warnings on x86-64.
Chia-I Wu writes: > /** > + * Get standard integer types > + */ > +#if defined(_MSC_VER) > + typedef __int8 int8_t; > + typedef unsigned __int8uint8_t; [snip] > +#else > +# include > +#endif I think this would make more sense predicated on __STDC_VERSION__ compared to 199901L (i.e. c99 path and non-c99 path). -tom -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] added depth-tex-compare test.
Ben Holmes writes:
[snip]
> +glEnable(GL_TEXTURE_2D);
> + glEnable(GL_BLEND);
> + glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
[snip]
> +static void
> +loadTex()
> +{
> + int height = 2;
> +int width = 2;
> +int i, j;
> +
> + GLfloat texDepthData[width][height];
> + for (i=0; i < width; ++i) {
> + for (j=0; j < height; ++j) {
[snip]
> + //depth texture 0 using LUMINANCE
> +glGenTextures(3, tex);
> +glBindTexture(GL_TEXTURE_2D, tex[0]);
> + glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_FALSE);
[snip]
And so on. Looks like your editor is outputting a mix of spaces and
tabs.
-tom
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] GLSL vec4 array support
The appended GLSL fragment shader is giving me a syntax error using
2ba98efdf6653a4cb885d576d2e6f349c69679d4 . A bit of experimentation
suggests it is the array of colors created. Does Mesa support:
vec4 somearray[] = vec4[] (
vec4(0.0, 0.0, 0.0, 0.0)
);
?
Also, I attached a couple patches covering minor issues. 0001 is
probably wrong; seems like these libs should probably end up in
GL_LIB_DEPS but don't in my configuration (autoconf, osmesa, no
gallium, no egl, mangled).
-tom
Shader that fails with a syntax error:
#version 120
uniform sampler3D texVolume; ///< the data volume
uniform sampler1D texTrans1D; ///< the 1D Transfer function
uniform float fTransScale;///< scale for 1D Transfer function lookup
uniform float fStepScale; ///< opacity correction quotient
vec4 r3d_lut(float value) {
const float alpha = 0.6;
const float mn = -0.998139;
const float mx = 0.998138;
int i;
vec4 colors[7] = vec4[] (
vec4(0.0, 0.0, 1.0, alpha),
vec4(0.0, 1.0, 0.0, alpha),
vec4(0.0, 1.0, 1.0, alpha),
vec4(1.0, 0.0, 0.0, alpha),
vec4(1.0, 0.0, 1.0, alpha),
vec4(1.0, 1.0, 0.0, alpha),
vec4(1.0, 1.0, 1.0, alpha)
);
const float incr = (mx - mn) / float(colors.length);
float v = mn;
for(i=0; i < 7 && v < value; i++) { v += incr; }
return colors[i];
}
void main(void)
{
/// get volume value
float fVolumVal = texture3D(texVolume, gl_TexCoord[0].xyz).x;
/// apply 1D transfer function
vec4 vTransVal = texture1D(texTrans1D, fVolumVal*fTransScale);
/// apply opacity correction
vTransVal.a = 1.0 - pow(1.0 - vTransVal.a, fStepScale);
// premultiply color with alpha (for front to back)
vTransVal.xyz *= vTransVal.a;
/// write result to fragment color
gl_FragColor= vTransVal;
//gl_FragColor = r3d_lut(fVolumVal);
}
Note that if one comments out the r3d_lut method the shader compiles
successfully.
From dd6911509e09d41c69c393008102ca895a6683cd Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Fri, 17 Jul 2009 20:17:10 -0600
Subject: [PATCH] Fix 'glslcompiler' compilation.
---
src/mesa/drivers/glslcompiler/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/glslcompiler/Makefile b/src/mesa/drivers/glslcompiler/Makefile
index ffe4e0a..a56d59d 100644
--- a/src/mesa/drivers/glslcompiler/Makefile
+++ b/src/mesa/drivers/glslcompiler/Makefile
@@ -33,7 +33,7 @@ default: $(PROGRAM)
glslcompiler: $(OBJECTS)
- $(CC) $(OBJECTS) $(GL_LIB_DEPS) -o $@
+ $(CC) $(OBJECTS) $(GL_LIB_DEPS) -o $@ -lpthread -lm -ldl
glslcompiler.o: glslcompiler.c
--
1.5.6.5
From 24825c2ebf2f45d8454aead994a668eedb8c19a8 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Fri, 17 Jul 2009 20:18:28 -0600
Subject: [PATCH] Fix 'glslcompiler' example run.
Command line option is "number", not "numbers".
---
docs/shading.html |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/docs/shading.html b/docs/shading.html
index 77c86be..dfef054 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -213,7 +213,7 @@ Here's an example of using the compiler to compile a vertex shader and
emit GL_ARB_vertex_program-style instructions:
-bin/glslcompiler --debug --numbers --fs progs/glsl/CH06-brick.frag.txt
+bin/glslcompiler --debug --number --fs progs/glsl/CH06-brick.frag.txt
results in:
--
1.5.6.5
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.5 release today
Brian Paul writes: > I think I'm going to finally bite the bullet and make the 7.5 release > today. There's still ongoing minor bug fixing, but there'll be a > 7.5.1 release sooner or later anyway. Could you expound on the known issues (not necessarily an exhaustive list, of course)? I've been waiting on 7.5 to upgrade the Mesa that's builtin to our app, and the list might cause me to wait until 7.5.1. -tom -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] added point-sprite test.
writes: > Am Friday 10 July 2009 01:27:22 schrieb Ian Romanick: > > Ben Holmes wrote: > > I'll let someone else comment here to be sure. I believe that we're not > > counting on C99 (or C++) in piglit, so variable declarations cannot be > > mixed with code. Do we care? [snip] > I don't think there's ever been a discussion on C99. My personal > opinion is to go ahead and just use its features. It's been 10 years > after all and should b e well supported on all interesting platforms > by now. MS' compiler still lacks some basic c99 support. I just tested with cl 15.00.30729.01 (i.e. VS 2008) && couldn't mix declarations w/ code. Maybe MS support isn't a big deal for test code, but just FYI. -tom -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Request for $DESTDIR support in Makefile
Hi, Anders Juel Jensen writes: > It would make life a lot easier for both packagers and testers if > the autotools based build system could be made to support DESTDIR, > like most other autotools based packages does. This is the wrong forum/time to ask this question, but I've noted similar support mentioned in other contexts here and again and never understood the point. It seems to me like "./configure --prefix=/tmp/my-new-mesa-package/usr && make && make install" would have the same effect. What does DESTDIR accomplish that prefix does not? Thanks, -tom -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB_texture_float disabled, but implemented?
Zack Rusin writes: > On Sunday 14 June 2009 20:29:47 tom fogal wrote: > > My application was failing because we were creating floating > > point textures. We would get an INVALID_VALUE by specifying a > > ARB_texture_float internal format for glTexImage2D. > > > > The attached two-line diff enables the extension, and my app gets by > > the Mesa check that was failing (dunno about farther; need to run). It > > seems like the extension is implemented but disabled for some reason, > > though I'm basing that on a cursory look through the code and could be > > wrong. > > > > I haven't tried ATI_texture_float yet, but I'm worried that I don't see > > it in `extensions.c'. > > > > Could anyone comment on any issue[s] with ARB_float_texture in Mesa? > > This is likely the most commonly asked question on this list. In > short look at the "IP Status" section of ARB_texture_float. For reference, the patent is online: http://www.freepatentsonline.com/6650327.html Anyway, yeah, I did notice that, but since the extension is 5 years old now I had figured I missed a point when it was labelled unenforceable. I mentioned the patent to a colleague at lunch, who recommended we patent multidimensional arrays. I guess I should take this to mean SGI hasn't relinquished their stake here. Has anybody contacted this `Doug Crisman' mentioned in the spec? > If you'd like more details there are numerous discussions related to > it in the archives. I only found: http://www.nabble.com/Floating-point-texture-support-(enabling-GPGPU-applications)-td21516913.html http://www.nabble.com/ARB_texture_float--td13515437.html There's an unverified indication that one can get an FP texture by talking directly to a driver instead of through extensions. Is there a path by which one can do this? I guess, in short, what is an application supposed to do if it wants floating point textures while supporting a range of OpenGL implementations? -tom -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] ARB_texture_float disabled, but implemented?
My application was failing because we were creating floating
point textures. We would get an INVALID_VALUE by specifying a
ARB_texture_float internal format for glTexImage2D.
The attached two-line diff enables the extension, and my app gets by
the Mesa check that was failing (dunno about farther; need to run). It
seems like the extension is implemented but disabled for some reason,
though I'm basing that on a cursory look through the code and could be
wrong.
I haven't tried ATI_texture_float yet, but I'm worried that I don't see
it in `extensions.c'.
Could anyone comment on any issue[s] with ARB_float_texture in Mesa?
Thanks,
-tom
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 490110a..050dc56 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -71,7 +71,7 @@ static const struct {
{ OFF, "GL_ARB_texture_env_combine",F(ARB_texture_env_combine) },
{ OFF, "GL_ARB_texture_env_crossbar", F(ARB_texture_env_crossbar) },
{ OFF, "GL_ARB_texture_env_dot3", F(ARB_texture_env_dot3) },
- { OFF, "GL_MESAX_texture_float",F(ARB_texture_float) },
+ { ON, "GL_MESAX_texture_float",F(ARB_texture_float) },
{ OFF, "GL_ARB_texture_mirrored_repeat",F(ARB_texture_mirrored_repeat)},
{ OFF, "GL_ARB_texture_non_power_of_two", F(ARB_texture_non_power_of_two)},
{ OFF, "GL_ARB_texture_rectangle", F(NV_texture_rectangle) },
@@ -220,7 +220,7 @@ _mesa_enable_sw_extensions(GLcontext *ctx)
ctx->Extensions.ARB_texture_env_combine = GL_TRUE;
ctx->Extensions.ARB_texture_env_crossbar = GL_TRUE;
ctx->Extensions.ARB_texture_env_dot3 = GL_TRUE;
- /*ctx->Extensions.ARB_texture_float = GL_TRUE;*/
+ ctx->Extensions.ARB_texture_float = GL_TRUE;
ctx->Extensions.ARB_texture_mirrored_repeat = GL_TRUE;
ctx->Extensions.ARB_texture_non_power_of_two = GL_TRUE;
#if FEATURE_ARB_vertex_program
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] OS X: _glCopyBufferSubData undefined on master
tom fogal writes: > Compilation is broken on OS X 10.5.7 using master's HEAD [1]: [snip] > mklib: Making Darwin shared library: libOSMesa.7.6.dylib > Undefined symbols: > "_glCopyBufferSubData", referenced from: > _static_functions in libglapi.a(glapi_getproc.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status Err, should have realized this earlier but this of course also happens on Linux, it just occurs earlier on a Mac. On Linux, it happens when linking an app against OSMesa, as opposed to linking OSMesa itself. Actually, upon further investigation, it looks like the symbol just exists non-mangled when it should not. t...@shigeru lib nm libOSMesa.so | grep -i glCopyBuffer U glCopyBufferSubData 0028c3c0 T mglCopyBufferSubData Based on: fe0ccf323daba2a5e2f0d9936477c73db044190a I think gl_mangle.h just needed regenerating. Attached patch solves the problem. Well, my application links again, at least... -tom From 49024ca1a9960e8e173a7a1fa6fd58740bf97069 Mon Sep 17 00:00:00 2001 From: Tom Fogal Date: Sun, 14 Jun 2009 17:59:50 -0600 Subject: [PATCH] mesa: regenerate gl_mangle.h file. --- include/GL/gl_mangle.h | 34 +- 1 files changed, 33 insertions(+), 1 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index 639d7bb..54147f7 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -53,6 +53,7 @@ #define glBeginFragmentShaderATI MANGLE(BeginFragmentShaderATI) #define glBegin MANGLE(Begin) #define glBeginOcclusionQueryNV MANGLE(BeginOcclusionQueryNV) +#define glBeginPerfMonitorAMD MANGLE(BeginPerfMonitorAMD) #define glBeginQueryARB MANGLE(BeginQueryARB) #define glBeginQuery MANGLE(BeginQuery) #define glBeginTransformFeedbackEXT MANGLE(BeginTransformFeedbackEXT) @@ -257,6 +258,7 @@ #define glConvolutionParameteri MANGLE(ConvolutionParameteri) #define glConvolutionParameterivEXT MANGLE(ConvolutionParameterivEXT) #define glConvolutionParameteriv MANGLE(ConvolutionParameteriv) +#define glCopyBufferSubData MANGLE(CopyBufferSubData) #define glCopyColorSubTableEXT MANGLE(CopyColorSubTableEXT) #define glCopyColorSubTable MANGLE(CopyColorSubTable) #define glCopyColorTable MANGLE(CopyColorTable) @@ -309,6 +311,7 @@ #define glDeleteLists MANGLE(DeleteLists) #define glDeleteObjectARB MANGLE(DeleteObjectARB) #define glDeleteOcclusionQueriesNV MANGLE(DeleteOcclusionQueriesNV) +#define glDeletePerfMonitorsAMD MANGLE(DeletePerfMonitorsAMD) #define glDeleteProgram MANGLE(DeleteProgram) #define glDeleteProgramsARB MANGLE(DeleteProgramsARB) #define glDeleteProgramsNV MANGLE(DeleteProgramsNV) @@ -343,6 +346,7 @@ #define glDrawArraysEXT MANGLE(DrawArraysEXT) #define glDrawArraysInstancedARB MANGLE(DrawArraysInstancedARB) #define glDrawArraysInstancedEXT MANGLE(DrawArraysInstancedEXT) +#define glDrawArraysInstanced MANGLE(DrawArraysInstanced) #define glDrawArrays MANGLE(DrawArrays) #define glDrawBuffer MANGLE(DrawBuffer) #define glDrawBuffersARB MANGLE(DrawBuffersARB) @@ -352,6 +356,7 @@ #define glDrawElementArrayATI MANGLE(DrawElementArrayATI) #define glDrawElementsInstancedARB MANGLE(DrawElementsInstancedARB) #define glDrawElementsInstancedEXT MANGLE(DrawElementsInstancedEXT) +#define glDrawElementsInstanced MANGLE(DrawElementsInstanced) #define glDrawElements MANGLE(DrawElements) #define glDrawMeshArraysSUN MANGLE(DrawMeshArraysSUN) #define glDrawPixels MANGLE(DrawPixels) @@ -381,6 +386,7 @@ #define glEndList MANGLE(EndList) #define glEnd MANGLE(End) #define glEndOcclusionQueryNV MANGLE(EndOcclusionQueryNV) +#define glEndPerfMonitorAMD MANGLE(EndPerfMonitorAMD) #define glEndQueryARB MANGLE(EndQueryARB) #define glEndQuery MANGLE(EndQuery) #define glEndTransformFeedbackEXT MANGLE(EndTransformFeedbackEXT) @@ -485,6 +491,7 @@ #define glGenFramebuffers MANGLE(GenFramebuffers) #define glGenLists MANGLE(GenLists) #define glGenOcclusionQueriesNV MANGLE(GenOcclusionQueriesNV) +#define glGenPerfMonitorsAMD MANGLE(GenPerfMonitorsAMD) #define glGenProgramsARB MANGLE(GenProgramsARB) #define glGenProgramsNV MANGLE(GenProgramsNV) #define glGenQueriesARB MANGLE(GenQueriesARB) @@ -501,7 +508,11 @@ #define glGetActiveAttribARB MANGLE(GetActiveAttribARB) #define glGetActiveAttrib MANGLE(GetActiveAttrib) #define glGetActiveUniformARB MANGLE(GetActiveUniformARB) +#define glGetActiveUniformBlockiv MANGLE(GetActiveUniformBlockiv) +#define glGetActiveUniformBlockName MANGLE(GetActiveUniformBlockName) #define glGetActiveUniform MANGLE(GetActiveUniform) +#define glGetActiveUniformName MANGLE(GetActiveUniformName) +#define glGetActiveUniformsiv MANGLE(GetActiveUniformsiv) #define glGetActiveVaryingNV MANGLE(GetActiveVaryingNV) #define glGetArrayObjectfvATI MANGLE(GetArrayObjectfvATI) #define glGetArrayObjectivATI MANGLE(GetArrayObjectivATI) @@ -634,6 +645,12 @@ #defi
[Mesa3d-dev] OS X: _glCopyBufferSubData undefined on master
Compilation is broken on OS X 10.5.7 using master's HEAD [1]:
gcc -c -I../../../../include -I../../../../src/mesa -I../../../../src/mesa/main
-g -DUSE_MGL_NAMESPACE -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fno-strict-aliasing -fno-commonosmesa.c -o osmesa.o
/bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \
-major 7 -minor 6 -patch 0 \
-install ../../../../lib \
-id /Users/tfogal/sw/mesa-git/lib/libOSMesa.7.dylib \
-L../../../../lib -lm -lpthread osmesa.o
../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a
mklib: Making Darwin shared library: libOSMesa.7.6.dylib
Undefined symbols:
"_glCopyBufferSubData", referenced from:
_static_functions in libglapi.a(glapi_getproc.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
with the configuration:
./configure \
CFLAGS="-g -DUSE_MGL_NAMESPACE" \
CXXFLAGS="-g -DUSE_MGL_NAMESPACE" \
--prefix=${PF}\
--without-demos \
--with-driver=osmesa \
--disable-gallium \
--disable-egl || exit 1
make clean
sed -i bak "s,GL_LIB = GL,GL_LIB=MesaGL,g" configs/autoconf || exit 1
sed -i bak "s,GLU_LIB = GLU,GLU_LIB=MesaGLU,g" configs/autoconf || exit 1
The same configuration works fine on mesa_7_5_branch [2].
-tom
[1] 41091087396f935d4acf70b018ba54889fcf55a1
[2] fb64365642be82ac0dc0d43452afc4650d309b53
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-users] How do I copy a buffer from win32 window
vinit bansal writes: > I'm a novice to openGL. My objective is to create a win32 Window, > render some image onto it and want to copy it's framebuffer. [snip] > But i want to capture the framebuffer of that win32 window so that i > can copy it to another buffer. Wgl doesnot provide any api like EGL > does i.e. EglCopyBuffers(). You can do this in straight gl. See `glReadPixels'. Might want to look at framebuffer objects / renderbuffers if this is a common use case for you. -tom -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] problem loading unichrome_dri.so (dlopen of /usr/lib/dri/unichrome_dri.so failed ((null)))
Stephan Raue writes:
> sorry, Mesa 7.5-rc2 :-) The beer was good
>
> i have crosscompiled Mesa-5.1-rc2 ofor a uClibc based system (gcc-4.4)
> with unichrome driver.
>
> when unichrome driver loaded i see follow message in /var/log/Xorg.log
> (full version attached)
>
> (EE) AIGLX error: dlopen of /usr/lib/dri/unichrome_dri.so failed ((null))
I don't have any specific advice, but I'll offer some general guidance.
> (EE) AIGLX: reverting to software rendering
> (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed ((null))
> (EE) GLX: could not load software renderer
> (II) GLX: no usable GL providers found for screen 0
>
> Mesa is build with
>
> HOST_CC=$HOST_CC \
> OPT_FLAGS="$CFLAGS -D_GNU_SOURCE" \
> HOST_OPT_FLAGS="$HOST_CFLAGS" \
> X11_INCLUDES= \
> DRI_DRIVER_INSTALL_DIR="$XORG_PATH_DRI" \
> DRI_DRIVER_SEARCH_DIR="$XORG_PATH_DRI" \
> ./configure --host=$TARGET_NAME \
In general, autoconf variables should come after "./configure" but before any
"--options", e.g.:
./configure HOST_CC=... DRI_DRIVER_SEARCHDIR=... --host=...
[snip -- a ton of options]
> --with-driver=dri \
> --with-dri-drivers=$DRIDRIVERS \
DRIDRIVERS was not set in the above script / command line.
> --with-dri-driverdir="$XORG_PATH_DRI" \
> --with-xorg-driver-dir="$XORG_PATH_DRIVERS" \
> --with-x \
> --without-demos
>
> how i can find out what is wrong?
Try something simpler first. Configure with:
./configure --prefix=${HOME}/sw
and then grep ${HOME}/sw to see if it builds the right things (e.g.
unichrome_dri.so). Then add flags one by one until you get the build
you're looking for.
If you're really bent on getting that particular configuration to work,
start throwing echo's into configure.ac with the goal of figuring out
why the build isn't descending into `src/mesa/drivers/dri/unichrome'.
IIRC, there's a variable that gets set to the list of subdirs to
recurse into, so that's probably a good starting point.
HTH,
-tom
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.5 branch plan
Brian Paul writes: > Brian Paul wrote: > > > > I'm planning on creating a "mesa_7_5_branch" branch in git soon. > > Thereafter, this branch should only receive bug fixes, not new development. > > > > I'll probably create the first 7.5 release candidate from the new branch > > early next week (or possibly sooner). > > OK, the new branch has been made. > > Again, mesa_7_5_branch is for bug fixes only. Could you apply: [PATCH] Fix symbol list for mangled Mesa on Darwin. posted on Apr. 28th? I didn't see any complaints here or receive any privately. Thanks, -tom -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Only export one set of glu symbol names: mangled or unmangled
Alan Coopersmith writes:
> Solaris linker throws error if a mapfile references an undefined
> symbol, such as is found when building glu with both mangled and
> unmangled names in exports table but only one set of symbol names
> defined in objects.
>
> Signed-off-by: Alan Coopersmith
> ---
> src/glu/sgi/Makefile |7 ++-
> src/glu/sgi/glu.exports| 118 --
> --
> src/glu/sgi/glu.exports.in | 63 +++
> 3 files changed, 69 insertions(+), 119 deletions(-)
> delete mode 100644 src/glu/sgi/glu.exports
> create mode 100644 src/glu/sgi/glu.exports.in
NAK, breaks Linux sw-only mangled mesa build.
My command line to create the exports file ends up being:
gcc -E -I ../../../include/GL -g -DUSE_MGL_NAMESPACE -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC
-DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
-DUSE_XSHM glu.exports.in | \
awk '/^[^#]+/ {print}' > glu.exports
which complains:
gcc: glu.exports.in: linker input file unused because linking not done
If I manually invoke:
cpp -E glu.exports.in | awk '/^[^#]+/ {print}' > glu.exports
it does the right thing, and the build works thereafter.
FYI, compiler:
t...@shigeru mesa gcc -v 2>&1 | grep "gcc version"
gcc version 4.3.2 (Debian 4.3.2-1.1)
I like the approach though. Might be a good idea to do something like
this for Darwin as well, so we could unify the way the export table is
built.
-tom
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tiny fix for Mesa-Win32
Sukender writes: [snip] > 2. Hardware/Software mixed OpenGL (= Hardware when supported, Software when n > ot)? I'm `currently' implementing this based on GLEW. That is, I'm making GLEW dynamically load a particular OpenGL implementation based on what the user wants. When I detect available HW, I tell GLEW to load the `system' GL; if not, I tell it to load mangled Mesa. This isn't quite complete, and won't work on Windows currently. I'd love to have someone who would use/help get it working/test it on Windows though. Please contact me off list if you are interested. Cheers, -tom -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Remove `egl' from SRC_DIRS.
Dan Nicholson writes: > On Wed, Apr 29, 2009 at 9:31 AM, tom fogal wrote: > > Dan Nicholson writes: > >> On Tue, Apr 28, 2009 at 10:57 PM, tom fogal wrote: > >> > Dan Nicholson writes: > >> >> On Tue, Apr 28, 2009 at 9:02 PM, tom fogal > >> >> wrote: > >> >> > Tom Fogal writes: > >> >> > Please note that I haven't actually verified the claim that > >> >> > `egl' wil l still be recursed into for those that do actually > >> >> > use --enable-gallium > >> > [snip] > >> >> Gallium's EGL state tracker requires libEGL, and the only > >> >> way it get's built is if egl is in SRC_DIRS. So, this will > >> >> break the typical build. What I've been meaning to add is a > >> >> --disable-egl switch which defaults to yes only for platforms > >> >> that can support it. > >> > > >> > Okay. Â Can I rely on you to add such a flag for the next major > >> > release? > >> > >> I'll do it in the next couple days and ping you to see if it does > >> the right thing for OSX. > > Can you try out 66f978625685d83b04c32b19b62c3cb8c0d25f74 when you get > a chance? For now, you'll have to pass --disable-egl, but maybe later > we an make the default smarter. Signed-off-by: Tom Fogal Tested: x86_64/linux/autoconf 2.61 OS X/autoconf 2.63 Works as desired on both systems. Thanks! -tom -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Use variable library name in pkg-config output.
Dan Nicholson writes: > On Wed, Apr 29, 2009 at 9:32 AM, Tom Fogal wrote: > > Previously the pkg-config output files would contain e.g. `-lGL' > > and `-lGLU', even if the user modified their configuration to > > build libraries with different names. Â This modifies the > > pkg-config inputs, and corresponding makery, so that modifying the > > output library name will cause the appropriate updated name to > > appear in the pkg-config `-l' option. > > Looks good. Do you have commit privs, or do you want me to push it? I do not, please push. -tom -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Use variable library name in pkg-config output.
Previously the pkg-config output files would contain e.g. `-lGL'
and `-lGLU', even if the user modified their configuration to
build libraries with different names. This modifies the
pkg-config inputs, and corresponding makery, so that modifying the
output library name will cause the appropriate updated name to
appear in the pkg-config `-l' option.
---
src/glu/Makefile |3 ++-
src/glu/glu.pc.in|2 +-
src/glut/glx/Makefile|3 ++-
src/glut/glx/glut.pc.in |2 +-
src/glut/mini/Makefile |3 ++-
src/glut/mini/glut.pc.in |2 +-
src/glw/Makefile |3 ++-
src/glw/glw.pc.in|2 +-
src/mesa/Makefile|3 ++-
src/mesa/gl.pc.in|2 +-
10 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/src/glu/Makefile b/src/glu/Makefile
index e519dfe..5c26ead 100644
--- a/src/glu/Makefile
+++ b/src/glu/Makefile
@@ -22,7 +22,8 @@ pcedit = sed \
-e 's,@GLU_PC_REQ@,$(GLU_PC_REQ),' \
-e 's,@GLU_PC_REQ_PRIV@,$(GLU_PC_REQ_PRIV),' \
-e 's,@GLU_PC_LIB_PRIV@,$(GLU_PC_LIB_PRIV),' \
- -e 's,@GLU_PC_CFLAGS@,$(GLU_PC_CFLAGS),'
+ -e 's,@GLU_PC_CFLAGS@,$(GLU_PC_CFLAGS),' \
+ -e 's,@GLU_LIB@,$(GLU_LIB),'
glu.pc: glu.pc.in
$(pcedit) $< > $@
diff --git a/src/glu/glu.pc.in b/src/glu/glu.pc.in
index bc2517e..f7d9109 100644
--- a/src/glu/glu.pc.in
+++ b/src/glu/glu.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL Utility library
Requires: @GLU_PC_REQ@
Requires.private: @GLU_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lGLU
+Libs: -L${libdir} -...@glu_lib@
Libs.private: @GLU_PC_LIB_PRIV@
Cflags: -I${includedir} @GLU_PC_CFLAGS@
diff --git a/src/glut/glx/Makefile b/src/glut/glx/Makefile
index 9a975bb..1b07290 100644
--- a/src/glut/glx/Makefile
+++ b/src/glut/glx/Makefile
@@ -107,7 +107,8 @@ pcedit = sed \
-e 's,@VERSION@,$(GLUT_MAJOR).$(GLUT_MINOR).$(GLUT_TINY),' \
-e 's,@GLUT_PC_REQ_PRIV@,$(GLUT_PC_REQ_PRIV),' \
-e 's,@GLUT_PC_LIB_PRIV@,$(GLUT_PC_LIB_PRIV),' \
- -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),'
+ -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),' \
+ -e 's,@GLUT_LIB@,$(GLUT_LIB),'
glut.pc: glut.pc.in
$(pcedit) $< > $@
diff --git a/src/glut/glx/glut.pc.in b/src/glut/glx/glut.pc.in
index ae0689d..151dd0b 100644
--- a/src/glut/glx/glut.pc.in
+++ b/src/glut/glx/glut.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL Utility Toolkit library
Requires: gl glu
Requires.private: @GLUT_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lglut
+Libs: -L${libdir} -...@glut_lib@
Libs.private: @GLUT_PC_LIB_PRIV@
Cflags: -I${includedir} @GLUT_PC_CFLAGS@
diff --git a/src/glut/mini/Makefile b/src/glut/mini/Makefile
index 841a473..0e42436 100644
--- a/src/glut/mini/Makefile
+++ b/src/glut/mini/Makefile
@@ -81,7 +81,8 @@ pcedit = sed \
-e 's,@VERSION@,$(GLUT_MAJOR).$(GLUT_MINOR).$(GLUT_TINY),' \
-e 's,@GLUT_PC_REQ_PRIV@,$(GLUT_PC_REQ_PRIV),' \
-e 's,@GLUT_PC_LIB_PRIV@,$(GLUT_PC_LIB_PRIV),' \
- -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),'
+ -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),' \
+ -e 's,@GLUT_LIB@,$(GLUT_LIB),'
glut.pc: glut.pc.in
$(pcedit) $< > $@
diff --git a/src/glut/mini/glut.pc.in b/src/glut/mini/glut.pc.in
index ae0689d..151dd0b 100644
--- a/src/glut/mini/glut.pc.in
+++ b/src/glut/mini/glut.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL Utility Toolkit library
Requires: gl glu
Requires.private: @GLUT_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lglut
+Libs: -L${libdir} -...@glut_lib@
Libs.private: @GLUT_PC_LIB_PRIV@
Cflags: -I${includedir} @GLUT_PC_CFLAGS@
diff --git a/src/glw/Makefile b/src/glw/Makefile
index b153a6d..d88d773 100644
--- a/src/glw/Makefile
+++ b/src/glw/Makefile
@@ -33,7 +33,8 @@ pcedit = sed \
-e 's,@VERSION@,$(MAJOR).$(MINOR).$(TINY),' \
-e 's,@GLW_PC_REQ_PRIV@,$(GLW_PC_REQ_PRIV),' \
-e 's,@GLW_PC_LIB_PRIV@,$(GLW_PC_LIB_PRIV),' \
- -e 's,@GLW_PC_CFLAGS@,$(GLW_PC_CFLAGS),'
+ -e 's,@GLW_PC_CFLAGS@,$(GLW_PC_CFLAGS),' \
+ -e 's,@GLW_LIB@,$(GLW_LIB),'
glw.pc: glw.pc.in
$(pcedit) $< > $@
diff --git a/src/glw/glw.pc.in b/src/glw/glw.pc.in
index 5493093..19a7c30 100644
--- a/src/glw/glw.pc.in
+++ b/src/glw/glw.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL widget library
Requires: gl
Requires.private: @GLW_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lGLw
+Libs: -L${libdir} -...@glw_lib@
Libs.private: @GLW_PC_LIB_PRIV@
Cflags: -I${includedir} @GLW_PC_CFLAGS@
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index 4ff28da..bb18bee 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -103,7 +103,8 @@ gl_pcedit = sed \
-e 's,@VERSION@,$(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY),' \
-e 's,@GL_PC_REQ_PRIV@,$(GL_PC_REQ_PRIV),' \
-e 's,@GL_PC_LIB_PRIV@,$(GL_PC_LIB_PRIV),' \
- -e 's,@GL_PC_CFLAGS@,$(GL_PC_CFLAGS),'
+ -e 's,@GL_PC_CFLAGS@,$(GL_PC_CFLAGS),' \
+ -e 's,@GL_LI
Re: [Mesa3d-dev] [PATCH] Use variable library name in pkg-config output.
Dan Nicholson writes:
> On Tue, Apr 28, 2009 at 8:56 PM, Tom Fogal wrote:
> > This modifies the pkg-config inputs, and corresponding makery, so
> > that modifying the output library name will cause the appropriate
> > updated name to appear in the pkg-config `-l' option.
>
> Yeah, this is the right thing to do, but I'd appreciate it if you
> would extend it to all the existing .pc files.
Okay. Updated patch is attached.
> There's also GLUT_LIB, GLW_LIB and OSMESA_LIB.
I found that these were already correct, sans the corrections in the
updated patch. For example, OSMesa's pc is correct without patching.
If you notice discrepancies in that, of course, please let me know.
> At some point there should be a egl.pc, too, but I don't think
> anyone's done that yet.
I'll leave that for you / others ...
-tom
From 2206d9219667d1fc5443b9f933b73e6b25f3a11f Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Wed, 14 Jan 2009 23:06:05 -0700
Subject: [PATCH] Use variable library name in pkg-config output.
Previously the pkg-config output files would contain e.g. `-lGL'
and `-lGLU', even if the user modified their configuration to
build libraries with different names. This modifies the
pkg-config inputs, and corresponding makery, so that modifying the
output library name will cause the appropriate updated name to
appear in the pkg-config `-l' option.
---
src/glu/Makefile |3 ++-
src/glu/glu.pc.in|2 +-
src/glut/glx/Makefile|3 ++-
src/glut/glx/glut.pc.in |2 +-
src/glut/mini/Makefile |3 ++-
src/glut/mini/glut.pc.in |2 +-
src/glw/Makefile |3 ++-
src/glw/glw.pc.in|2 +-
src/mesa/Makefile|3 ++-
src/mesa/gl.pc.in|2 +-
10 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/src/glu/Makefile b/src/glu/Makefile
index e519dfe..5c26ead 100644
--- a/src/glu/Makefile
+++ b/src/glu/Makefile
@@ -22,7 +22,8 @@ pcedit = sed \
-e 's,@GLU_PC_REQ@,$(GLU_PC_REQ),' \
-e 's,@GLU_PC_REQ_PRIV@,$(GLU_PC_REQ_PRIV),' \
-e 's,@GLU_PC_LIB_PRIV@,$(GLU_PC_LIB_PRIV),' \
- -e 's,@GLU_PC_CFLAGS@,$(GLU_PC_CFLAGS),'
+ -e 's,@GLU_PC_CFLAGS@,$(GLU_PC_CFLAGS),' \
+ -e 's,@GLU_LIB@,$(GLU_LIB),'
glu.pc: glu.pc.in
$(pcedit) $< > $@
diff --git a/src/glu/glu.pc.in b/src/glu/glu.pc.in
index bc2517e..f7d9109 100644
--- a/src/glu/glu.pc.in
+++ b/src/glu/glu.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL Utility library
Requires: @GLU_PC_REQ@
Requires.private: @GLU_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lGLU
+Libs: -L${libdir} -...@glu_lib@
Libs.private: @GLU_PC_LIB_PRIV@
Cflags: -I${includedir} @GLU_PC_CFLAGS@
diff --git a/src/glut/glx/Makefile b/src/glut/glx/Makefile
index 9a975bb..1b07290 100644
--- a/src/glut/glx/Makefile
+++ b/src/glut/glx/Makefile
@@ -107,7 +107,8 @@ pcedit = sed \
-e 's,@VERSION@,$(GLUT_MAJOR).$(GLUT_MINOR).$(GLUT_TINY),' \
-e 's,@GLUT_PC_REQ_PRIV@,$(GLUT_PC_REQ_PRIV),' \
-e 's,@GLUT_PC_LIB_PRIV@,$(GLUT_PC_LIB_PRIV),' \
- -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),'
+ -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),' \
+ -e 's,@GLUT_LIB@,$(GLUT_LIB),'
glut.pc: glut.pc.in
$(pcedit) $< > $@
diff --git a/src/glut/glx/glut.pc.in b/src/glut/glx/glut.pc.in
index ae0689d..151dd0b 100644
--- a/src/glut/glx/glut.pc.in
+++ b/src/glut/glx/glut.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL Utility Toolkit library
Requires: gl glu
Requires.private: @GLUT_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lglut
+Libs: -L${libdir} -...@glut_lib@
Libs.private: @GLUT_PC_LIB_PRIV@
Cflags: -I${includedir} @GLUT_PC_CFLAGS@
diff --git a/src/glut/mini/Makefile b/src/glut/mini/Makefile
index 841a473..0e42436 100644
--- a/src/glut/mini/Makefile
+++ b/src/glut/mini/Makefile
@@ -81,7 +81,8 @@ pcedit = sed \
-e 's,@VERSION@,$(GLUT_MAJOR).$(GLUT_MINOR).$(GLUT_TINY),' \
-e 's,@GLUT_PC_REQ_PRIV@,$(GLUT_PC_REQ_PRIV),' \
-e 's,@GLUT_PC_LIB_PRIV@,$(GLUT_PC_LIB_PRIV),' \
- -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),'
+ -e 's,@GLUT_PC_CFLAGS@,$(GLUT_PC_CFLAGS),' \
+ -e 's,@GLUT_LIB@,$(GLUT_LIB),'
glut.pc: glut.pc.in
$(pcedit) $< > $@
diff --git a/src/glut/mini/glut.pc.in b/src/glut/mini/glut.pc.in
index ae0689d..151dd0b 100644
--- a/src/glut/mini/glut.pc.in
+++ b/src/glut/mini/glut.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL Utility Toolkit library
Requires: gl glu
Requires.private: @GLUT_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lglut
+Libs: -L${libdir} -...@glut_lib@
Libs.private: @GLUT_PC_LIB_PRIV@
Cflags: -I${includedir} @GLUT_PC_CFLAGS@
diff --git a/src/glw/Makefile b/src/glw/Makefile
index b153a6d..d88d773 100644
--- a/src/glw/Makefile
+++ b/src/glw/Makefile
@@ -33,7 +33,8 @@ pcedit = sed \
-e &#
Re: [Mesa3d-dev] [PATCH] Remove `egl' from SRC_DIRS.
Dan Nicholson writes: > On Tue, Apr 28, 2009 at 9:02 PM, tom fogal wrote: > > Tom Fogal writes: > >> This removes `egl' from the variable SRC_DIRS, preventing Mesa > >> from automatically recursing/building that state tracker. Â It > >> appears as if `egl' is not necessary in SRC_DIRS: there is > >> appropriate autoconfery to ensure it ends up in > >> GALLIUM_STATE_TRACKERS_DIRS [snip] > > Please note that I haven't actually verified the claim that `egl' will > > still be recursed into for those that do actually use --enable-gallium [snip] > Gallium's EGL state tracker requires libEGL, and the only way it get's > built is if egl is in SRC_DIRS. So, this will break the typical build. > What I've been meaning to add is a --disable-egl switch which defaults > to yes only for platforms that can support it. Then if libEGL is not > being built, the EGL statetracker won't either. Haven't gotten around > to it, though. Okay. Can I rely on you to add such a flag for the next major release? It doesn't really matter (to me) if any sort of autodetection works, as long as there's an override switch. -tom -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Fix symbol list for mangled Mesa on Darwin.
Tom Fogal writes: > When building mangled Mesa on Darwin, the exported symbols ... [snip] ack, sorry for the spam.. must be too late here. While I'm here though, I might as well note that this patch is basically a followup to 4469355df277bec4947d859def543a3903c99041; I hadn't realized there were separate files for different platforms, initially. -tom -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Fix symbol list for mangled Mesa on Darwin.
When building mangled Mesa on Darwin, the exported symbols are named `_mgluWhatever' instead of simply `_gluWhatever'. When using a list of exported symbols via the system ld's `-exported_symbols_list' command line option (as done by mklib), this resulted in error messages about exporting symbols which do not exist. Fortunately the file format accepts simple wildcards. This throws a wildcard so that the symbol list will match both the mangled and non-mangled names, preventing the warning and actually exporting the correct symbols in one shot. --- src/glu/sgi/glu.exports.darwin | 118 1 files changed, 59 insertions(+), 59 deletions(-) diff --git a/src/glu/sgi/glu.exports.darwin b/src/glu/sgi/glu.exports.darwin index 62d20ae..4f56e36 100644 --- a/src/glu/sgi/glu.exports.darwin +++ b/src/glu/sgi/glu.exports.darwin @@ -1,59 +1,59 @@ -_gluBeginCurve -_gluBeginPolygon -_gluBeginSurface -_gluBeginTrim -_gluBuild1DMipmapLevels -_gluBuild1DMipmaps -_gluBuild2DMipmapLevels -_gluBuild2DMipmaps -_gluBuild3DMipmapLevels -_gluBuild3DMipmaps -_gluCheckExtension -_gluCylinder -_gluDeleteNurbsRenderer -_gluDeleteQuadric -_gluDeleteTess -_gluDisk -_gluEndCurve -_gluEndPolygon -_gluEndSurface -_gluEndTrim -_gluErrorString -_gluGetNurbsProperty -_gluGetString -_gluGetTessProperty -_gluLoadSamplingMatrices -_gluLookAt -_gluNewNurbsRenderer -_gluNewQuadric -_gluNewTess -_gluNextContour -_gluNurbsCallback -_gluNurbsCallbackData -_gluNurbsCallbackDataEXT -_gluNurbsCurve -_gluNurbsProperty -_gluNurbsSurface -_gluOrtho2D -_gluPartialDisk -_gluPerspective -_gluPickMatrix -_gluProject -_gluPwlCurve -_gluQuadricCallback -_gluQuadricDrawStyle -_gluQuadricNormals -_gluQuadricOrientation -_gluQuadricTexture -_gluScaleImage -_gluSphere -_gluTessBeginContour -_gluTessBeginPolygon -_gluTessCallback -_gluTessEndContour -_gluTessEndPolygon -_gluTessNormal -_gluTessProperty -_gluTessVertex -_gluUnProject -_gluUnProject4 +_*gluBeginCurve +_*gluBeginPolygon +_*gluBeginSurface +_*gluBeginTrim +_*gluBuild1DMipmapLevels +_*gluBuild1DMipmaps +_*gluBuild2DMipmapLevels +_*gluBuild2DMipmaps +_*gluBuild3DMipmapLevels +_*gluBuild3DMipmaps +_*gluCheckExtension +_*gluCylinder +_*gluDeleteNurbsRenderer +_*gluDeleteQuadric +_*gluDeleteTess +_*gluDisk +_*gluEndCurve +_*gluEndPolygon +_*gluEndSurface +_*gluEndTrim +_*gluErrorString +_*gluGetNurbsProperty +_*gluGetString +_*gluGetTessProperty +_*gluLoadSamplingMatrices +_*gluLookAt +_*gluNewNurbsRenderer +_*gluNewQuadric +_*gluNewTess +_*gluNextContour +_*gluNurbsCallback +_*gluNurbsCallbackData +_*gluNurbsCallbackDataEXT +_*gluNurbsCurve +_*gluNurbsProperty +_*gluNurbsSurface +_*gluOrtho2D +_*gluPartialDisk +_*gluPerspective +_*gluPickMatrix +_*gluProject +_*gluPwlCurve +_*gluQuadricCallback +_*gluQuadricDrawStyle +_*gluQuadricNormals +_*gluQuadricOrientation +_*gluQuadricTexture +_*gluScaleImage +_*gluSphere +_*gluTessBeginContour +_*gluTessBeginPolygon +_*gluTessCallback +_*gluTessEndContour +_*gluTessEndPolygon +_*gluTessNormal +_*gluTessProperty +_*gluTessVertex +_*gluUnProject +_*gluUnProject4 -- 1.5.6.5 -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Remove `egl' from SRC_DIRS.
Tom Fogal writes: > This removes `egl' from the variable SRC_DIRS, preventing Mesa > from automatically recursing/building that state tracker. It > appears as if `egl' is not necessary in SRC_DIRS: there is > appropriate autoconfery to ensure it ends up in > GALLIUM_STATE_TRACKERS_DIRS, which is (correctly) only recursed > when Gallium is being built. The logic behind this path is that EGL isn't currently building on OS X. Looks like eglplatform.h requires some platform-specific defs to define how the library binds to a windowing system. Use the existing case for Linux/sun/something-else-I-forget would probably work as it uses X11, but on Mac it's not obvious one always wants to go through X11. Anyway, we don't need it, so disabling it was the simplest thing for me to do at the moment, but I'm not sure if EGL is supposed to work on OS X. Please note that I haven't actually verified the claim that `egl' will still be recursed into for those that do actually use --enable-gallium (the default). Further review/testing that it doesn't break anyone's Gallium w/ EGL would be greatly appreciated. Thanks, -tom -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Fix symbol list for mangled Mesa on Darwin.
When building mangled Mesa on Darwin, the exported symbols are named `_mgluWhatever' instead of simply `_gluWhatever'. When using a list of exported symbols via the system ld's `-exported_symbols_list' command line option (as done by mklib), this resulted in error messages about exporting symbols which do not exist. Fortunately the file format accepts simple wildcards. This throws a wildcard so that the symbol list will match both the mangled and non-mangled names, preventing the warning and actually exporting the correct symbols in one shot. --- src/glu/sgi/glu.exports.darwin | 118 1 files changed, 59 insertions(+), 59 deletions(-) diff --git a/src/glu/sgi/glu.exports.darwin b/src/glu/sgi/glu.exports.darwin index 62d20ae..4f56e36 100644 --- a/src/glu/sgi/glu.exports.darwin +++ b/src/glu/sgi/glu.exports.darwin @@ -1,59 +1,59 @@ -_gluBeginCurve -_gluBeginPolygon -_gluBeginSurface -_gluBeginTrim -_gluBuild1DMipmapLevels -_gluBuild1DMipmaps -_gluBuild2DMipmapLevels -_gluBuild2DMipmaps -_gluBuild3DMipmapLevels -_gluBuild3DMipmaps -_gluCheckExtension -_gluCylinder -_gluDeleteNurbsRenderer -_gluDeleteQuadric -_gluDeleteTess -_gluDisk -_gluEndCurve -_gluEndPolygon -_gluEndSurface -_gluEndTrim -_gluErrorString -_gluGetNurbsProperty -_gluGetString -_gluGetTessProperty -_gluLoadSamplingMatrices -_gluLookAt -_gluNewNurbsRenderer -_gluNewQuadric -_gluNewTess -_gluNextContour -_gluNurbsCallback -_gluNurbsCallbackData -_gluNurbsCallbackDataEXT -_gluNurbsCurve -_gluNurbsProperty -_gluNurbsSurface -_gluOrtho2D -_gluPartialDisk -_gluPerspective -_gluPickMatrix -_gluProject -_gluPwlCurve -_gluQuadricCallback -_gluQuadricDrawStyle -_gluQuadricNormals -_gluQuadricOrientation -_gluQuadricTexture -_gluScaleImage -_gluSphere -_gluTessBeginContour -_gluTessBeginPolygon -_gluTessCallback -_gluTessEndContour -_gluTessEndPolygon -_gluTessNormal -_gluTessProperty -_gluTessVertex -_gluUnProject -_gluUnProject4 +_*gluBeginCurve +_*gluBeginPolygon +_*gluBeginSurface +_*gluBeginTrim +_*gluBuild1DMipmapLevels +_*gluBuild1DMipmaps +_*gluBuild2DMipmapLevels +_*gluBuild2DMipmaps +_*gluBuild3DMipmapLevels +_*gluBuild3DMipmaps +_*gluCheckExtension +_*gluCylinder +_*gluDeleteNurbsRenderer +_*gluDeleteQuadric +_*gluDeleteTess +_*gluDisk +_*gluEndCurve +_*gluEndPolygon +_*gluEndSurface +_*gluEndTrim +_*gluErrorString +_*gluGetNurbsProperty +_*gluGetString +_*gluGetTessProperty +_*gluLoadSamplingMatrices +_*gluLookAt +_*gluNewNurbsRenderer +_*gluNewQuadric +_*gluNewTess +_*gluNextContour +_*gluNurbsCallback +_*gluNurbsCallbackData +_*gluNurbsCallbackDataEXT +_*gluNurbsCurve +_*gluNurbsProperty +_*gluNurbsSurface +_*gluOrtho2D +_*gluPartialDisk +_*gluPerspective +_*gluPickMatrix +_*gluProject +_*gluPwlCurve +_*gluQuadricCallback +_*gluQuadricDrawStyle +_*gluQuadricNormals +_*gluQuadricOrientation +_*gluQuadricTexture +_*gluScaleImage +_*gluSphere +_*gluTessBeginContour +_*gluTessBeginPolygon +_*gluTessCallback +_*gluTessEndContour +_*gluTessEndPolygon +_*gluTessNormal +_*gluTessProperty +_*gluTessVertex +_*gluUnProject +_*gluUnProject4 -- 1.5.6.5 -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Remove `egl' from SRC_DIRS.
This removes `egl' from the variable SRC_DIRS, preventing Mesa from automatically recursing/building that state tracker. It appears as if `egl' is not necessary in SRC_DIRS: there is appropriate autoconfery to ensure it ends up in GALLIUM_STATE_TRACKERS_DIRS, which is (correctly) only recursed when Gallium is being built. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 7b07f0f..9461699 100644 --- a/configure.ac +++ b/configure.ac @@ -411,7 +411,7 @@ esac dnl dnl Driver specific build directories dnl -SRC_DIRS="mesa egl glew" +SRC_DIRS="mesa glew" GLU_DIRS="sgi" WINDOW_SYSTEM="" GALLIUM_DIRS="auxiliary drivers state_trackers" -- 1.5.6.5 -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Use variable library name in pkg-config output.
Previously the pkg-config output files would contain `-lGL' and
`-lGLU', even if the user modified their configuration to build
libraries with different names. This modifies the pkg-config
inputs, and corresponding makery, so that modifying the output
library name will cause the appropriate updated name to appear in
the pkg-config `-l' option.
---
src/glu/Makefile |3 ++-
src/glu/glu.pc.in |2 +-
src/mesa/Makefile |3 ++-
src/mesa/gl.pc.in |2 +-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/glu/Makefile b/src/glu/Makefile
index e519dfe..5c26ead 100644
--- a/src/glu/Makefile
+++ b/src/glu/Makefile
@@ -22,7 +22,8 @@ pcedit = sed \
-e 's,@GLU_PC_REQ@,$(GLU_PC_REQ),' \
-e 's,@GLU_PC_REQ_PRIV@,$(GLU_PC_REQ_PRIV),' \
-e 's,@GLU_PC_LIB_PRIV@,$(GLU_PC_LIB_PRIV),' \
- -e 's,@GLU_PC_CFLAGS@,$(GLU_PC_CFLAGS),'
+ -e 's,@GLU_PC_CFLAGS@,$(GLU_PC_CFLAGS),' \
+ -e 's,@GLU_LIB@,$(GLU_LIB),'
glu.pc: glu.pc.in
$(pcedit) $< > $@
diff --git a/src/glu/glu.pc.in b/src/glu/glu.pc.in
index bc2517e..f7d9109 100644
--- a/src/glu/glu.pc.in
+++ b/src/glu/glu.pc.in
@@ -8,6 +8,6 @@ Description: Mesa OpenGL Utility library
Requires: @GLU_PC_REQ@
Requires.private: @GLU_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lGLU
+Libs: -L${libdir} -...@glu_lib@
Libs.private: @GLU_PC_LIB_PRIV@
Cflags: -I${includedir} @GLU_PC_CFLAGS@
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index 4ff28da..bb18bee 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -103,7 +103,8 @@ gl_pcedit = sed \
-e 's,@VERSION@,$(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY),' \
-e 's,@GL_PC_REQ_PRIV@,$(GL_PC_REQ_PRIV),' \
-e 's,@GL_PC_LIB_PRIV@,$(GL_PC_LIB_PRIV),' \
- -e 's,@GL_PC_CFLAGS@,$(GL_PC_CFLAGS),'
+ -e 's,@GL_PC_CFLAGS@,$(GL_PC_CFLAGS),' \
+ -e 's,@GL_LIB@,$(GL_LIB),'
gl.pc: gl.pc.in
$(gl_pcedit) $< > $@
diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
index 0462b9f..97b8659 100644
--- a/src/mesa/gl.pc.in
+++ b/src/mesa/gl.pc.in
@@ -7,6 +7,6 @@ Name: gl
Description: Mesa OpenGL library
Requires.private: @GL_PC_REQ_PRIV@
Version: @VERSION@
-Libs: -L${libdir} -lGL
+Libs: -L${libdir} -...@gl_lib@
Libs.private: @GL_PC_LIB_PRIV@
Cflags: -I${includedir} @GL_PC_CFLAGS@
--
1.5.6.5
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
