Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
Matt Ettus 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio 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. -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29619104.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On Fri, Sep 03, 2010 at 04:21:53PM -0700, Jack Ott wrote: Matt Ettus 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) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/04/2010 12:01 AM, Eric Blossom wrote: 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
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? -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29604761.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/02/2010 10: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? 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/02/2010 11:39 AM, Matt Ettus 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? How does this relate to the Direct Rendering Manager in the X server? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On Thu, Sep 2, 2010 at 5:53 PM, Marcus D. Leech mle...@ripnet.com wrote: On 09/02/2010 11:39 AM, Matt Ettus 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. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On Thu, Sep 2, 2010 at 08:39, Matt Ettus m...@ettus.com wrote: 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.) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
Marcus D. Leech wrote: On 09/02/2010 11:39 AM, Matt Ettus 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? How does this relate to the Direct Rendering Manager in the X server? Yes, the simplest way to tell is if I disable 3D acceleration through the driconf utility, after which glxgears becomes noticeably slower, it goes from displaying 60 vertically synched frames to 16. I also marked DRI in xorg.conf as false, yet in either case I get the exact same performance from GRC. On another note I forgot to mention that I already had the fft's refresh rate at 10Hz instead of the default 30. I just don't understand why GRC is the only program not leveraging the graphics card. I also stumbled upon this http://gnuradio.org/redmine/wiki/gnuradio/CompGrWxgui#Enable-the-GL-Sinks It talks in the bottom of the page about the Intel G965 chipset, since I have the mobile version GM965 I thought it might have something to do with this, but so far no luck. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29607093.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC's graphical sinks performance issues
Hi there, 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. Regards, -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29600609.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
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. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/02/2010 12:52 AM, Matt Ettus wrote: 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
