[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] GL sinks freeze

From: Josh Blum
Subject: Re: [Discuss-gnuradio] GL sinks freeze
Date: Sat, 26 Dec 2009 20:47:14 -0500
User-agent: Thunderbird (X11/20090817)

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.


Nick Foster wrote:
Looks like it's not letting go of a 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.


Date: Sat, 26 Dec 2009 17:04:36 -0500
From: address@hidden
To: address@hidden
CC: address@hidden
Subject: Re: [Discuss-gnuradio] GL sinks freeze

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).


Nick Foster wrote:
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,

Date: Tue, 22 Dec 2009 17:38:59 -0800
From: address@hidden
To: address@hidden
CC: address@hidden
Subject: Re: [Discuss-gnuradio] GL sinks freeze

Nick Foster 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: http://gnuradio.org/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.

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.

Hotmail: Powerful Free email with security by Microsoft.


Discuss-gnuradio mailing list
Hotmail: Free, trusted and rich email service.


Hotmail: Trusted email with Microsoft’s powerful SPAM protection.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]