Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
The waterfall rate is exactly like the fft rate: a decimation is computed so that the actual rate of fft frames per second (from the log power fft block) is approximately the given fft rate. The reason for adding a new preference is that the CPU and graphics requirements are different for the waterfall plot, so it should have its own separate configurable rate. -Josh Eric Blossom wrote: On Fri, Aug 22, 2008 at 11:33:18AM -0700, Josh Blum wrote: I think we need another preference parameter for the "waterfall rate". It should not be the same rate as the fft rate. Howabout "waterfall_rate"? OK. What are the units, and how would it behave? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Fri, Aug 22, 2008 at 11:33:18AM -0700, Josh Blum wrote: > I think we need another preference parameter for the "waterfall rate". It > should not be the same rate as the fft rate. > > Howabout "waterfall_rate"? OK. What are the units, and how would it behave? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
I think we need another preference parameter for the "waterfall rate". It should not be the same rate as the fft rate. Howabout "waterfall_rate"? On Fri, Aug 22, 2008 at 11:27 AM, Eric Blossom <[EMAIL PROTECTED]> wrote: > On Fri, Aug 22, 2008 at 07:26:07PM +0200, Stefan Bruens wrote: > > On Monday 18 August 2008 18:04:23 Johnathan Corgan wrote: > > > On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> > wrote: > > > > 2) I think screen refresh (drawing times) is too high (on my system) > that > > > > leads to flickering. > > > > > > You can lower the frame rate from the default of 30 by adding the > > > following line(s) to your config.conf: > > > > > > [wxgui] > > > fft_rate=15 (...or whatever frame rate you want) > > > > > > This will work with either the old or the new sinks. > > > > Unfortunately, this is not the case - waterfallsink_gl.py uses > > DEFAULT_FRAME_RATE, which is set waterfall_window.py to the fixed value > of 30. > > It works if you make sure there's no #... following the 15. > I stumbled on to that one myself. > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Fri, Aug 22, 2008 at 07:26:07PM +0200, Stefan Bruens wrote: > On Monday 18 August 2008 18:04:23 Johnathan Corgan wrote: > > On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote: > > > 2) I think screen refresh (drawing times) is too high (on my system) that > > > leads to flickering. > > > > You can lower the frame rate from the default of 30 by adding the > > following line(s) to your config.conf: > > > > [wxgui] > > fft_rate=15 (...or whatever frame rate you want) > > > > This will work with either the old or the new sinks. > > Unfortunately, this is not the case - waterfallsink_gl.py uses > DEFAULT_FRAME_RATE, which is set waterfall_window.py to the fixed value of 30. It works if you make sure there's no #... following the 15. I stumbled on to that one myself. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Monday 18 August 2008 18:04:23 Johnathan Corgan wrote: > On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote: > > 2) I think screen refresh (drawing times) is too high (on my system) that > > leads to flickering. > > You can lower the frame rate from the default of 30 by adding the > following line(s) to your config.conf: > > [wxgui] > fft_rate=15 (...or whatever frame rate you want) > > This will work with either the old or the new sinks. Unfortunately, this is not the case - waterfallsink_gl.py uses DEFAULT_FRAME_RATE, which is set waterfall_window.py to the fixed value of 30. There is another problem with the frame rate, if it is decreased often enough, old_framerate*0.75 will yield 0, and this leads to various problems. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Tue, Aug 19, 2008 at 11:41 PM, Josh Blum <[EMAIL PROTECTED]> wrote: > The flickering issue is fixed in the trunk r9333. > > Certain machines defaulted to "single" buffering. Double buffering is now > explicitly enabled. > > cd gnuradio > cd gr-wxgui > svn up > sudo make install While this will mostly work for this particular case, in general is it not advised to only update a portion of the source code tree, as it leaves the working copy in an inconsistent state. The user's working copy might have been old enough that there were other, required changes in other parts of the tree that would have been needed. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
The flickering issue is fixed in the trunk r9333. Certain machines defaulted to "single" buffering. Double buffering is now explicitly enabled. cd gnuradio cd gr-wxgui svn up sudo make install -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Mon, Aug 18, 2008 at 1:22 PM, Eric Schneider
<[EMAIL PROTECTED]> wrote:
> I was bit by this as well. In my case I get the AttributeError error if
> config.conf is missing or has a typo ("type=nogl"). A present and correct
> config.conf works fine.
Okay, as of r9315 on the trunk, the type selection has been made more
robust. Right now, anything other than 'gl' (including mispellings)
or if the config file is missing forces the use of the old code.
This is a Python only change, so if you were on a very recent trunk
version, all you need to do is:
$ svn update
$ sudo make -C gr-wxgui install
This will just install the gr-wxgui component without having to do a full build.
--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
I was bit by this as well. In my case I get the AttributeError error if
config.conf is missing or has a typo ("type=nogl"). A present and correct
config.conf works fine.
-Original Message-
From: Johnathan Corgan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 10:04 AM
To: Firas A.
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope
displays in trunk
On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote:
> 2) I think screen refresh (drawing times) is too high (on my system) that
> leads to flickering.
You can lower the frame rate from the default of 30 by adding the
following line(s) to your config.conf:
[wxgui]
fft_rate=15 (...or whatever frame rate you want)
This will work with either the old or the new sinks.
> File "./usrp_fft.py", line 122, in __init__
>self.scope = fftsink2.fft_sink_c (panel, fft_size=1024,
> sample_rate=input_rate,
> AttributeError: 'module' object has no attribute 'fft_sink_c'
Please see if you can duplicate this problem. What directory were you
running 'usrp_fft.py' from?
> as mentioned in "README.gl", creating the file ~/.gnuradio/config.conf
> removed the error and everything was working fine in the second
usrp_fft.py
> shot.
Actually, if the config.conf is missing, the software just defaults to
the non-gl implementation, so this shouldn't have made a difference.
> I think this file should be creating automatically with the option
> style=gl (or at least style = auto)
Since this is still experimental code in the trunk, we default to not
using it until someone explicitly enables it. In release 3.2, it will
become the default unless GL support is missing, then will fall back
to using the non-GL version.
--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
Hi, > Johnathan Corgan wrote : > > What directory were you running 'usrp_fft.py' from? I was running from gr-utils/src/python/ Regards, Firas -- View this message in context: http://www.nabble.com/New-OpenGL-based-FFT%2C-Waterfall%2C-and-Scope-displays-in-trunk-tp18988013p19035634.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] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote: > 2) I think screen refresh (drawing times) is too high (on my system) that > leads to flickering. You can lower the frame rate from the default of 30 by adding the following line(s) to your config.conf: [wxgui] fft_rate=15 (...or whatever frame rate you want) This will work with either the old or the new sinks. > File "./usrp_fft.py", line 122, in __init__ >self.scope = fftsink2.fft_sink_c (panel, fft_size=1024, > sample_rate=input_rate, > AttributeError: 'module' object has no attribute 'fft_sink_c' Please see if you can duplicate this problem. What directory were you running 'usrp_fft.py' from? > as mentioned in "README.gl", creating the file ~/.gnuradio/config.conf > removed the error and everything was working fine in the second usrp_fft.py > shot. Actually, if the config.conf is missing, the software just defaults to the non-gl implementation, so this shouldn't have made a difference. > I think this file should be creating automatically with the option > style=gl (or at least style = auto) Since this is still experimental code in the trunk, we default to not using it until someone explicitly enables it. In release 3.2, it will become the default unless GL support is missing, then will fall back to using the non-GL version. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
Hi, 1) Great Work. 2) I think screen refresh (drawing times) is too high (on my system) that leads to flickering. 3) Compiling a fresh trunk copy (rev 9311) on my C2D running Ubuntu 8.04, the running of usrp_fft.py for the first time leads to the following error : File "./usrp_fft.py", line 306, in main () File "./usrp_fft.py", line 302, in main app = stdgui2.stdapp(app_top_block, "USRP FFT", nstatus=1) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in __init__ wx.App.__init__ (self, redirect=False) File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7836, in __init__ self._BootstrapApp() File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7433, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in OnInit frame = stdframe (self.top_block_maker, self.title, self._nstatus) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in __init__ self.panel = stdpanel (self, self, top_block_maker) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File "./usrp_fft.py", line 122, in __init__ self.scope = fftsink2.fft_sink_c (panel, fft_size=1024, sample_rate=input_rate, AttributeError: 'module' object has no attribute 'fft_sink_c' as mentioned in "README.gl", creating the file ~/.gnuradio/config.conf removed the error and everything was working fine in the second usrp_fft.py shot. I think this file should be creating automatically with the option style=gl (or at least style = auto) Best Regards, Firas -- View this message in context: http://www.nabble.com/New-OpenGL-based-FFT%2C-Waterfall%2C-and-Scope-displays-in-trunk-tp18988013p19030103.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] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
Rakesh Peter wrote: Hi Josh.. The CPU usage goes around 75% for the application when I goto the millisecond scales. Do take a look at the snapshot.. http://imagebin.ca/view/3ZJeY0.html I am thinking that this is probably a limitation of the graphics pipeline. The screen updates are too large and too frequent. I'm using an Intel G33 chipset with Linux AGPGart driver. Other applications like the video player VLC in OpenGL mode also seems to have the similar issue (?). So probably out of our hands ;) Probably, but I will take note. From dmesg output: [ 35.546210] Linux agpgart interface v0.102 [ 35.584679] agpgart: Detected an Intel G33 Chipset. [ 35.585409] agpgart: Detected 7164K stolen memory. [ 35.599048] agpgart: AGP aperture is 256M @ 0xd000 Btw, is it possible to give callbacks from the wxgui sink to the application, like click on waterfall to change center frequency ?? Not at the moment. The way we did this in the old fft sink was incompatible. This feature will be restored for future releases. Regards, rakesh On Sun, Aug 17, 2008 at 12:14 AM, Josh Blum <[EMAIL PROTECTED]> wrote: On Sat, Aug 16, 2008 at 4:03 AM, Rakesh Peter <[EMAIL PROTECTED]> wrote: Just tested the opengl implementation... Rocks hard ! Update times are really up on my C2D 2.4G E4600 / 2GB / Intel 82G33/G31 / Ubuntu Hardy. Had to do a "make clean" also, since it was reporting some top_block4dump error while running any GR code. Probably a lone case. In Ubuntu, you can get python-opengl bindings with "sudo apt-get install python-opengl". Some bugs (ticket #260): In Waterfall, I can go down the time scale till milliseconds updating, when the whole window freezes and I can't update the parameters anymore. Terminating the application seems to be the only way. With a smaller time scale, the waterfall must process FFT frames even faster. Most likely, the UI cannot respond because too much % CPU is taken for other processing. Can you report how much CPU usage when this freeze happens? Happened to notice some occasional frequent flickering with the windows in the background. The screenshot is attached. Also the FFT window (only the graph portion) becomes overlaid over other windows (right now, I can see it inside Firefox ;)) if it is not minimized. What kind of graphics card/driver version? http://imagebin.ca/view/6zuODeL6.html http://imagebin.ca/view/HIMraDE.html Indeed, thanks to Josh and team for the release... Regards, rakesh On Fri, Aug 15, 2008 at 12:51 AM, Johnathan Corgan < [EMAIL PROTECTED]> wrote: Josh Blum has implemented OpenGL-based versions of the FFT, waterfall, and scope sinks in gr-wxgui. These have been merged into the trunk as of revision 9291, and will be part of the 3.2 release. This feature available to those who have installed GNU Radio via a source code build from the GNU Radio trunk repository. You will not be able to use it if you are using the release tarballs, the release repository, or binary package installations. You will need to have OpenGL available for your graphics card, and have installed the python-opengl bindings. This is the default for many systems, but please see your distribution documentation for details. Currently, the new displays must be explicitly enabled in your GNU Radio preferences, though in release 3.2 they will become the default with fall back to the non-GL versions if GL is not available. Please see: http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl ...for details on how to enable. If you have written your own GNU Radio applications that use wxgui sinks, you will not have to make any changes to your source code for these. The existing Python scripts in gr-utils and gnuradio-examples will automatically take advantage of the new functionality if enabled. To obtain this new code, you will need to update your GNU Radio trunk distribution, and re-run the build: (From the top-level source code directory) $ svn update $ ./bootstrap $ ./configure (...whatever you might currently use...) $ make $ make check $ sudo make install We are looking for testers, to measure the difference in performance between the non-GL and GL versions, and in particular, the performance of the GL versions when using a non-accelerated host-based GL implementation like Mesa (without DRI). In particular, the waterfall implementation is a vast improvement over the existing one. Try usrp_fft.py -W to view. Thanks, Josh! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Sat, Aug 16, 2008 at 4:03 AM, Rakesh Peter <[EMAIL PROTECTED]> wrote: > Just tested the opengl implementation... Rocks hard ! Update times are > really up on my C2D 2.4G E4600 / 2GB / Intel 82G33/G31 / Ubuntu Hardy. > > Had to do a "make clean" also, since it was reporting some top_block4dump > error while running any GR code. Probably a lone case. In Ubuntu, you can > get python-opengl bindings with "sudo apt-get install python-opengl". > > Some bugs (ticket #260): > > In Waterfall, I can go down the time scale till milliseconds updating, when > the whole window freezes and I can't update the parameters anymore. > Terminating the application seems to be the only way. > With a smaller time scale, the waterfall must process FFT frames even faster. Most likely, the UI cannot respond because too much % CPU is taken for other processing. Can you report how much CPU usage when this freeze happens? > > Happened to notice some occasional frequent flickering with the windows in > the background. The screenshot is attached. Also the FFT window (only the > graph portion) becomes overlaid over other windows (right now, I can see it > inside Firefox ;)) if it is not minimized. > What kind of graphics card/driver version? > > http://imagebin.ca/view/6zuODeL6.html > http://imagebin.ca/view/HIMraDE.html > > Indeed, thanks to Josh and team for the release... > > Regards, > > rakesh > > > On Fri, Aug 15, 2008 at 12:51 AM, Johnathan Corgan < > [EMAIL PROTECTED]> wrote: > >> Josh Blum has implemented OpenGL-based versions of the FFT, waterfall, >> and scope sinks in gr-wxgui. These have been merged into the trunk as of >> revision 9291, and will be part of the 3.2 release. >> >> This feature available to those who have installed GNU Radio via a >> source code build from the GNU Radio trunk repository. You will not be >> able to use it if you are using the release tarballs, the release >> repository, or binary package installations. >> >> You will need to have OpenGL available for your graphics card, and have >> installed the python-opengl bindings. This is the default for many >> systems, but please see your distribution documentation for details. >> >> Currently, the new displays must be explicitly enabled in your GNU Radio >> preferences, though in release 3.2 they will become the default with >> fall back to the non-GL versions if GL is not available. Please see: >> >> http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl >> >> ...for details on how to enable. If you have written your own GNU Radio >> applications that use wxgui sinks, you will not have to make any changes >> to your source code for these. >> >> The existing Python scripts in gr-utils and gnuradio-examples will >> automatically take advantage of the new functionality if enabled. >> >> To obtain this new code, you will need to update your GNU Radio trunk >> distribution, and re-run the build: >> >> (From the top-level source code directory) >> >> $ svn update >> $ ./bootstrap >> $ ./configure (...whatever you might currently use...) >> $ make >> $ make check >> $ sudo make install >> >> We are looking for testers, to measure the difference in performance >> between the non-GL and GL versions, and in particular, the performance >> of the GL versions when using a non-accelerated host-based GL >> implementation like Mesa (without DRI). >> >> In particular, the waterfall implementation is a vast improvement over >> the existing one. Try usrp_fft.py -W to view. >> >> Thanks, Josh! >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
Just tested the opengl implementation... Rocks hard ! Update times are really up on my C2D 2.4G E4600 / 2GB / Intel 82G33/G31 / Ubuntu Hardy. Had to do a "make clean" also, since it was reporting some top_block4dump error while running any GR code. Probably a lone case. In Ubuntu, you can get python-opengl bindings with "sudo apt-get install python-opengl". Some bugs (ticket #260): In Waterfall, I can go down the time scale till milliseconds updating, when the whole window freezes and I can't update the parameters anymore. Terminating the application seems to be the only way. Happened to notice some occasional frequent flickering with the windows in the background. The screenshot is attached. Also the FFT window (only the graph portion) becomes overlaid over other windows (right now, I can see it inside Firefox ;)) if it is not minimized. http://imagebin.ca/view/6zuODeL6.html http://imagebin.ca/view/HIMraDE.html Indeed, thanks to Josh and team for the release... Regards, rakesh On Fri, Aug 15, 2008 at 12:51 AM, Johnathan Corgan < [EMAIL PROTECTED]> wrote: > Josh Blum has implemented OpenGL-based versions of the FFT, waterfall, > and scope sinks in gr-wxgui. These have been merged into the trunk as of > revision 9291, and will be part of the 3.2 release. > > This feature available to those who have installed GNU Radio via a > source code build from the GNU Radio trunk repository. You will not be > able to use it if you are using the release tarballs, the release > repository, or binary package installations. > > You will need to have OpenGL available for your graphics card, and have > installed the python-opengl bindings. This is the default for many > systems, but please see your distribution documentation for details. > > Currently, the new displays must be explicitly enabled in your GNU Radio > preferences, though in release 3.2 they will become the default with > fall back to the non-GL versions if GL is not available. Please see: > > http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl > > ...for details on how to enable. If you have written your own GNU Radio > applications that use wxgui sinks, you will not have to make any changes > to your source code for these. > > The existing Python scripts in gr-utils and gnuradio-examples will > automatically take advantage of the new functionality if enabled. > > To obtain this new code, you will need to update your GNU Radio trunk > distribution, and re-run the build: > > (From the top-level source code directory) > > $ svn update > $ ./bootstrap > $ ./configure (...whatever you might currently use...) > $ make > $ make check > $ sudo make install > > We are looking for testers, to measure the difference in performance > between the non-GL and GL versions, and in particular, the performance > of the GL versions when using a non-accelerated host-based GL > implementation like Mesa (without DRI). > > In particular, the waterfall implementation is a vast improvement over > the existing one. Try usrp_fft.py -W to view. > > Thanks, Josh! > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
Awesome. 1000% Performance improvement under OSX. Waterfall was completely unusable for me before. Thanks ksh. On Aug 14, 2008, at 9:21 PM, Johnathan Corgan wrote: Josh Blum has implemented OpenGL-based versions of the FFT, waterfall, and scope sinks in gr-wxgui. These have been merged into the trunk as of revision 9291, and will be part of the 3.2 release. This feature available to those who have installed GNU Radio via a source code build from the GNU Radio trunk repository. You will not be able to use it if you are using the release tarballs, the release repository, or binary package installations. You will need to have OpenGL available for your graphics card, and have installed the python-opengl bindings. This is the default for many systems, but please see your distribution documentation for details. Currently, the new displays must be explicitly enabled in your GNU Radio preferences, though in release 3.2 they will become the default with fall back to the non-GL versions if GL is not available. Please see: http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl ...for details on how to enable. If you have written your own GNU Radio applications that use wxgui sinks, you will not have to make any changes to your source code for these. The existing Python scripts in gr-utils and gnuradio-examples will automatically take advantage of the new functionality if enabled. To obtain this new code, you will need to update your GNU Radio trunk distribution, and re-run the build: (From the top-level source code directory) $ svn update $ ./bootstrap $ ./configure (...whatever you might currently use...) $ make $ make check $ sudo make install We are looking for testers, to measure the difference in performance between the non-GL and GL versions, and in particular, the performance of the GL versions when using a non-accelerated host-based GL implementation like Mesa (without DRI). In particular, the waterfall implementation is a vast improvement over the existing one. Try usrp_fft.py -W to view. Thanks, Josh! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio PGP.sig Description: This is a digitally signed message part ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
Quoting Johnathan Corgan <[EMAIL PROTECTED]>: We are looking for testers, to measure the difference in performance between the non-GL and GL versions, and in particular, the performance of the GL versions when using a non-accelerated host-based GL implementation like Mesa (without DRI). In particular, the waterfall implementation is a vast improvement over the existing one. Try usrp_fft.py -W to view. Thus far it's a great improvement in apparent response time and update speed. It "feels" faster. (Let me know how you want this quantified and I'll certainly try to do that.) One thing I've noticed, though it may just be this machine: If I resize usrp_fft.py too much, the GUI stops responding to user input, though the data display keeps running. (This is using rev 9293, on Ubuntu Gutsy.) usrp_oscope.py is apparently immune. That said, it's an amazing improvement on the current scope/spectrum analyzer. Thanks, Josh! Indeed, thanks a ton, Josh! --Mason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
