[Mesa-dev] [Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'

https://bugs.freedesktop.org/show_bug.cgi?id=45420 ojab changed: What|Removed |Added Attachment #56357|0 |1 is obsolete|

Re: [Mesa-dev] Help required in configuring mesa 3d in non X environment.

On Tue, Jan 31, 2012 at 4:26 AM, Sanjoy Saha - ERS, HCL Tech wrote: > Matt, >   I tried with --disable-glx option in autogen.sh line and I am still getting > the same error. Below is the log output. The option --disable-glx is not > recognized "configure: WARNING: unrecognized options: --disable

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 Matt Turner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [Mesa-dev] undefined C++ GLSL symbol error

On 01/31/2012 06:26 PM, Matt Turner wrote: On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul wrote: On 01/31/2012 02:44 PM, Zack Rusin wrote: On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote: $ make>log ar: creating libglapi.a ar: creating libmesa.a ar: libmesa.a: Error reading ../../sr

[Mesa-dev] [PATCH] gallium/dri: Handle xserver that doesn't send needless DRI2 invalidate events

From: Ville Syrjala Ever since xserver commit 531869448d07e00ae241120b59f35709d59c, the server no longer sends invalidate events to clients, unless they have performed a GetBuffers request since the drawable was last invalidated. If the drawable gets invalidated immediately after the GetBuff

Re: [Mesa-dev] [PATCH] Do not use sched_yield() on Linux

On 1/31/12 12:30 PM, Alan Swanson wrote: As discussed back in 2003, sched_yield() on Linux is no longer equivalent to other POSIX variations. From a LWN article; "This call used to simply move the process to the end of the run queue; now it moves the process to the "expired" queue, effectively ca

Re: [Mesa-dev] undefined C++ GLSL symbol error

On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul wrote: > On 01/31/2012 02:44 PM, Zack Rusin wrote: >> >> On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote: $ make>log ar: creating libglapi.a ar: creating libmesa.a ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is

Re: [Mesa-dev] [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

On Tue, Jan 31, 2012 at 7:05 PM, Brian Paul wrote: > On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick wrote: >> From: Ian Romanick >> >> This is a partial revert of f9874fe.  It turns out that the types >> don't always match.  Specifically, this can happen when doing >> glCopyPixels from a float FB

Re: [Mesa-dev] [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick wrote: > From: Ian Romanick > > This is a partial revert of f9874fe.  It turns out that the types > don't always match.  Specifically, this can happen when doing > glCopyPixels from a float FBO to a RGBA8 FBO. > > Signed-off-by: Ian Romanick > Bugzil

[Mesa-dev] [Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'

https://bugs.freedesktop.org/show_bug.cgi?id=45420 Vinson Lee changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Mesa-dev] [PATCH 2/2] mesa: reference shared state in glPushAttrib(GL_TEXTURE_BIT)

This fixes a dangling texture object pointer bug hit via wglShareLists(). When we push the GL_TEXTURE_BIT state we may push references to the default texture objects which are owned by the gl_shared_state object. We don't want to accidentally delete that shared state while the attribute stack refe

[Mesa-dev] [PATCH 1/2] mesa: use new _mesa_reference_shared_state() function

This cleans up the reference counting of shared context state. The next patch will use this to fix an actual bug. NOTE: This is a candidate for the 8.0 branch. --- src/mesa/main/context.c | 28 -- src/mesa/main/shared.c | 48 +--

Re: [Mesa-dev] undefined C++ GLSL symbol error

On 01/31/2012 02:44 PM, Zack Rusin wrote: On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote: $ make>log ar: creating libglapi.a ar: creating libmesa.a ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is a directory ar: creating libmesagallium.a ar: libmesagallium.a: Error reading ../

[Mesa-dev] [PATCH] glsl: Implement ralloc with talloc

Since talloc has more debugging features than ralloc, such as the very useful: talloc_report_full(ctx, stdout); we here conditionally implement ralloc by simply calling directly into talloc. NOTE: This commit is simply example code that I used recently, and I thought I should share in c

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #8 from Kevin DeKorte 2012-01-31 16:12:40 PST --- I had this working yesterday and with the patch in bug #45466 I can get to compile again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are

[Mesa-dev] [PATCH] mesa: Convert colors if span ChanType and renderbuffer data type don't match

From: Ian Romanick This is a partial revert of f9874fe. It turns out that the types don't always match. Specifically, this can happen when doing glCopyPixels from a float FBO to a RGBA8 FBO. Signed-off-by: Ian Romanick Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45429 --- src/mesa

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #7 from Ian Romanick 2012-01-31 15:47:23 PST --- 32-bit-on-64-bit builds have been broken for some time. I report this back in October of 2011: bug #41700. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[Mesa-dev] [PATCH] gen_matypes: fix cross-compiling with gcc

The current gen_matypes logic assumes that the host compiler will produce information that is useful for the target compiler. Unfortunately, this is not the case whenever cross-compiling. When we detect that we're cross-compiling and using GCC, use the target compiler to produce assembly from the

[Mesa-dev] [Bug 45466] New: Updated configure.ac check for llvm-config to use 32 version when appropriate

https://bugs.freedesktop.org/show_bug.cgi?id=45466 Bug #: 45466 Summary: Updated configure.ac check for llvm-config to use 32 version when appropriate Classification: Unclassified Product: Mesa Version: git Platform: O

Re: [Mesa-dev] undefined C++ GLSL symbol error

On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote: > > $ make>log > > ar: creating libglapi.a > > ar: creating libmesa.a > > ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is a directory > > ar: creating libmesagallium.a > > ar: libmesagallium.a: Error reading ../../src/glsl/.libs/: I

Re: [Mesa-dev] Build fail since Make sure libGL.so links with libglsl

Brian Paul wrote: make[3]: *** [r600_dri.so] Error 1 I've been running into weird build problems all day too (I'm seeing the same problem with softpipe ATM using very simple configure options). It seems that make -j8 is flakey too. I've had better luck omitting -j. That definitely needs to be

Re: [Mesa-dev] Build fail since Make sure libGL.so links with libglsl

Matt Turner wrote: On Tue, Jan 31, 2012 at 3:12 PM, Andy Furniss wrote: Maybe it's just me having a strange/old LFS system - but I am getting build errors since Are you subscribed? It seems so is everyone else. :P Make sure libGL.so links with libglsl f53e7e981ef35ab64a084c8da6c67bd2d230fe

Re: [Mesa-dev] [PATCH] glsl: fix scaffolding build

On Tue, Jan 31, 2012 at 2:31 PM, Dave Airlie wrote: > From: Dave Airlie > > /usr/bin/ld: .libs/glsl_compiler: hidden symbol `_mesa_reference_shader' in > standalone_scaffolding.o is referenced by DSO > > export the symbol. > > Signed-off-by: Dave Airlie > --- >  src/glsl/standalone_scaffolding.

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #6 from Matt Turner 2012-01-31 12:33:05 PST --- (In reply to comment #4) > Adding those flags before autogen does seem to fix it, but shouldn't that be > what --enable-32-bit does? Yes. Please send a patch. :) (In reply to comment #

Re: [Mesa-dev] Build fail since Make sure libGL.so links with libglsl

On Tue, Jan 31, 2012 at 3:12 PM, Andy Furniss wrote: > Maybe it's just me having a strange/old LFS system  - but I am getting build > errors since Are you subscribed? It seems so is everyone else. :P > Make sure libGL.so links with libglsl > f53e7e981ef35ab64a084c8da6c67bd2d230fe33 *Since* this

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #5 from Kevin DeKorte 2012-01-31 12:22:28 PST --- I think we want the --enable-32-bit so that we can build 32bit binaries on a 64bit machine so that we can run 32bit applications. -- Configure bugmail: https://bugs.freedesktop.org/

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #4 from Kevin DeKorte 2012-01-31 12:21:22 PST --- Adding those flags before autogen does seem to fix it, but shouldn't that be what --enable-32-bit does? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #3 from Matt Turner 2012-01-31 12:19:37 PST --- If that fixes it, then yeah. The real solution is to automake everything and then kill the --enable-{32,64}-bit flags. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi

Re: [Mesa-dev] Build fail since Make sure libGL.so links with libglsl

On 01/31/2012 01:12 PM, Andy Furniss wrote: Maybe it's just me having a strange/old LFS system - but I am getting build errors since Make sure libGL.so links with libglsl f53e7e981ef35ab64a084c8da6c67bd2d230fe33 Perhaps my build options are to blame - CPPFLAGS="-I/home/andy/Src/Xorg-git/modul

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #2 from Kenneth Graunke 2012-01-31 12:13:40 PST --- Yeah, I'm pretty sure this broke a while back. It -should- work if you do: CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --enable-32-bit --more-options-here Which also has the added

[Mesa-dev] Build fail since Make sure libGL.so links with libglsl

Maybe it's just me having a strange/old LFS system - but I am getting build errors since Make sure libGL.so links with libglsl f53e7e981ef35ab64a084c8da6c67bd2d230fe33 Perhaps my build options are to blame - CPPFLAGS="-I/home/andy/Src/Xorg-git/modular/include" LDFLAGS="-L/home/andy/Src/Xor

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 --- Comment #1 from Kevin DeKorte 2012-01-31 11:58:45 PST --- After additional research it appears the build triplet is wrong. I don't think that the --enable-32-bit flag is being honored by libglsl -- Configure bugmail: https://bugs.freedeskt

Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering

On 1/30/12 12:14 PM, Kevin H. Hobbs wrote: The VTK tests have the same pattern of failures with the Fedora 15 OSMesa package as with the custom built OSMesa library, that is : Thanks, so it does. Works fine on Fedora 15 and Red Hat EL6 too. FYI, since I'm very interested in repeatable deployme

[Mesa-dev] [PATCH] glsl: fix scaffolding build

From: Dave Airlie /usr/bin/ld: .libs/glsl_compiler: hidden symbol `_mesa_reference_shader' in standalone_scaffolding.o is referenced by DSO export the symbol. Signed-off-by: Dave Airlie --- src/glsl/standalone_scaffolding.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --

[Mesa-dev] [Bug 45458] mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 Kevin DeKorte changed: What|Removed |Added CC||bri...@vmware.com, |

[Mesa-dev] [Bug 45458] New: mesa will not compile in 32bit mode on a 64bit machine that is setup to do that

https://bugs.freedesktop.org/show_bug.cgi?id=45458 Bug #: 45458 Summary: mesa will not compile in 32bit mode on a 64bit machine that is setup to do that Classification: Unclassified Product: Mesa Version: git Platform:

Re: [Mesa-dev] OSMesa glapi linlking

On 01/31/2012 09:53 AM, Brian Paul wrote: > > I just pushed a couple osmesa fixes to master and the 8.0 branch. Can > you give it a try? > > Thinks seem to fix things on the 8.0 branch but I'm unable to verify > on master due to some other regressions ATM. > > -Brian > master leaves a bunch

Re: [Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION

On 31.01.2012 09:49, Jose Fonseca wrote: > I don't oppose adding the cap. > > But I think that the story for draw module should be figured out, as at least > nv50/nvc0 drivers will advertise > PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 1 and are using the draw > module: > > $ git grep '

Re: [Mesa-dev] [PATCH] glsl: Fix optimization tests after converting src/glsl to automake.

On 30 January 2012 20:08, Matt Turner wrote: > On Mon, Jan 30, 2012 at 10:28 PM, Paul Berry > wrote: > > Commit 99476561 (automake: src/glsl and src/glsl/glcpp) changed the > > build system so that src/glsl/glsl_test is not built by default. This > > inadvertently broke "make check", since the

Re: [Mesa-dev] [PATCH] r600g: Use new kernel interface to wait for fences

On Die, 2012-01-31 at 17:02 +, Simon Farnsworth wrote: > Instead of busywaiting for the GPU to finish a fence, use the new kernel > interface to wait for fence completion. > > If the new kernel interface is unavailable, fall back to busywaiting. > > Signed-off-by: Simon Farnsworth [...] >

[Mesa-dev] [PATCH] Do not use sched_yield() on Linux

As discussed back in 2003, sched_yield() on Linux is no longer equivalent to other POSIX variations. From a LWN article; "This call used to simply move the process to the end of the run queue; now it moves the process to the "expired" queue, effectively cancelling the rest of the process's time sli

Re: [Mesa-dev] [PATCH] Do not use sched_yield() on Linux

On Tuesday 31 January 2012, Alan Swanson wrote: > As discussed back in 2003, sched_yield() on Linux is no longer > equivalent to other POSIX variations. From a LWN article; "This call > used to simply move the process to the end of the run queue; now it > moves the process to the "expired" queue,

Re: [Mesa-dev] OSMesa glapi linlking

On Tue, 31 Jan 2012 10:50:51 -0500, "Kevin H. Hobbs" wrote: > On 01/31/2012 09:53 AM, Brian Paul wrote: > > > > Kevin, > > > > I just pushed a couple osmesa fixes to master and the 8.0 branch. Can > > you give it a try? > > > > Thinks seem to fix things on the 8.0 branch but I'm unable to ver

Re: [Mesa-dev] undefined C++ GLSL symbol error

On Tue, Jan 31, 2012 at 11:36 AM, Brian Paul wrote: > On 01/31/2012 08:32 AM, Matt Turner wrote: >> >> On Tue, Jan 31, 2012 at 9:32 AM, Matt Turner  wrote: >>> >>> On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul  wrote: I just ran into this problem this morning. make realclean

[Mesa-dev] [PATCH] r600g: Use new kernel interface to wait for fences

Instead of busywaiting for the GPU to finish a fence, use the new kernel interface to wait for fence completion. If the new kernel interface is unavailable, fall back to busywaiting. Signed-off-by: Simon Farnsworth --- This builds on top of the kernel interface I add in Message-Id: <1328029169-1

Re: [Mesa-dev] OSMesa glapi linlking

On 01/31/2012 11:14 AM, Matt Turner wrote: > > You cannot change branches or bisect without running autogen.sh (and > maybe git clean to be safe). I see glsl_lexer.cc in your log, which > exists only in the master branch. > Sorry, I left a lot out, but I can't be certain I did enough cleaning so

Re: [Mesa-dev] [PATCH 2/2] dri: Add Unigine Tropics as an app that requires the GLSL warn workaround.

On Mon, Jan 30, 2012 at 21:23, Eric Anholt wrote: > I wasn't seeing it be needed because of the previous bug. > --- > src/mesa/drivers/dri/common/drirc |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > For both patches: Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov

Re: [Mesa-dev] OSMesa glapi linlking

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2012 09:14 AM, Matt Turner wrote: > On Tue, Jan 31, 2012 at 10:50 AM, Kevin H. Hobbs > wrote: >> On 01/31/2012 09:53 AM, Brian Paul wrote: >>> >>> Kevin, >>> >>> I just pushed a couple osmesa fixes to master and the 8.0 >>> branch. Can you

Re: [Mesa-dev] undefined C++ GLSL symbol error

On 01/31/2012 08:32 AM, Matt Turner wrote: On Tue, Jan 31, 2012 at 9:32 AM, Matt Turner wrote: On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul wrote: I just ran into this problem this morning. make realclean ./autogen.sh ./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug

Re: [Mesa-dev] VDPAU build fail since autoconf: Enable missing-prototypes errors when available.

On 31.01.2012 17:22, Andy Furniss wrote: I am getting a build fail with vdpau since commit b9aab8b3b3769b9c5121686efe3446dae770b951 Author: Eric Anholt Date: Thu Jan 26 18:48:20 2012 -0800 autoconf: Enable missing-prototypes errors when available. After the removal of the dri driver

Re: [Mesa-dev] VDPAU build fail since autoconf: Enable missing-prototypes errors when available.

Andy Furniss wrote: I am getting a build fail with vdpau since I see it's fixed now. commit b9aab8b3b3769b9c5121686efe3446dae770b951 Author: Eric Anholt Date: Thu Jan 26 18:48:20 2012 -0800 autoconf: Enable missing-prototypes errors when available. After the removal of the dri driver link

[Mesa-dev] VDPAU build fail since autoconf: Enable missing-prototypes errors when available.

I am getting a build fail with vdpau since commit b9aab8b3b3769b9c5121686efe3446dae770b951 Author: Eric Anholt Date: Thu Jan 26 18:48:20 2012 -0800 autoconf: Enable missing-prototypes errors when available. After the removal of the dri driver link test, this should help avoid the

Re: [Mesa-dev] build errors and make distclean

Matt Turner wrote: On Tue, Jan 31, 2012 at 6:18 AM, Andy Furniss wrote: I am getting a build error today - will have time later to investigate more. I did notice, though that make distclean on head is not cleaning well enough for me to git reset --hard back to somewhere that previously worked

Re: [Mesa-dev] OSMesa glapi linlking

On Tue, Jan 31, 2012 at 10:50 AM, Kevin H. Hobbs wrote: > On 01/31/2012 09:53 AM, Brian Paul wrote: >> >> Kevin, >> >> I just pushed a couple osmesa fixes to master and the 8.0 branch.  Can >> you give it a try? >> >> Thinks seem to fix things on the 8.0 branch but I'm unable to verify >> on maste

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

https://bugs.freedesktop.org/show_bug.cgi?id=45444 --- Comment #3 from Christian König 2012-01-31 08:13:54 PST --- That was a one liner. Fix pushed to master. Christian. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: ---

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

https://bugs.freedesktop.org/show_bug.cgi?id=45444 --- Comment #2 from Emeric Grange 2012-01-31 08:11:57 PST --- Seems like #include "vdpau_private.h" is missing inside src/gallium/state_trackers/vdpau/preemption.c ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --

[Mesa-dev] [PATCH] mesa: Set the gl_array_object::ARBsemantics flag at the right time

From: Ian Romanick With 0963990 the flag was only set when Bind created the object. In all cases where ::ARBsemantics could be true, this path never happened. Instead, add a _Used flag to track whether a VAO has ever been bound. On the first Bind, set the _Used flag, and set the ARBsemantics f

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

https://bugs.freedesktop.org/show_bug.cgi?id=45444 Christian König changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Christian

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

https://bugs.freedesktop.org/show_bug.cgi?id=45444 Kevin DeKorte changed: What|Removed |Added CC||deathsim...@vodafone.de -- Configure bu

[Mesa-dev] [Bug 45444] Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

https://bugs.freedesktop.org/show_bug.cgi?id=45444 Kevin DeKorte changed: What|Removed |Added CC||emeric.gra...@gmail.com -- Configure bu

Re: [Mesa-dev] OSMesa glapi linlking

On 01/31/2012 09:53 AM, Brian Paul wrote: > > Kevin, > > I just pushed a couple osmesa fixes to master and the 8.0 branch. Can > you give it a try? > > Thinks seem to fix things on the 8.0 branch but I'm unable to verify > on master due to some other regressions ATM. > > -Brian > [kevin@bu

Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering

On 01/31/2012 09:55 AM, Brian Paul wrote: > On 01/30/2012 01:14 PM, Kevin H. Hobbs wrote: >> >> The VTK tests have the same pattern of failures with the Fedora 15 >> OSMesa package as with the custom built OSMesa library, that is : >> >> The following tests FAILED: >> 146 - TestTecplotRea

Re: [Mesa-dev] undefined C++ GLSL symbol error

On Tue, Jan 31, 2012 at 9:32 AM, Matt Turner wrote: > On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul wrote: >> I just ran into this problem this morning. >> >> make realclean >> ./autogen.sh >> ./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug >> make >> >> The build appears

Re: [Mesa-dev] Segmentation fault with VTK OffScreenRendering

On 01/30/2012 01:14 PM, Kevin H. Hobbs wrote: On 01/30/2012 02:53 PM, Kevin H. Hobbs wrote: I'm trying that now but you can give it a shot before then. The VTK tests have the same pattern of failures with the Fedora 15 OSMesa package as with the custom built OSMesa library, that is : The fo

Re: [Mesa-dev] OSMesa glapi linlking

On 01/30/2012 11:27 AM, Kevin H. Hobbs wrote: On 01/30/2012 12:15 PM, Brian Paul wrote: On 01/30/2012 08:56 AM, Kevin H. Hobbs wrote: I tried with just the lines added manually and almost every VTK test gives me: osmesa.c:892: OSMesaMakeCurrent: Assertion `osmesa->srb->Base.RefCount == 2' fai

Re: [Mesa-dev] [PATCH] osmesa: Fix osmesa_context.DataType type.

On 01/27/2012 11:36 PM, Vinson Lee wrote: Fixes these GCC warnings. osmesa.c: In function ‘osmesa_renderbuffer_storage’: osmesa.c:417: warning: comparison is always false due to limited range of data type osmesa.c:423: warning: comparison is always false due to limited range of data type osmesa

Re: [Mesa-dev] undefined C++ GLSL symbol error

On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul wrote: > I just ran into this problem this morning. > > make realclean > ./autogen.sh > ./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug > make > > The build appears to go fine, but when I try to run any GL app I get: > > glxinf

Re: [Mesa-dev] undefined C++ GLSL symbol error

On 01/31/2012 07:12 AM, Brian Paul wrote: I just ran into this problem this morning. make realclean ./autogen.sh ./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug make The build appears to go fine, but when I try to run any GL app I get: glxinfo: symbol lookup error: /

[Mesa-dev] [Bug 45444] New: Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a

https://bugs.freedesktop.org/show_bug.cgi?id=45444 Bug #: 45444 Summary: Compilation error with git 6386f80dbd6f1230abf16fa5ac65dc0dca70033a Classification: Unclassified Product: Mesa Version: git Platform: Other

[Mesa-dev] undefined C++ GLSL symbol error

I just ran into this problem this morning. make realclean ./autogen.sh ./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug make The build appears to go fine, but when I try to run any GL app I get: glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1: undefined

Re: [Mesa-dev] Help required in configuring mesa 3d in non X environment.

Matt, I tried with --disable-glx option in autogen.sh line and I am still getting the same error. Below is the log output. The option --disable-glx is not recognized "configure: WARNING: unrecognized options: --disable-glx". The mesa version I am using is mesa-7.11. root@MPC8641HPCN:~/workin

[Mesa-dev] [PATCH] nv50: use larger arrays to silence warnings

The warnings were: nv50_pc_regalloc.c: In function ‘pass_generate_phi_movs’: nv50_pc_regalloc.c:423:41: warning: array subscript is above array bounds codegen/nv50_ir_peephole.cpp: In member function ‘bool nv50_ir::MemoryOpt::replaceStFromSt(nv50_ir::Instruction*, nv50_ir::MemoryOpt::Record*)’: c

Re: [Mesa-dev] [PATCH] autoconf: Enable missing-prototypes errors when available.

On 27/01/2012 19:58, Eric Anholt wrote: > After the removal of the dri driver link test, this should help avoid > the original problem that it was designed to catch: The warning about > a missing prototype due to typoing a function name scrolling by in the > Mesa build spew, and you not noticing un

Re: [Mesa-dev] build errors and make distclean

On Tue, Jan 31, 2012 at 6:18 AM, Andy Furniss wrote: > I am getting a build error today - will have time later to investigate more. > > I did notice, though that make distclean on head is not cleaning well enough > for me to git reset --hard back to somewhere that previously worked without > build

[Mesa-dev] build errors and make distclean

I am getting a build error today - will have time later to investigate more. I did notice, though that make distclean on head is not cleaning well enough for me to git reset --hard back to somewhere that previously worked without build errors. I have to look at git status and manually clean u

Re: [Mesa-dev] [PATCH] Rename R300_NO_TCL envvar to RADEON_NO_TCL

On Mon, 2012-01-30 at 14:04 -0500, Matt Turner wrote: > The envvar works for R100 and R200 too, and the classic R300 driver > doesn't even exist anymore. RADEON_NO_TCL is kind of redundant for the radeon and r200 drivers, which both support the driconf tcl_mode setting. (r200 also listens to R200

Re: [Mesa-dev] [PATCH 5/5] src/glsl/glcpp: wire up glcpp-test to make check

On 12-01-30 12:33 PM, Matt Turner wrote: > On Mon, Jan 30, 2012 at 12:03 PM, Gaetan Nadon wrote: >> Sorry, I meant $(top_builddir)/src/glsl/glcpp or whatever the correct >> location is. > I don't understand -- I'm not seeing top_builddir or builddir defined > in the execution of tests/glcpp-test.

Re: [Mesa-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION

I don't oppose adding the cap. But I think that the story for draw module should be figured out, as at least nv50/nvc0 drivers will advertise PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 1 and are using the draw module: $ git grep '\' src/gallium/drivers/ src/gallium/drivers/i915/i915_c

[Mesa-dev] [Bug 45420] undefined reference to `LLVMInitializeARMDisassembler'

https://bugs.freedesktop.org/show_bug.cgi?id=45420 José Fonseca changed: What|Removed |Added Status|NEW |RESOLVED Resolution|