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
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 with a solid color
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 with a solid color
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 tests
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
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 simple primitives 7.11 seems to be about 4 times
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
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 the
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 \
On 03/05/2013 01:58 PM, Matt Turner wrote:
On Tue, Mar 5, 2013 at 9:37 AM, Kevin H. Hobbs hob...@ohio.edu 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
more vtk test errors than
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 both
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
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
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
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
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
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 output from running ./configure on each.
Thank
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.
I'd try to compare Mesa config.log
One of the VTK tests (vtkFiltersHybridPython-largeImageOffset) makes
OSMesa segfault.
This is the top of the gdb backtrace :
#0 pstip_bind_sampler_states (pipe=optimized out, num=0, sampler=0x0)
at draw/draw_pipe_pstipple.c:713
#1 0x7fffdf7580fc in cso_release_all (ctx=ctx@entry=0x15f1540)
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=optimized out, 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/dst were
null.
memcpy is fine
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.
We
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.py
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.
Before Valgrind crashed it mentions
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
Well, that's not too helpful.
Ha! I can move the segfault all
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_ATTACHMENT_FRONT_LEFT) at osmesa.c
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 halves of the address are the
same.
I believe
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 OSMesa would
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
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 use
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 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 compilation /
On 05/10/2010 02:13 PM, Dan Nicholson wrote:
On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs hob...@ohiou.edu 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.
./configure --with-driver=xlib
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 | grep _mesa_free_context_data
On 05/10/2010 04:48 PM, Dan Nicholson wrote:
On Mon, May 10, 2010 at 12:51 PM, Kevin H. Hobbs hob...@ohiou.edu 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 adds
On 05/14/2010 08:51 AM, Dan Nicholson wrote:
On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs hob...@ohiou.edu 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 standalone osmesa
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 in order to load
libOSMesa.so?
3. a build
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 seems to
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 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 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 which
On 08/05/2010 07:07 PM, tom fogal wrote:
Brian Paul bri...@vmware.com 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
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
those
On 08/06/2010 10:47 AM, tom fogal wrote:
Kevin H. Hobbs hob...@ohiou.edu 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.
Oh. Can you add it into your bisect script and try
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.
I
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
On 08/10/2010 04:44 PM, tom fogal wrote:
Kevin H. Hobbs hob...@ohiou.edu 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 :
vtkXGPUInfoList.cxx
On 08/11/2010 11:55 PM, tom fogal wrote:
Dan Nicholson dbn.li...@gmail.com 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
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
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.
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
On 08/24/2010 10:53 AM, tom fogal wrote:
Brian Paul bri...@vmware.com 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
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'.
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 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 built
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/25/2012 11:58 AM, Matt Turner wrote:
On Wed, Jan 25, 2012 at 11:40 AM, Kevin H. Hobbs hob...@ohio.edu wrote:
My build of OSMesa from git is failing:
./autogen.sh \
--prefix=/home/kevin/mesa_osmesa/ \
--disable-dri \
--disable-glx \
--enable-osmesa
Unrelated (related to another
On 01/25/2012 02:03 PM, Matt Turner wrote:
On Wed, Jan 25, 2012 at 1:42 PM, Kevin H. Hobbs hob...@ohio.edu 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
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, but
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/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
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
--disable-egl?
No. it's just
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 FAILED:
146
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:
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
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
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?
It does.
It also looks like --with-gallium-drivers
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 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 proceed.
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
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 GL threads are
70 matches
Mail list logo
