https://bugs.freedesktop.org/show_bug.cgi?id=45420
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
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 '\draw_create\' src/gallium/drivers/
On 12-01-30 12:33 PM, Matt Turner wrote:
On Mon, Jan 30, 2012 at 12:03 PM, Gaetan Nadon mems...@videotron.ca 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
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
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 until
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*)’:
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.
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
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
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:
On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul bri...@vmware.com 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:
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
On Tue, Jan 31, 2012 at 9:32 AM, Matt Turner matts...@gmail.com wrote:
On Tue, Jan 31, 2012 at 2:12 PM, Brian Paul bri...@vmware.com wrote:
I just ran into this problem this morning.
make realclean
./autogen.sh
./configure --disable-dri --enable-xlib-glx --enable-osmesa --enable-debug
make
https://bugs.freedesktop.org/show_bug.cgi?id=45444
Kevin DeKorte kdeko...@yahoo.com changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=45444
Kevin DeKorte kdeko...@yahoo.com changed:
What|Removed |Added
CC|
From: Ian Romanick ian.d.roman...@intel.com
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,
https://bugs.freedesktop.org/show_bug.cgi?id=45444
--- Comment #2 from Emeric Grange emeric.gra...@gmail.com 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/show_bug.cgi?id=45444
--- Comment #3 from Christian König deathsim...@vodafone.de 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
On Tue, Jan 31, 2012 at 10:50 AM, Kevin H. Hobbs hob...@ohio.edu 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 master
Matt Turner wrote:
On Tue, Jan 31, 2012 at 6:18 AM, Andy Furnissandy...@ukfsn.org 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
I am getting a build fail with vdpau since
commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt e...@anholt.net
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
Andy Furniss wrote:
I am getting a build fail with vdpau since
I see it's fixed now.
commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt e...@anholt.net
Date: Thu Jan 26 18:48:20 2012 -0800
autoconf: Enable missing-prototypes errors when available.
After the removal of the
On 31.01.2012 17:22, Andy Furniss wrote:
I am getting a build fail with vdpau since
commit b9aab8b3b3769b9c5121686efe3446dae770b951
Author: Eric Anholt e...@anholt.net
Date: Thu Jan 26 18:48:20 2012 -0800
autoconf: Enable missing-prototypes errors when available.
After the removal
On 01/31/2012 08:32 AM, Matt Turner wrote:
On Tue, Jan 31, 2012 at 9:32 AM, Matt Turnermatts...@gmail.com wrote:
On Tue, Jan 31, 2012 at 2:12 PM, Brian Paulbri...@vmware.com wrote:
I just ran into this problem this morning.
make realclean
./autogen.sh
./configure --disable-dri
-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 hob...@ohio.edu
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
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 :
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 simon.farnswo...@onelan.co.uk
---
This builds on top of the kernel interface I
On Tue, Jan 31, 2012 at 11:36 AM, Brian Paul bri...@vmware.com wrote:
On 01/31/2012 08:32 AM, Matt Turner wrote:
On Tue, Jan 31, 2012 at 9:32 AM, Matt Turnermatts...@gmail.com wrote:
On Tue, Jan 31, 2012 at 2:12 PM, Brian Paulbri...@vmware.com wrote:
I just ran into this problem this
On Tue, 31 Jan 2012 10:50:51 -0500, Kevin H. Hobbs hob...@ohio.edu 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
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
On 30 January 2012 20:08, Matt Turner matts...@gmail.com wrote:
On Mon, Jan 30, 2012 at 10:28 PM, Paul Berry stereotype...@gmail.com
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
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
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 of
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
https://bugs.freedesktop.org/show_bug.cgi?id=45458
Kevin DeKorte kdeko...@yahoo.com changed:
What|Removed |Added
CC||bri...@vmware.com,
From: Dave Airlie airl...@redhat.com
/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 airl...@redhat.com
---
src/glsl/standalone_scaffolding.h |2 +-
1 files changed, 1
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
https://bugs.freedesktop.org/show_bug.cgi?id=45458
--- Comment #1 from Kevin DeKorte kdeko...@yahoo.com 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:
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
https://bugs.freedesktop.org/show_bug.cgi?id=45458
--- Comment #2 from Kenneth Graunke kenn...@whitecape.org 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
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 -
https://bugs.freedesktop.org/show_bug.cgi?id=45458
--- Comment #3 from Matt Turner matts...@gmail.com 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/show_bug.cgi?id=45458
--- Comment #4 from Kevin DeKorte kdeko...@yahoo.com 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/show_bug.cgi?id=45458
--- Comment #5 from Kevin DeKorte kdeko...@yahoo.com 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:
On Tue, Jan 31, 2012 at 3:12 PM, Andy Furniss andy...@ukfsn.org 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
https://bugs.freedesktop.org/show_bug.cgi?id=45458
--- Comment #6 from Matt Turner matts...@gmail.com 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
On Tue, Jan 31, 2012 at 2:31 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
/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
Matt Turner wrote:
On Tue, Jan 31, 2012 at 3:12 PM, Andy Furnissandy...@ukfsn.org 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
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
On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
$ makelog
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/: Is a
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:
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
https://bugs.freedesktop.org/show_bug.cgi?id=45458
--- Comment #7 from Ian Romanick i...@freedesktop.org 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:
From: Ian Romanick ian.d.roman...@intel.com
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 ian.d.roman...@intel.com
Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=45458
--- Comment #8 from Kevin DeKorte kdeko...@yahoo.com 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:
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
On 01/31/2012 02:44 PM, Zack Rusin wrote:
On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
$ makelog
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=45420
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
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.
On Tue, Jan 31, 2012 at 7:05 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Tue, Jan 31, 2012 at 4:47 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
This is a partial revert of f9874fe. It turns out that the types
don't always match. Specifically,
On Tue, Jan 31, 2012 at 8:32 PM, Brian Paul bri...@vmware.com wrote:
On 01/31/2012 02:44 PM, Zack Rusin wrote:
On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
$ makelog
ar: creating libglapi.a
ar: creating libmesa.a
ar: libmesa.a: Error reading ../../src/glsl/.libs/: Is a
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
From: Ville Syrjala syrj...@sci.fi
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
On 01/31/2012 06:26 PM, Matt Turner wrote:
On Tue, Jan 31, 2012 at 8:32 PM, Brian Paulbri...@vmware.com wrote:
On 01/31/2012 02:44 PM, Zack Rusin wrote:
On Tuesday, January 31, 2012 12:02:28 PM Matt Turner wrote:
$ makelog
ar: creating libglapi.a
ar: creating libmesa.a
ar: libmesa.a: Error
https://bugs.freedesktop.org/show_bug.cgi?id=45458
Matt Turner matts...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Jan 31, 2012 at 4:26 AM, Sanjoy Saha - ERS, HCL Tech
sanjoy.s...@hcl.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=45420
ojab o...@ojab.ru changed:
What|Removed |Added
Attachment #56357|0 |1
is obsolete|
69 matches
Mail list logo
