I’m having trouble getting hardware acceleration to work with grc’s
graphical sinks. With the regular sinks the refresh rate is always
choppy
and sluggish until it eventually locks up completely. And when I tried
the
OpenGL sinks it turned out they’re even slower than the regulars,
especially
the FFT Sink in which even the buttons can’t be pressed with most my
configurations, though I have to mention that with the OpenGL version
the
waveform in the middle of the sink’s window is drawn fine, it’s just
that
the buttons are unclickable. That’s when I figured it’s a graphics issue
and
not due to the cpu. All the other graphically intensive programs work
fine
on this machine, so I know I got the driver properly configured.
Anyone having the same issues?
Any help is appreciated
P.S. - My configuration: I’m using the latest gnuradio source code along
with a USRP2 and a WBX board, decimation is at 4, the FFT Sink’s bin
size is
set at 2048 and its sampling rate is at 1,000,000. The computer is a
Thinkpad X61s with a Core2Duo 1.6GHz processor and an Intel GM965
graphics
controller.
P.S. - My configuration: I’m using the latest gnuradio source code along
with a USRP2 and a WBX board, decimation is at 4, the FFT Sink’s bin size is
set at 2048 and its sampling rate is at 1,000,000. The computer is a
Thinkpad X61s with a Core2Duo 1.6GHz processor and an Intel GM965 graphics
controller.
This is where your problem is. If you are using decimation of 4 then
you are sending 25 million samples per second to the display. However,
you are telling it that its sample rate is 1 Million. Thus you are
giving it 25 times as many samples per second as it expects. Tell it to
expect 25 MS/s and you won’t have any problem.
This is where your problem is. If you are using decimation of 4 then
you are sending 25 million samples per second to the display.
However, you are telling it that its sample rate is 1 Million. Thus
you are giving it 25 times as many samples per second as it expects.
Tell it to expect 25 MS/s and you won’t have any problem.
Matt
25Msps with a 1.6GHz CPU, with default FFT display update rate? Aint
gonna happen, in my experience.
Smaller bandwidth, lower FFT update rate (5Hz, instead of the default
which is much higher).
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
The strange thing is that when the fft’s sample rate is at 25Msps which
equals the USRP’s bandwidth at a decimation of 4 everything works fine
with
the regular fft sink yet not with the OpenGL one. However when I
increase
the fft’s sample rate to 50Msps which is 2x the USRP’s bandwidth both
sinks
work fine. What does this mean?
I’m really convinced all this is because graphics are rendered strictly
through software. Does GRC even support graphics hardware acceleration?
how
do I configure it?
The strange thing is that when the fft’s sample rate is at 25Msps which
equals the USRP’s bandwidth at a decimation of 4 everything works fine with
the regular fft sink yet not with the OpenGL one. However when I increase
the fft’s sample rate to 50Msps which is 2x the USRP’s bandwidth both sinks
work fine. What does this mean?
I’m really convinced all this is because graphics are rendered strictly
through software. Does GRC even support graphics hardware acceleration? how
do I configure it?
The application has very little control over such things.
The X server implementation is responsible for dealing with hardware
acceleration, I think via
something called the “Direct Rendering Manager”. OpenGL will take
advantage of that, if
it’s an available option in your X server.
I’d try changing the update rate in your FFT window–change the “Refresh
Rate” parameter in your
FFT window from the default of “30” to 5 and see if that makes a
difference. I’m betting that it
will.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Thu, Sep 2, 2010 at 5:53 PM, Marcus D. Leech [email protected]
wrote:
On 09/02/2010 11:39 AM, Matt E. wrote:
If you have unaccelerated OpenGL, then the OpenGL version will be
unacceptably slow.
Matt
Any idea how you tell if your OpenGL is accelerated or not?
I know several ways that work for me:
Try executing glxinfo or glxgears. I can only execute them if I have
3D acceleration enabled.
If you are using Gnome desktop or something similar, you can try to
enable “Desktop effects” - they wont work either without 3d
acceleration.
With ATI and Nvidia based cards it is rather easy to tell because 3D
acceleration is only available with the proprietary drivers and you
can not (or should not be able to) install them by accident. They also
provide some configuration and diagnostic tools that should be
accessible from the menus.
I think you are missing the point here. There is no need to lie to the
program. If you are sending the FFT sink 25 MS/s, then tell it you are
sending it 25 MS/s. If you give it a different rate you will have all sorts
of other issues, like incorrect frequency scales on the display. If you want
to decrease the processor load then reduce the display update rate.
Just to elaborate a bit on this.
The FFT sink in GNU Radio incorporates time domain frame decimation
via the “keep one in n” block. The sample stream input to the sink is
divided into frames at the configured FFT size (1024 samples by
default in GRC). Then, only one frame per “n” is forwarded out to the
FFT block, with “n” being calculated as the sample rate divided by the
display update rate, then divided by the FFT size. In this way, we
only burden the CPU with the windowing/FFT/log power calculation and
graphics rendering as many times as is needed to refresh the display
at the requested rate (which are still all using fast C++ code, not
Python.)
The “sample rate” parameter to the FFT sink is not a control input.
You are simply telling the flowgraph the correct numerical time base
of the input sample stream, to be used in the above calculation. The
sample rate itself is usually established elsewhere; in this case, by
the upstream USRP2 source block’s decimation parameter. The “sample
rate” parameter is also used to correctly display the units on the
x-axis of the FFT window.
Thus, the proper way to control the CPU usage of the FFT sink is to
vary the update rate, as was mentioned by Matt and others. If in fact
you are CPU-bound, then “lying” to the FFT sink by giving it an
artificially high, incorrect sample rate will have the side effect of
increasing the time frame decimation, thus lowering the CPU load, and
appearing to “cure” the problem. But the x-axis units/scale will be
incorrect and the update rate won’t match the requested rate.
(None of this speaks to whether your system’s OpenGL/video card
combination is properly functioning or whether it results in a
performance improvement over the non-GL version of the sink.)
The strange thing is that when the fft’s sample rate is at 25Msps which
equals the USRP’s bandwidth at a decimation of 4 everything works fine
with
the regular fft sink yet not with the OpenGL one. However when I increase
the fft’s sample rate to 50Msps which is 2x the USRP’s bandwidth both
sinks
work fine. What does this mean?
I’m really convinced all this is because graphics are rendered strictly
through software. Does GRC even support graphics hardware acceleration?
how
do I configure it?
Jack,
I think you are missing the point here. There is no need to lie to the
program. If you are sending the FFT sink 25 MS/s, then tell it you are
sending it 25 MS/s. If you give it a different rate you will have all
sorts of other issues, like incorrect frequency scales on the display.
If you want to decrease the processor load then reduce the display
update rate.
If you have unaccelerated OpenGL, then the OpenGL version will be
unacceptably slow.
Thanks for pointing that out, I was wondering why the scales were acting
up.
Anyway, am setting up a fresh OS in a couple of days on a different
machine,
hopefully then I’ll be able to pinpoint where I’ve gone wrong.
On Fri, Sep 03, 2010 at 04:21:53PM -0700, Jack Ott wrote:
Matt E. wrote:
On 09/02/2010 07:09 AM, Jack Ott wrote:
The strange thing is that when the fft’s sample rate is at 25Msps which
equals the USRP’s bandwidth at a decimation of 4 everything works fine
with
the regular fft sink yet not with the OpenGL one. However when I increase
the fft’s sample rate to 50Msps which is 2x the USRP’s bandwidth both
sinks
work fine. What does this mean?
I’m really convinced all this is because graphics are rendered strictly
through software. Does GRC even support graphics hardware acceleration?
how
do I configure it?
Jack,
I think you are missing the point here. There is no need to lie to the
program. If you are sending the FFT sink 25 MS/s, then tell it you are
sending it 25 MS/s. If you give it a different rate you will have all
sorts of other issues, like incorrect frequency scales on the display.
If you want to decrease the processor load then reduce the display
update rate.
If you have unaccelerated OpenGL, then the OpenGL version will be
unacceptably slow.
Matt
Thanks for pointing that out, I was wondering why the scales were acting up.
Anyway, am setting up a fresh OS in a couple of days on a different machine,
hopefully then I’ll be able to pinpoint where I’ve gone wrong.
Thanks everyone.
FWIW, independent of GNU Radio, I’ve found that OpenGL support in
Linux still leaves a lot to be desired in the performance and
reliability departments. (Spoken as someone who’s recently tried high
performance cards from both Nvidia and ATI, trying both the
proprietary and open source drivers for each one… on Fedora 13)
The strange thing is that when the fft’s sample rate is at 25Msps which
equals the USRP’s bandwidth at a decimation of 4 everything works fine with
the regular fft sink yet not with the OpenGL one. However when I increase
the fft’s sample rate to 50Msps which is 2x the USRP’s bandwidth both sinks
work fine. What does this mean?
I’m really convinced all this is because graphics are rendered strictly
through software. Does GRC even support graphics hardware acceleration? how
do I configure it?
Jack,
I think you are missing the point here. There is no need to lie to the
program. If you are sending the FFT sink 25 MS/s, then tell it you are
sending it 25 MS/s. If you give it a different rate you will have all
sorts of other issues, like incorrect frequency scales on the display.
If you want to decrease the processor load then reduce the display
update rate.
If you have unaccelerated OpenGL, then the OpenGL version will be
unacceptably slow.
FWIW, independent of GNU Radio, I’ve found that OpenGL support in
Linux still leaves a lot to be desired in the performance and
reliability departments. (Spoken as someone who’s recently tried high
performance cards from both Nvidia and ATI, trying both the
proprietary and open source drivers for each one… on Fedora 13)
Eric
I have a system upon which none of the Gnu Radio apps that include
OpenGL “stuff” will work at all, producing
an almighty core dump from inside some Python gtk2 module. Even when
I set “LIBGL_ALWAYS_INDIRECT=1”.
That’s for identical F12 installations, Gnu Radio installations, etc,
etc. Only difference is the video card. And if I
turn off OpenGL, things work. But curiously enough the little OpenGL
test app, glxgears, works flawlessly (of course!).
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.