Hi all,
I’m having some trouble with the OpenGL versions of the wxgui waterfall
and FFT sinks. I’m using r11659 (8/30/09). To test the sinks, I just
created a simple flowgraph with a 32ksps random stream (throttled)
feeding the sinks, similar to what the built-in test methods for the
sinks use.
The FFT sink freezes up after displaying a single frame in GL mode, and
never updates. It then locks up, using 100% CPU. The waterfall sink
doesn’t even load; it just loads an empty gray box and then freezes.
However, it doesn’t use any CPU time. Both sinks work fine in non-GL
mode. Interestingly, the GL versions of the scope sink and histogram
sink seem to work fine, so I don’t believe it to be an issue with my
graphics driver (nvidia kernel driver on Ubuntu Hardy).
Are there any known issues with the GL waterfall or FFT sinks? Has
anyone else encountered this issue? I’d like to use the extra
functionality the GL waterfall sink offers.
Thanks,
Nick
Nick F. wrote:
Hi all,
I’m having some trouble with the OpenGL versions of the wxgui waterfall and FFT sinks. I’m using r11659 (8/30/09). To test the sinks, I just created a simple flowgraph with a 32ksps random stream (throttled) feeding the sinks, similar to what the built-in test methods for the sinks use.
All the newest stuff is on git: GNU Radio cgit
For some reason we wont clear the svn stuff, probably to confuse
people…
The FFT sink freezes up after displaying a single frame in GL mode, and never updates. It then locks up, using 100% CPU. The waterfall sink doesn’t even load; it just loads an empty gray box and then freezes. However, it doesn’t use any CPU time. Both sinks work fine in non-GL mode. Interestingly, the GL versions of the scope sink and histogram sink seem to work fine, so I don’t believe it to be an issue with my graphics driver (nvidia kernel driver on Ubuntu Hardy).
The waterfall sink is making heavy use of textures and I could imagine
that having problems but… the scope and the fft are exercising the
exact same gl plotter base class. So I cannot fathom why the fft freezes
for you and the scope works.
The only thing that comes to mind is the update rate on the fft is
probably larger than the scopes. Not that the rate should be enough to
kill your cpu, but if the gl configuration has issues, that could
explain it.
You may try turning your ubuntu visual effects to off. They have been
known to mess up other applications that try to use gl.
Josh et al,
Thanks for the tip re: SVN vs Git. I thought the repositories were
linked – guess I didn’t look closely enough.
After installing the latest version via Git, the FFT sink appears to
work fine, as does everything else – except the waterfall sink. The
test case built into the main method of waterfallsink_gl.py gives me
the attached screenshot. CPU usage is 0%, and the GUI does not respond
to input. The color key shows 0dB all the way up and down the range, and
the main window of the waterfall display is black. The frequency axis is
marked correctly.
Using GRC to put together a simple flowgraph with a waterfall sink
produces the same result, when OpenGL is enabled (via
.gnuradio/config.conf). Non-GL waterfall works fine.
I’ve tried reinstalling/updating OpenGL, the nvidia kernel module,
python-opengl, numpy, and python-wxgtk (2.8). No change in behavior. I
tried disabling Ubuntu visual effects, with no change in behavior. Other
OpenGL applications and games work correctly on this machine (Thinkpad
T61p, Nvidia Quadro FX 570 GPU).
I don’t have any real experience debugging Python applications, or
OpenGL apps, for that matter. Using pdb reveals that the application
seems fine up until it calls app.MainLoop(), which I suppose is pretty
obvious. Then it locks up. How can I get started in finding the cause of
this behavior?
Thanks again,
Nick
Its probably something to do with texture handling, since thats the only
thing that makes the waterfall distinct from the other plotters. If you
care to mess with some python code, see the _draw_waterfall function in
gr-wxgui/src/python/plotter/waterfall_plotter.py Thats likely to be the
place where the trouble is. Perhaps something more portable could be
implemented (if that is the problem).
-Josh
Looks like it’s not letting go of a lock:
/home/bistromath/gnuradio-git/gr-wxgui/src/python/plotter/common.py(91)lock()
-> def lock(self): self._lock.acquire()
(Pdb) r
------freezes here, never returns------
It’s hard for me to really get a handle on it because from what I know
the Python debugger pdb doesn’t allow you to interrupt execution
interactively while the program is running, so I have to manually step
through until the program locks, and then look for what the last
instructions were. Best I can tell, the draw_waterfall function gets
called twice during init and that goes fine, and then the window gets
drawn, and I break on _on_paint() repeatedly (some hundred times or so).
Eventually both waterfall displays get drawn, and then the control
panel, and right after the control panel gets drawn, the program calls
lock(self) and then never returns from it.
Does that help any? Sounds like something’s not letting go of that lock,
since Python’s threading system holds _lock.acquire() in block until the
existing lock is released.
I’ll keep looking to try to narrow it down some. Do you know how I can
set up pdb to trigger a breakpoint if lock() blocks for more than a
second or so? If I could just break somewhere inside that condition, I
could get a stack trace and tell you exactly where it’s failing for me.
–n
I just checked, and Im having the same problem on my laptop. It used to
work before the upgrade to ubuntu 9.10. Something changed…
I will be looking into this too.
-Josh
Thanks Josh – ended up finding the same thing right around the same
time. =) Wonder why Python wouldn’t print the error message to stderr.
The diff fixes the problem for me as well. I’ll take a look at switching
back to using numpy.choose, although the for loop seems to work fine for
now.
–n
I fixed it on my computer, it seems numpy.choose changed implementation
since the upgrade to 9.10 (or maybe i was misusing it). I replaced the
numpy.choose call with a python for loop. Its probably slower than a
numpy table look up. But lets just see if this also fixes the problem
for you.
It seems the gnuradio.org server is on vacation again. Attached is the
diff, try it out.
-Josh
I put the fix on a branch “fix/waterfall” at
http://gnuradio.org/git/jblum.git
I also wonder why it did not throw an error: one of the calling methods
must
have a try/except block, but I couldn’t find it.
I put my own try/except in to print out the error. Its seems that the
more
recent implementation of numpy.choose only handles lookups into tables
that
are between size 2 and 32.
-Josh