Re: [Mesa3d-dev] [PATCH] Only export one set of glu symbol names: mangled or unmangled
Mandalemula, Rajesh rajesh.mandalem...@deshaw.com 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 ATT 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 jerem...@freedesktop.org writes: On Apr 3, 2010, at 12:34, tom fogal wrote: Vinson Lee v...@vmware.com 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#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list 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 jerem...@freedesktop.org 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#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list 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 bri...@vmware.com 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 tfo...@alumni.unh.edu 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#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list 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 tfo...@alumni.unh.edu
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#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
Tom Stellard tstel...@gmail.com 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#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list 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#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
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 chantry.xav...@gmail.com 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#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list 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 chantry.xav...@gmail.com writes: On Mon, Mar 15, 2010 at 12:41 AM, tom fogal tfo...@alumni.unh.edu 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#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list 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 tfo...@alumni.unh.edu
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 aj...@aber.ac.uk
+#
+# 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 stdlib.h
+ 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 tfo...@alumni.unh.edu
Date: Fri, 13 Nov 2009 21:25:45 -0700
Subject: [PATCH 2/2] autoconf: Detect platform support for glX TLS.
Check for thread local
Re: [Mesa3d-dev] code generation for dynamic extensions broken ?
George Sapountzis gsapount...@gmail.com writes: On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick i...@freedesktop.org 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#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] OS ABI Tag.
Pat Suwalski p...@suwalski.net 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
[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 tfo...@alumni.unh.edu 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] [PATCH] Fix a typo in mesa3d.org HTML
From 99fbfe43dad3efae04749ab9da164c0e849bd836 Mon Sep 17 00:00:00 2001 From: Tom Fogal tfo...@alumni.unh.edu 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 @@ HTML -TITLECocd Repository/TITLE +TITLECode Repository/TITLE link rel=stylesheet type=text/css href=mesa.css/head -- 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
Re: [Mesa3d-dev] [PATCH] Honor LD_LIBRARY_PATH getting EGL drivers
Mike Stroyan m...@lunarg.com 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
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] 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] c99 again [was: Re: [PATCH] Fix compressed texture loads for non-minimal pitches]
Luca Barbieri l...@luca-barbieri.com 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
= \ + 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 tfo...@alumni.unh.edu 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 tfo...@alumni.unh.edu
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 CoreFoundation/CFByteOrder.h
#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 sys/endian.h
-#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 jfons...@vmware.com wrote: On Sun, 2010-01-03 at 08:45 -0800, Brian Paul wrote: 2010/1/2 Chia-I Wu olva...@gmail.com: 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 bri...@vmware.com 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 tfo...@alumni.unh.edu 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
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
Corbin Simpson mostawesomed...@gmail.com 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 X but implements it in software, though such a thing is desperately needed. It would be much easier for us if advertising X 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 kei...@vmware.com 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 e0425...@student.tuwien.ac.at 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 mostawesomed...@gmail.com - - 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
[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 string, line 27, in module 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 module from libstdcxx.v6.printers import register_libstdcxx_printers File /usr/lib/python2.6/site-packages/gdb/libstdcxx/v6/printers.py, line 19, in module 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*, QFlagsQt::WindowType) () 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*, QFlagsQt::WindowType) () 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
Re: [Mesa3d-dev] swrast: _ae_invalidate_state segfault executing a VBO
tom fogal tfo...@alumni.unh.edu 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
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
Dan Nicholson dbn.li...@gmail.com writes: On Tue, Nov 24, 2009 at 3:55 PM, tom fogal tfo...@alumni.unh.edu 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 dbn.li...@gmail.com 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 tfo...@alumni.unh.edu 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] 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] 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
Dan Nicholson dbn.li...@gmail.com writes: On Thu, Nov 19, 2009 at 8:28 AM, Brian Paul bri...@vmware.com wrote: tom fogal wrote: Brian Paul bri...@vmware.com 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] Mesa 7.6.1 release candidate 1
Dan Nicholson dbn.li...@gmail.com writes: On Tue, Nov 24, 2009 at 12:37 PM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Thu, Nov 19, 2009 at 8:28 AM, Brian Paul bri...@vmware.com wrote: tom fogal wrote: Brian Paul bri...@vmware.com 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 tfo...@alumni.unh.edu 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 \ + 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 -- 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
Re: [Mesa3d-dev] Mesa 7.6.1 release candidate 1
tom fogal tfo...@alumni.unh.edu writes: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Nov 24, 2009 at 12:37 PM, tom fogal tfo...@alumni.unh.edu wrot= e: Dan Nicholson dbn.li...@gmail.com writes: On Thu, Nov 19, 2009 at 8:28 AM, Brian Paul bri...@vmware.com wrote= : tom fogal wrote: Brian Paul bri...@vmware.com 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 tfo...@alumni.unh.edu 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
Brian Paul bri...@vmware.com writes: tom fogal wrote: Brian Paul bri...@vmware.com 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
[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] Mesa 7.6.1 release candidate 1
Brian Paul bri...@vmware.com 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 tfo...@alumni.unh.edu
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 CoreFoundation/CFByteOrder.h
#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 sys/endian.h
#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 tfo...@alumni.unh.edu
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
Re: [Mesa3d-dev] Error building MesaLib 7.6 onto Win32 with Microsoft Visual Studio 2005 and 2008
Delle dell...@gmail.com 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] glX TLS disabled by default?
Dan Nicholson dbn.li...@gmail.com writes: On Mon, Nov 9, 2009 at 9:52 AM, tom fogal tfo...@alumni.unh.edu wrote: Mark Kettenis mark.kette...@xs4all.nl writes: From: Adam Jackson a...@nwnk.net 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
[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 tfo...@alumni.unh.edu 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 i...@freedesktop.org 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
[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
[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
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 tfo...@alumni.unh.edu 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
Re: [Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
Brian Paul bri...@vmware.com 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 0/4] Speed up _glapi_add_dispatch.
Chia-I Wu olva...@gmail.com writes:
On Mon, Oct 05, 2009 at 11:16:17AM -0600, tom fogal wrote:
Chia-I Wu olva...@gmail.com 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 tfo...@alumni.unh.edu
FWIW.
-tom
--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
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] [PATCH] Regenerate gl_mangle.h.
Attached. -tom From 87ce26ad777157de905c33d24e4b24ba09dd9c90 Mon Sep 17 00:00:00 2001 From: Tom Fogal tfo...@alumni.unh.edu 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
Re: [Mesa3d-dev] [PATCH 0/4] Speed up _glapi_add_dispatch.
Chia-I Wu olva...@gmail.com 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(ExtEntryTable[j].name, function_names[i]) == 0) {
- /* The offset may be ~0 if the
Re: [Mesa3d-dev] Mesa 7.6 released
Ian Romanick i...@freedesktop.org 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 @@ H1News/H1 +h2September 28, 2009/h2 +p +a href=relnotes-7.6.htmlMesa 7.6/a 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. +/p +p +a href=relnotes-7.5.2.htmlMesa 7.5.2/a is released. This is a stable +release fixing bugs since the 7.5.1 release. +/p + h2September 3, 2009/h2 p -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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 i...@freedesktop.org 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 i...@freedesktop.org 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 bri...@vmware.com writes: tom fogal wrote: Brian Paul bri...@vmware.com writes: Dan Nicholson wrote: On Thu, Aug 13, 2009 at 7:10 PM, tom fogaltfo...@alumni.unh.edu wrote: Brian Paul bri...@vmware.com 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 bri...@vmware.com 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 tfo...@alumni.unh.edu
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 tfo...@alumni.unh.edu
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 tfo...@alumni.unh.edu
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.
/p
+h23.6 How can I change the maximum framebuffer size in Mesa's
+ttswrast/tt backend?/h2
+p
+These can be overridden by using the tt--with-max-width/tt and
+tt--with-max-height/tt options. The two need not be equal.
+/pp
+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 tt4096/tt
+may introduce rasterization artifacts; see the leading comments in
+ttsrc/mesa/swrast/s_tritemp.h/tt.
+/p
+
br
br
--
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
Re: [Mesa3d-dev] [PATCH 1/2] egl: Silence warnings on x86-64.
tom fogal tfo...@alumni.unh.edu writes: Chia-I Wu olva...@gmail.com 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 stdint.h #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 stdint.h #elif defined(_MSC_VER) typedef __int8 int8_t; ... #else # include stdint.h #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 olva...@gmail.com writes: On Tue, Jul 28, 2009 at 09:14:04PM -0600, tom fogal wrote: Chia-I Wu olva...@gmail.com 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 stdint.h #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 stdint.h +#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 olva...@gmail.com 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 stdint.h #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 olva...@gmail.com writes: /** + * Get standard integer types + */ +#if defined(_MSC_VER) + typedef __int8 int8_t; + typedef unsigned __int8uint8_t; [snip] +#else +# include stdint.h +#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 shran...@hotmail.com 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
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 andersjjen...@gmail.com 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 za...@vmware.com 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
Re: [Mesa3d-dev] OS X: _glCopyBufferSubData undefined on master
tom fogal tfo...@alumni.unh.edu 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 tfo...@alumni.unh.edu 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 @@ #define
[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
[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 bansal.it...@gmail.com 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 mailingli...@openelec.tv 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 bri...@vmware.com 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] Tiny fix for Mesa-Win32
Sukender suky0...@free.fr 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] Only export one set of glu symbol names: mangled or unmangled
Alan Coopersmith alan.coopersm...@sun.com 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 alan.coopersm...@sun.com
---
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 21 | 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] [PATCH] Remove `egl' from SRC_DIRS.
Dan Nicholson dbn.li...@gmail.com writes: On Tue, Apr 28, 2009 at 9:02 PM, tom fogal tfo...@alumni.unh.edu wrote: Tom Fogal tfo...@alumni.unh.edu 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] Use variable library name in pkg-config output.
Dan Nicholson dbn.li...@gmail.com writes:
On Tue, Apr 28, 2009 at 8:56 PM, Tom Fogal tfo...@alumni.unh.edu 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 tfo...@alumni.unh.edu
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 '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
[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
Re: [Mesa3d-dev] [PATCH] Use variable library name in pkg-config output.
Dan Nicholson dbn.li...@gmail.com writes: On Wed, Apr 29, 2009 at 9:32 AM, Tom Fogal tfo...@alumni.unh.edu 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
Re: [Mesa3d-dev] [PATCH] Remove `egl' from SRC_DIRS.
Dan Nicholson dbn.li...@gmail.com writes: On Wed, Apr 29, 2009 at 9:31 AM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Apr 28, 2009 at 10:57 PM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Apr 28, 2009 at 9:02 PM, tom fogal tfo...@alumni.unh.edu wrote: Tom Fogal tfo...@alumni.unh.edu 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 tfo...@alumni.unh.edu 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
[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
[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] 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] 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] Fix symbol list for mangled Mesa on Darwin.
Tom Fogal tfo...@alumni.unh.edu 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
Re: [Mesa3d-dev] Hacking GLU for more flexibility
arthur m artur_mi...@hotmail.com writes: I have been playing a bit with GLU library in context of 2d graphics. I found that GLU tessellator can be improved in regards of the interface with very little code added. I think you're talking to the wrong community about this. Mesa is/has just one implementation of GLU, which is a standard specified by the Khronos group. If you want to change GLU, you really want to propose your modifications to the standards group, as otherwise your program will break if the user has a different version of GLU than the one you hacked on / added your functions to. The GLU spec is here: http://www.opengl.org/documentation/specs/ Khronos group's website is here: http://www.khronos.org/ and information on membership is here: http://www.khronos.org/members/ Though maybe the solution is a new utility library -- the GLU spec apparently hasn't been updated in 11 years. *shrug*. HTH, -tom -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.4 release candidate 1
Brian Paul bri...@vmware.com writes: The first release candidate of Mesa 7.4 can be grabbed from http://www.mesa3d .org/beta/ 7.4 will be a stable release just fixing bugs since Mesa 7.3. Could: commit 7399d56ec6019e00297eef57f802a53698baa8ad commit 4447fddc82a2c0245e798c90492293d875d186d0 commit fe0ccf323daba2a5e2f0d9936477c73db044190a get cherry-picked, or is this too late? Discussion: http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg06789.html though it seemed like the thread took off on release schedules and the patches themeselves were left mostly in limbo. -tom -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: Add simple atomic class api.
thellst...@vmware.com writes:
[snip]
+#if (defined(PIPE_CC_GCC) defined(__i386__))
^
This is basically an #ifdef (__GNUC__), I'm guessing?
+struct pipe_atomic {
+ int32_t count;
+};
[snip]
+static INLINE int32_t
+p_atomic_cmpxchg(struct pipe_atomic *v, int32_t old, int32_t new)
+{
+ int32_t previous;
+
+ __asm__ __volatile__(lock; cmpxchgl %k1,%2:=a(previous)
+ :r(new), m(v-count), 0(old)
+ :memory);
+
+ return previous;
+}
If the code is only compiled on gcc anyway, it seems like one could
apply the atomics primitives provided by the compiler:
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Atomic-Builtins.html
That might allow you to remove the __i386__ qualification as well.
(Note that I've never tried these extensions, just an idea.)
-tom
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa with llvm?
Brian Paul bri...@vmware.com writes: Kamalneet Singh wrote: Stephane Marchesin wrote: [...] What specifically are you interested in ? FWIW all this stuff is quite unfinished... We have a project to develop OpenGL ES Shading Language compiler. We want to use llvm, [snip] For the long-term, we need a new GLSL compiler in Mesa. I think a new compil er which uses LLVM for code generation is the right way to go. LLVM has lot s of good optimization infrastructure that I wouldn't want to try to recreate . Could you elaborate on this? Are there more/bigger issues than what is mentioned under `Unsupported Features' at: http://www.mesa3d.org/shading.html ? -tom -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [glew-coders] Including GLEW in Mesa
Sorry to wake this thread up.. writes: On Thu, 2009-01-22 at 12:49 -0800, Brian Paul wrote: Ian Romanick wrote: On Thu, 2009-01-22 at 13:15 +, José Fonseca wrote: Mesa and Gallium3D include a big number of test and sample OpenGL apps. [snip] To make it easy to build the samples I plan to integrate the GLEW source code directly into Mesa: - include/GL/glew.h - include/GL/glxew.h - include/GL/wglew.h Since we're not intending to be the install-source of GLEW on people's system, I think the GLEW header files should go in src/glew/include. The Makefiles in progs/* can just add -I$(topdir)/src/glew/include to CFLAGS. Or, couldn't we simply omit the glew headers from 'make install'? Yeah, this is possible. I really don't care much either way, but putting in mesa/include/GL would save me the trouble of modifying all samples' makefiles. Could this (omitting headers from install) be done, please? I'm hacking on GLEW, using Mesa git-master sources, and just got bit by this -- my test programs are picking up Mesa's included GLEW instead of my modified version. -tom -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] glxapi: update get_proc_address for mangled names.
---
src/mesa/drivers/x11/glxapi.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/x11/glxapi.c b/src/mesa/drivers/x11/glxapi.c
index 19aca60..02eea25 100644
--- a/src/mesa/drivers/x11/glxapi.c
+++ b/src/mesa/drivers/x11/glxapi.c
@@ -1375,7 +1375,12 @@ _glxapi_get_proc_address(const char *funcName)
{
GLuint i;
for (i = 0; GLX_functions[i].Name; i++) {
+#ifdef MANGLE
+ /* skip the m prefix on the name */
+ if (strcmp(GLX_functions[i].Name, funcName+1) == 0)
+#else
if (strcmp(GLX_functions[i].Name, funcName) == 0)
+#endif
return GLX_functions[i].Address;
}
return NULL;
--
1.5.6.5
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Correct fix for finding mangled mesa symbols?
Brian Paul brian.e.p...@gmail.com writes: On Fri, Feb 20, 2009 at 7:48 PM, tom fogal tfo...@alumni.unh.edu wrote: There is an issue loading mangled mesa symbols. [snip] Please inform me which of these solutions you'd like to see: 1. Remove the #ifdef MANGLE case. 2. use an #ifdef MANGLE case in find_entry to dynamically build a string 3. Change the table such that it contains [. . .] `mglBegin' in the mangled case. 4. other that I haven't thought of (please explain) I opted for #2 by just skipping the 'm' prefix for the mangled case. Ahh, yes, I see the patch; that's a much better solution. There's some other strcmp() calls that may need updating too. Maybe you could follow-up with patches if more changes are needed. I've verified my small program that just loads `mglBegin' works, but I will definitely do so if the larger work involved requires. Updated code in git (plus your other two issues). Thanks! -tom -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Add `glRenderbufferStorageMultisample' to mangling list.
Missing entry causes undefined references when using mangled mesa. --- include/GL/gl_mangle.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index 1dcd4a8..a7106e6 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -974,6 +974,7 @@ #define glRenderbufferStorageEXT MANGLE(RenderbufferStorageEXT) #define glRenderbufferStorageMultisampleCoverageNV MANGLE(RenderbufferStorageMultisampleCoverageNV) #define glRenderbufferStorageMultisampleEXT MANGLE(RenderbufferStorageMultisampleEXT) +#define glRenderbufferStorageMultisample MANGLE(RenderbufferStorageMultisample) #define glRenderMode MANGLE(RenderMode) #define glReplacementCodePointerSUN MANGLE(ReplacementCodePointerSUN) #define glReplacementCodeubSUN MANGLE(ReplacementCodeubSUN) -- 1.5.6.5 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Add missing `extern' to function declaration.
--- src/mesa/main/fbobject.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h index 33d16cc..5409394 100644 --- a/src/mesa/main/fbobject.h +++ b/src/mesa/main/fbobject.h @@ -83,7 +83,7 @@ extern void GLAPIENTRY _mesa_RenderbufferStorageEXT(GLenum target, GLenum internalformat, GLsizei width, GLsizei height); -void GLAPIENTRY +extern void GLAPIENTRY _mesa_RenderbufferStorageMultisample(GLenum target, GLsizei samples, GLenum internalformat, GLsizei width, GLsizei height); -- 1.5.6.5 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Correct fix for finding mangled mesa symbols?
There is an issue loading mangled mesa symbols.
In _glapi_get_proc_address, there is the code:
#ifdef MANGLE
if (funcName[0] != 'm' || funcName[1] != 'g' || funcName[2] != 'l')
return NULL;
#else
if (funcName[0] != 'g' || funcName[1] != 'l')
return NULL;
#endif
thus, if the user is mangling mesa, any string they give which does not
have the mangled name will quickly return NULL. Sure, fine, but then
eventually `find_entry' will be called for some paths, which contains
the code:
for(i from 1 to N...) {
const char *testName = gl_string_table + static_functions[i].Name_offset;
if (strcmp(testName, n) == 0) {
return static_functions[i];
}
}
Unfortunately the static_functions table only contains the demangled
names. Thus, the user *cannot* load functions from a mangled mesa
library: if they use the non-mangled name, then the #ifdef in
_glapi_get_proc_address will bail on them without even searching; if
they use the mangled name, find_entry will iterate through the entire
table and never find a match because the table only contains the
non-mangled name.
I have verified that removing the `#ifdef MANGLE' case and simply
using the else clause allows the user to load basic functions, e.g.
`glBegin'. Of course, this means that a user must load `glBegin'
instead of `mglBegin' regardless of whether or not they are using
mangled Mesa.
I'm not really sure if that's a good thing or a bad thing, but I'll let
you decide. Please inform me which of these solutions you'd like to
see:
1. Remove the #ifdef MANGLE case. To load `glBegin', for example,
users must call `mglXGetProcAddress(glBegin)'. [1]
2. use an #ifdef MANGLE case in find_entry to dynamically build a
string which is essentially (m concat gl_string_table +
static_functions[i].Name_offset). Do the comparison based on
the dynamic string and the argument.
3. Change the table such that it contains `glBegin' (etc.) in the
unmangled case, and `mglBegin' in the mangled case.
4. other that I haven't thought of (please explain)
Thanks,
-tom
[1] I imagine glXGetProcAddressARB(glBegin) would work too. My use
case necessitates the former though, so I haven't tried.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
