On Fri, Oct 21, 2011 at 4:52 PM, Ben Hilburn <b...@ettus.com
<mailto:b...@ettus.com>> wrote:
If I don't use OpenGL, the persistence feature works just fine.
Has anyone else seen this error before?
My setup:
linux; GNU C++ version 4.6.1 20110819 (prerelease); Boost_104700;
UHD_003.003.000-13899cd
Python 2.7
GNURadio next branch, commit: 882089131a00da24
python-opengl 3.0.1-2
Cheers,
Ben
<sarcasm> What? Problems with OpenGL in GNU Radio? Nope, never heard
of that before </sarcasm>
Not sure if I've heard that particular problem, but there have been
other reports of OpenGL issues. They can often be OS and hardware
specific, so it's been really hard to work out these problems.
Tom
OpenGL has turned over the years from a pretty-nice hardware-abstraction
layer (but which takes advantage of whatever hardware
accelerations are available for rendering 3D objects) into a rancid,
festering, pile of horse leavings. It misbehaves randomly, depending
on which hardware you happen to have, and only really-recent
gee-whizz 400-core GPU cards seem to be really supported by the
latest OpenGL code, while support for older cards (like, you know,
last week's) tends to decay rapidly.
However, until we have a better choice for graphical "goop" in Gnu
Radio, we're rather stuck with the underlying WxPython objects which
uses OpenGL rendering for some of our graphical stuff (although,
there's no real reason to--we don't have the kinds of performance
demands that would require OpenGL hardware-assisted rendering, you
hardly need that for an FFT display that updates only a few
times per second, and has simple 2D imagery in it).
Try doing this before you start your application, does it help?
LIBGL_ALWAYS_INDIRECT=1
export LIBGL_ALWAYS_INDIRECT
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio