Ilia, thank you for looking at it.
On 04/30/2014 12:47 PM, Ilia Mirkin wrote:
> The relevant code:
>
>if (slab->free == 0) {
> LIST_DEL(&slab->head);
> LIST_ADD(&slab->head, &bucket->full);
>}
>
> And the LIST_ADD is line 206 (on the 9.2 branch).
>
> Do you know if multiple
I'm running Minecraft 1.7.9
on Fedora 19 x86_64
with mesa-dri-drivers-9.2.4-1.20131128.fc19.x86_64.
lspci says my graphics card is :
01:00.0 VGA compatible controller: NVIDIA Corporation G86 [Quadro
NVS 290] (rev a1)
The the console output says :
A fatal error has been detected by the Java Ru
On 08/21/2013 10:06 AM, Brian Paul wrote:
> On 08/20/2013 03:18 PM, Matt Turner wrote:
>> The Gallium implementation is apparently not ready for regular
>> consumption, so as much as I hate adding more build-time options, here's
>> another.
>>
>
> The intention was for the old/swrast version of OS
On 08/12/2013 10:29 AM, Brian Paul wrote:
> On 08/09/2013 01:50 PM, Kevin H. Hobbs wrote:
>> (gdb) print pstip
>> $1 = (struct pstip_stage *) 0xff66331aff66331a
>>
>> I don't think my actual RAM goes that high.
>
> That looks suspect since the low and high
On 08/13/2013 01:41 PM, Kevin H. Hobbs wrote:
>
> Ha! I can move the segfault all the way back to :
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe0ba6d43 in osmesa_st_framebuffer_flush_front
> (stctx=0x1518ee0, stfbi=0x1520560,
> statt=ST_ATTA
On 08/13/2013 11:45 AM, Kevin H. Hobbs wrote:
> On 08/13/2013 09:50 AM, Brian Paul wrote:
>> On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
>>>
>>> --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV)
>>> - exiting
>>>
>> W
On 08/13/2013 09:50 AM, Brian Paul wrote:
> On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
>>
>> --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
>> exiting
>>
> Well, that's not too helpful.
I think it may have been helpful.
Befor
On 08/12/2013 10:29 AM, Brian Paul wrote:
> Can you run with valgrind? That should give us some useful info if
> there's a use-after-free.
Sure,
$ valgrind /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkpython
"--enable-bt"
"/home/kevin/kitware/VTK_OSMesa_Build/Utilities/vtkTclTest2Py/rtImageTest.
On 08/09/2013 01:59 PM, Brian Paul wrote:
>
> That's probably not it, given the above. Can you try setting a
> breakpoint on pstip_destroy() and see if that's getting called before
> the segfault? If so, things are getting freed in the wrong order.
>
No, it is not called before the segfault.
On 08/09/2013 09:16 AM, Brian Paul wrote:
> On 08/07/2013 12:17 PM, Kevin H. Hobbs wrote:
>>
>> #0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
>> at draw/draw_pipe_pstipple.c:713
>>
> Hmm, I'd expect memcpy() of length zero to be fine even if src/d
One of the VTK tests (vtkFiltersHybridPython-largeImageOffset) makes
OSMesa segfault.
This is the top of the gdb backtrace :
#0 pstip_bind_sampler_states (pipe=, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
#1 0x7fffdf7580fc in cso_release_all (ctx=ctx@entry=0x15f1540) at
cso_cache/
On 07/17/2013 06:12 PM, Brian Paul wrote:
> On 07/17/2013 03:10 PM, Kevin H. Hobbs wrote:
>>
>> Can anybody give me a clue as to what's going on?
>
> My guess is your Fedora 18 system is missing some dependency that was
> previously found on your Fedora 17 system.
On 07/17/2013 06:12 PM, Brian Paul wrote:
> On 07/17/2013 03:10 PM, Kevin H. Hobbs wrote:
>>
>> Can anybody give me a clue as to what's going on?
>
> I'd try to compare Mesa config.log files from 17 vs. 18 to see what
> might be different. Or, just the outpu
I build Mesa with OSMesa from git source for testing VTK on two hosts with:
./autogen.sh \
--prefix=/home/kevin/mesa_nightly \
--enable-glx \
--enable-dri \
--enable-shared-glapi \
--enable-gallium-llvm \
--with-gallium-drivers=nouveau,swrast \
--enable-osmesa
When I used Fedora 17
vtkRenderingOpenGLCxx-TestTransformCoordinateUseDouble
looks like an llvmpipe issue:
OSMesa-9.1.1 offscreen pass
OSMesa-git softpipe pass
OSMesa-git llvmpipe fail
Mesa-9.1.1 softpipe pass
Mesa-9.1.1 nouveau pass
Mesa-9.1.1 llvmpipe fail
Mesa-git softpipe pass
Mesa-git no
Sure:
http://crab-lab.zool.ohiou.edu/kevin/vtkRenderingOpenGLCxxTests
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 03/13/2013 10:40 AM, Brian Paul wrote:
>
> Can you tell me what the parameters are for your OSMesaCreateContext()
> and OSMesaMakeCurrent() calls (in particular the image format/type)?
>
David Gobbi on the VTK developers list tells me these always look like :
contextId = OSMesaCreateContext
On 03/13/2013 10:40 AM, Brian Paul wrote:
>
> Can you tell me what the parameters are for your OSMesaCreateContext()
> and OSMesaMakeCurrent() calls (in particular the image format/type)?
I do not know. I'll do some digging into the VTK source and ask on the
VTK list.
>
> You could also try se
My tests of nightly VTK built against nightly OSMesa failed last
night.
The onscreen builds are fine.
The OSMesa build tests now fail with all black output but I
haven't found any error message to inform me of what's going on.
I know osmesa just switched to Gallium: that is reflected in
VTK's Lo
On 03/06/2013 01:54 AM, Michel Dänzer wrote:
> Actually, you asked for two different software renderers:
> --with-dri-drivers=swrast produces lib/swrast_dri.so based on classic
> swrast, --with-gallium-drivers=swrast produces lib/gallium/swrast_dri.so
> based on llvmpipe/softpipe.
>
> Presumably
On 03/05/2013 01:58 PM, Matt Turner wrote:
> On Tue, Mar 5, 2013 at 9:37 AM, Kevin H. Hobbs wrote:
>>
>> so now configure is giving me exactly what I asked for which is good :-)
>>
>> Unfortunately it isn't what I want :-( and the swrast driver gives me
>>
On 03/04/2013 01:32 PM, Matt Turner wrote:
>
> Committed. Thanks!
Before this change ( at least this is the most reasonable change from
last night ) I would configure mesa with :
./autogen.sh \
--prefix=/home/kevin/mesa_nightly \
--enable-glx \
--with-dri-drivers=swrast \
--with-gallium-
On 02/19/2013 09:51 AM, Brian Paul wrote:
>
> Looks like lines, in particular, are missing. I don't see any recent
> changes to swrast/osmesa that would seem to cause this.
>
There probably were none. I'm trying to track down long standing issues.
>
> 1. You do a git-bisect of mesa to find t
I have two machines {bubbles, murron} doing nightly dashboard builds of
VTK using nightly Mesa.
Each machine does a build of VTK using swrast and one with OSMesa.
Many tests pass on both machines when using OSMesa and fail on both
machines using swrast.
This is an example :
Test failing on bubb
On 12/10/2012 09:33 AM, Marek Olšák wrote:
> Type "git clean -fdX" before building Mesa.
Sometimes I hate git.
"make clean
git reset --hard
git clean -fd
git pull origin"
isn't enough because if the file was in .gitignore and not cleaned by
"make clean", then git clean ignored it.
I used to
gmake[5]: Entering directory `/home/kevin/mesa/src/glsl/builtin_compiler'
gmake[5]: *** No rule to make target
`../../../src/mesa/program/hash_table.c', needed by `hash_table.o'. Stop.
My mesa build has been failing here for the past few days.
The script that does the build is attached but the c
With shared GLAPI can Mesa be built so that I link the same application
to GL and OSMesa and get onscreen rendering (or even accelerated
rendering) rendering when I have DISPLAY set and OSMesa rendering when I
don't?
signature.asc
Description: OpenPGP digital signature
__
On 08/14/2012 06:59 PM, Matt Turner wrote:
>
> Ian says (and I agree) that shared-glapi doesn't make any sense for
> non-DRI configurations. So build with --disable-shared-glapi until I
> get a patch to disable it on Xlib/OSMesa/...
>
Thank you.
--disable-shared-glapi allows the build to procee
I just checked out mesa from git.
My system runs Fedora 17 x86_64.
I configured mesa with :
$ ./autogen.sh \
--prefix=/home/kevin/mesa_build/ \
--disable-dri \
--enable-glx \
--enable-xlib-glx \
--enable-osmesa \
--without-gallium-drivers
and built with :
$ make -ij8 && make
I get
On 02/08/2012 07:43 AM, Kenneth Graunke wrote:
> On 02/08/2012 04:28 AM, Kevin H. Hobbs wrote:
>>
>> configure: error: Package requirements (libdrm_radeon>= 2.4.31)
>> were not met:
>>
>
> Does it work if you add --with-gallium-drivers='' as well?
&
Config of the git repository fails because it can't find Radeon
libraries
This is despite the configure line being :
./autogen.sh \
--prefix=/home/kevin/mesa_xlib/ \
--disable-dri \
--enable-glx \
--enable-xlib-glx \
--disable-osmesa
checking for RADEON... no
configure: error: Package r
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
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
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
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 follow
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 following tests FAILE
On 01/30/2012 02:13 PM, Joshua Daniel Franklin (UW Seattle) wrote:
> On 1/27/12 12:28 PM, Kevin H. Hobbs wrote:
>> So you want to get OSMesa from Mesa-7.11.2 working with VTK-5.8.0 on
>> Fedora 15?
>
> So is it EGL that has trouble with offline rendering, since you did
>
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
&g
On 01/25/2012 05:20 PM, Jon TURNEY wrote:
>
> ... and reverting "always build shared glapi" didn't wrap this line above in
> ifeq ($(SHARED_GLAPI),1)/endif, since it wasn't there before.
>
>
> Sigh.
>
> I guess you could try the attached.
$ git apply
~/Download/0001-Don-t-try-to-link-OSMesa-w
So you want to get OSMesa from Mesa-7.11.2 working with VTK-5.8.0 on
Fedora 15?
You can do without the VTKData lines.
They don't add as many tests as I thought.
# Go somewhere to play around
cd /tmp
# get Mesa
wget ftp://ftp.freedesktop.org/pub/mesa/7.11.2/MesaLib-7.11.2.tar.bz2
# get VTK and
On 01/24/2012 06:11 PM, Joshua Daniel Franklin (UW Seattle) wrote:
> The application works fine with an X11
> DISPLAY using hardware GL but crashes when we try to use Mesa only. I
> decided to go to the very basic VTK_OPENGL_HAS_OSMESA
> OffScreenRendering.cxx example:
>
I will gladly help you,
On 01/25/2012 02:03 PM, Matt Turner wrote:
> On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs wrote:
>
> Maybe try reverting 4e5a8937d1a1bfb2a3bd067ed01e036728675fc2?
So this change is just the line
OSMESA_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB)
$(OSMESA_LIB_DEPS)
So I comme
On 01/25/2012 11:58 AM, Matt Turner wrote:
> On Wed, Jan 25, 2012 at 11:40 AM, Kevin H. Hobbs wrote:
>> My build of OSMesa from git is failing:
>>
>> ./autogen.sh \
>> --prefix=/home/kevin/mesa_osmesa/ \
>> --disable-dri \
>> --disable-glx \
>>
My build of OSMesa from git is failing:
./autogen.sh \
--prefix=/home/kevin/mesa_osmesa/ \
--disable-dri \
--disable-glx \
--enable-osmesa
/bin/sh ../../../../bin/mklib -o OSMesa -linker 'g++' -ldflags '' \
-major 8 -minor 0 -patch 0 \
-install ../../../../lib -cplusplus
On 01/20/2012 06:12 PM, Brian Paul wrote:
>
> $ glxinfo
> name of display: :0.0
> glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1:
> undefined symbol: u_tsd_set
>
My nightly builds of VTK and ParaView built with OSMesa or xlib OSMesa
are broken this way too.
Their mesa's are buil
On 11/07/2011 06:02 PM, Brian Paul wrote:
>
> No problem. I pushed the first glReadPixels patch. That should fix
> reads from regular windows (non-FBOs).
>
> -Brian
>
>
The OSMesa tests on the VTK and ParaView dashboards are still failing
with a solid color output image.
I've seen a lot of
On 11/07/2011 04:21 PM, Brian Paul wrote:
> As I posted on Friday, glReadPixels is broken. I have a patch that
> will probably fix most of this. I'll push it soon.
>
> -Brian
>
OK, I'm sorry for the noise.
I didn't make the connection at the time, though I should have
since I knew the VTK test
On 11/07/2011 03:29 PM, Kevin H. Hobbs wrote:
> I build Mesa OSMesa and xlib from git every night, and then I build and
> test VTK and ParaView against both Mesa libraries all of this on 9 hosts.
>
> Beginning Friday night basically all of the rendering tests started
> failing wit
On 11/07/2011 03:29 PM, Kevin H. Hobbs wrote:
> I build Mesa OSMesa and xlib from git every night, and then I build and
> test VTK and ParaView against both Mesa libraries all of this on 9 hosts.
>
> Beginning Friday night basically all of the rendering tests started
> failing wit
I build Mesa OSMesa and xlib from git every night, and then I build and
test VTK and ParaView against both Mesa libraries all of this on 9 hosts.
Beginning Friday night basically all of the rendering tests started
failing with a solid color on OSMesa and segfaulting with xlib.
I suspect Mesa beca
On 10/07/2011 12:10 PM, Kevin H. Hobbs wrote:
> On 10/07/2011 10:53 AM, Paul Gotzel wrote:
>> Brain,
>>
>> I'm using osmesa with VTK and in this particular test I'm rendering
>> just lines. The ratios stay the same for just triangles. Just for
>> these
On 10/07/2011 10:53 AM, Paul Gotzel wrote:
> Brain,
>
> I'm using osmesa with VTK and in this particular test I'm rendering
> just lines. The ratios stay the same for just triangles. Just for
> these simple primitives 7.11 seems to be about 4 times slower that
> 7.6.1.
These builds on the VTK d
On 10/26/2010 11:34 AM, Brian Paul wrote:
> Hmmm, can you try using an older version from git and see if it's a
> regression?
The problem exists in git tags:
mesa-7.9
mesa-7.8.2
mesa-7.8.1
mesa-7.8
mesa_7_7_1
mesa_7_6
mesa_7_5
and that's as far back as I can go with the same mesa and VTK
confi
I build VTK from git with Mesa from git every night.
mesa is built with :
./autogen.sh \
--prefix=/home/kevin/mesa_osmesa/ \
--with-driver=osmesa \
--disable-gallium
VTK is linked to OSMesa only and no other GL.
VTK's Charts-TestMultipleScalarsToColors test is segfaulting.
The backtrace
On 08/27/2010 05:34 PM, Jon TURNEY wrote:
> On 27/08/2010 21:40, Kevin H. Hobbs wrote:
>>
>
> Um. Sorry for the confusion, but there are two separate
> patches in this thread.
>
> Did you try the first patch "Add talloc to dependencies for
> libGL built with x
On 08/27/2010 02:45 PM, Jon TURNEY wrote:
>
> Updated patch attached.
No luck, I still get :
/home/kevin/mesa_xlib/lib/libGL.so: undefined reference to
`talloc_strdup'
and such when I link an application against libGL.so and there is
no talloc in the output of 'ldd libGL.so'.
sgall...@redhat.
On 08/24/2010 10:53 AM, tom fogal wrote:
> Brian Paul writes:
>>
>> One thing: was the issue with libGL + libOSMesa linking relevant to
>> the 7.8 branch? I don't remember.
>
> It was, but it was relevant to all branches. The solution I came to was
> that mangling would solve the immediate prob
When Mesa is built with :
./autogen.sh \
--prefix=/home/kevin/mesa_xlib/ \
--with-driver=xlib \
--disable-gallium \
--disable-gl-osmesa
The libGL.so that is produced has undefined symbols from talloc but
talloc is not linked.
$ nm mesa_xlib/lib/libGL.so | grep talloc
001ac4a0 T _
When I do :
./autogen.sh --with-driver=osmesa
make -j8
nm lib/libOSMesa.so | grep talloc
I get :
00160a30 T _ZN9glsl_type20init_talloc_type_ctxEv
00298220 r
_ZZN9glsl_type20init_talloc_type_ctxEvE19__PRETTY_FUNCTION__
U _talloc_array
U _tal
Mesa git started failing to configure early this week.
I ran
./autogen.sh \
--with-driver=xlib \
--disable-gallium
and configure complained about missing talloc.
I looked and saw that my fedora 12 machine has libtalloc installed but
libtalloc-devel was not installed, so I installed it.
Tha
On 08/12/2010 10:53 AM, tom fogal wrote:
> Can we go the other way? Put OSMesa symbols in libGL?
I gave this a successful try in the other thread. (Sorry for the
braiding of threads)
signature.asc
Description: OpenPGP digital signature
___
mesa-dev m
On 08/06/2010 05:20 PM, tom fogal wrote:
>
> Well, it does appear to be some type of symbol resolution/overloading
> issue. However it seems to be with internal Mesa symbols. Switching
> to a single library -- that is, putting OSMesaCreateContext, etc. into
> libGL directly, and getting rid of l
On 08/11/2010 11:55 PM, tom fogal wrote:
> Dan Nicholson writes:
> [snip]
>
>> So, sorry for not reading the whole thread, but is GL being linked
>> because it's needed by the app, because pkg-config said so, or
>> because the linker added it?
>>
> It's needed by the app. Not really, it's
On 08/11/2010 05:18 PM, tom fogal wrote:
> Right. This is exactly why Mesa's name mangling exists.
> You mean you haven't been mangling this whole time? I guess I haven't
> been reading these mails closely enough.
>
> -tom
>
It just seems perverse to have to use name mangling to deal with the
How is symbol visibility set up in mesa's shared objects?
When I do :
./autogen.sh --with-driver=xlib --disable-gallium --enable-debug
I get for example :
$ nm lib/libGL.so | grep glDepthFunc
0020ce30 T glDepthFunc
$ nm lib/libOSMesa.so | grep glDepthFunc
001ca760 T glDepthFunc
On 08/10/2010 04:44 PM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>>
>> VTK_USE_X:BOOL=ON is set the test segfaults.
>
> What does VTK_USE_X change/end up doing?
>
Most of the action seems to happen in Rendering/CMakeLists.txt where on
linux with VTK_USE_X=
On 08/10/2010 02:47 PM, Kevin H. Hobbs wrote:
>
> VTK_USE_X:BOOL=OFF
>
With VTK_USE_X:BOOL=OFF the test also passes with libGL.so and
libOSMesa.so switched that is
VTK_USE_X:BOOL=OFF
OPENGL_gl_LIBRARY:FILEPATH=/home/kevin/mesa/lib/libOSMesa.so
OSMESA_LIBRARY:FILEPATH=/home/kevin
On 08/06/2010 05:20 PM, tom fogal wrote:
> Well, it does appear to be some type of symbol resolution/overloading
> issue. However it seems to be with internal Mesa symbols. Switching
> to a single library -- that is, putting OSMesaCreateContext, etc. into
> libGL directly, and getting rid of libO
Although the backtrace after the segfault does not show other functions
between vtkOpenGLRenderWindow::OpenGLInit and vbo_exec_EvalCoord1fv I am
able to set a breakpoint at vtkOpenGLRenderWindow::OpenGLInit and step
through the program. I can see the execution moving through mesa
functions. I'm onl
On 08/06/2010 05:20 PM, tom fogal wrote:
>
> Yeah... hrm, I thought Dan's change got rid of that, but maybe I
> misunderstood it.
>
> Could you rm /tmp/mesa/lib64/libGL.so* before building VTK? My hunch
> is that VTK is linking it in anyway; maybe it stuck around in cmake's
> cache or something.
>
On 08/06/2010 03:15 PM, tom fogal wrote:
>
> If you could build VTK with just a single GL library -- i.e. with just
> libOSMesa or just libGL, but not both -- and could reproduce the crash,
> that would rule out my symbol collision theory. I am not sure how easy
> that is, though...
>
That was
On 08/06/2010 10:47 AM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>>
>> my git bisect script uses :
>>
>> make -j8 linux-x86-64-debug
>>
>> so -fvisibility=3Dhidden is not added to the command line of the
>> builds in the git bisection.
&
On 08/05/2010 06:50 PM, Brian Paul wrote:
>
> Kevin, you seem to have identified two potential commits that caused
> trouble:
>
> 91c37599f621a0ec498c0f0add14f16470ca852b
> and
> 36b3a8bd5a317ab297f44b19fd14c7e76ec2fc77
>
> You should go to the head of the Mesa git tree and then undo each of
> t
On 08/05/2010 06:30 PM, tom fogal wrote:
>
>
> Is your test multithreaded, by any chance?
>
I can't really answer this : it's VTK's test.
When I run the test in gdb it tells me :
[Thread debugging using libthread_db enabled]
and when I quit from gdb gdb warns me that :
A debugging session i
On 08/05/2010 07:07 PM, tom fogal wrote:
> Brian Paul writes:
> [snip]
>
>> My other hunch is something is duplicated in the libOSMesa and libGL
>> libraries that's causing things to blow up in general.
>>
> Do note that both of these issues are from the pre-"-fvisibility=hidden
> by defau
On 08/04/2010 05:58 PM, tom fogal wrote:
> If you can find the commit that started the trouble (using git bisect),
> that might shed some light.
>
With my script adjusted to only report when the test started segfaulting
git bisect reports :
91c37599f621a0ec498c0f0add14f16470ca852b is the first
On 08/04/2010 05:58 PM, tom fogal wrote:
>
> If you can find the commit that started the trouble (using git bisect),
> that might shed some light.
>
I ran :
git bisect start
git bisect bad
git bisect good mesa_7_6
git bisect run ~/kitware/os_bisect_script.sh
The os_bisect_script.sh s
On 08/04/2010 04:21 PM, tom fogal wrote:
>
> Can you try valgrind? Perhaps somehow the generated dispatch
> code is jumping into lalaland and somehow magically ends up in
> vbo_exec_EvalCoord1fv (pretty far-fetched, but I'm out of ideas
> here...).
>
valgrind suggested I add --leak-check=full
On 08/04/2010 04:21 PM, tom fogal wrote:
>
> I am not sure what is wrong here, but something is.
> vbo_exec_EvalCoord1fv and vbo_exec_EvalCoord1f are both static methods
> in that file... there is no way OpenGLInit could call them. They must
> be called automagically during OSMesaCreateContext or
On 08/04/2010 03:29 PM, tom fogal wrote:
>
> To workaround it, we tell VTK that the OpenGL library is OSMesa and the
> OSMesa library is libGL. I would test that the above workaround works
> (i.e. you're hitting the same issue I did) before filing a bug.
>
> -tom
>
With the the mesa libraries
On 08/04/2010 03:01 PM, tom fogal wrote:
>
> 3) Doesn't seem likely that ::OpenGLInit calls vbo_exec_EvalCoord1fv :)
> Are you missing debug symbols in Mesa? Could you get a stack trace w/
> full debug symbols?
>
The full gdb session with both mesa and VTK built with debug symbols is :
$ gdb
On 08/04/2010 03:01 PM, tom fogal wrote:
>
> No "--enable-gl-osmesa" ?
>
>
That's right I do not have "--enable-gl-osmesa". according to "configure
--help" this is on by default when the xlib driver is used.
> 1) Make sure you've got -fvisibility=hidden when you're building;
> the VBO code s
I'm looking into some segfaults in VTK's Offscreen tests.
These failures appeared about the time that I switched from building
mesa with the "make linux-x86-64" target and moved to buiulding mesa with :
./autogen.sh \
--with-driver=xlib \
--disable-gallium \
--without-demos
make
It was al
On 05/14/2010 10:58 AM, Brian Paul wrote:
> Kevin H. Hobbs wrote:
>>
>> 1. a build of Mesa where only libOSMesa.so is produced?
>>
>> 2. a build of Mesa where libGL.so and libOSMesa.so are produced but the
>> dynamic linker will need no symbols from libGL.so
On 05/14/2010 08:51 AM, Dan Nicholson wrote:
> On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs wrote:
>>
>> I tried it and it tests as well with VTK as any recent build.
>
> Thanks. Well, you and Tom use a standalone osmesa. The only distro I
> looked at (fedora) uses a
On 05/12/2010 02:21 PM, Dan Nicholson wrote:
>
>
> Yeah, but you also have to stop it from being linked to libGL. Here's
> what I'd try on master, although I have tested it. You'll have to rerun
> autogen.sh.
>
> Dan
>
I tried it and it tests as well with VTK as any recent build.
signature.
On 05/12/2010 11:45 AM, tom fogal wrote:
> That said, I think Dan's idea of linking directly to libmesa is an
> easier way to solve your problem.
>
Would that be done in :
src/mesa/drivers/osmesa/Makefile
by changing line 31 from
CORE_MESA =
to
CORE_MESA = $(TOP)/src/mesa/libmesa.a
?
On 05/12/2010 11:45 AM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>> Today, I plan to try to :
> [snip]
>> 2. Try surrounding the declarations of the hidden symbols needed by
>> OSMesa with "#pragma GCC visibility push(default)" and "#p
On 05/10/2010 04:48 PM, Dan Nicholson wrote:
>
> I guess this is because configure adds -fvisibility=hidden to the
> CFLAGS. Maybe we should always build osmesa against the internal
> static libraries instead of against libGL.
>
Today, I plan to try to :
1. Try a VTK test build against static M
On 05/10/2010 04:48 PM, Dan Nicholson wrote:
> On Mon, May 10, 2010 at 12:51 PM, Kevin H. Hobbs wrote:
>> The mesa/configs/linux-x86-64 target makes this symbol global while the
>> auto tools configuration makes this symbol local...
>
> I guess this is because configure add
On 05/10/2010 03:25 PM, Kevin H. Hobbs wrote:
>
>
> I really do not understand this missing symbol business since :
>
>
> $ nm mesa/lib/libGL.so | grep _mesa_free_context_data
> 00078030 t _mesa_free_context_data
>
> $ nm /opt/Mesa-7.8.1/lib64/libGL.so | g
On 05/10/2010 02:13 PM, Dan Nicholson wrote:
> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
>>
>> All I really want is Mesa with OSMesa from the development repository as
>> the "reference" library for my VTK and ParaView nightly test builds.
>
>
On 05/10/2010 11:56 AM, tom fogal wrote:
>
> I recommend you check out the "build_mesa" function in:
>
> http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit
>
> There's a lot we can do to make the whole VTK, Mesa/mangled or no,
> and VisIt/ParaView stack more amenable to compilatio
On 05/10/2010 09:46 AM, Brian Paul wrote:
>
> A 'make clean' may be needed. Sometimes when source files move around
> the 'depend' files don't get properly updated.
>
> -Brian
I get the same result after 'make clean' err.. at least the build fails
with :
make[5]: *** No rule to make target
`.
On 05/10/2010 08:45 AM, Chia-I Wu wrote:
>
> I could not reproduce it here on my AMD64 machine. Can you post the
> full mesa_build.txt?
>
The entire mesa_build.txt is here:
http://crab-lab.zool.ohiou.edu/kevin/mesa_build.txt
signature.asc
Description: OpenPGP digital signature
_
I run several nightly builds of VTK and ParaView with Mesa from the git
repository.
My builds for May 6 failed because Mesa failed to build.
Mesa is built with :
# Update Mesa
echo "Update Mesa"
cd /home/kevin/mesa
make realclean > ~/mesa_build.txt 2>&1
git pull origin > ~/mesa_update.txt 2>&1
m
96 matches
Mail list logo
