Re: [Discuss-gnuradio] GRC's graphical sinks performance issues

[Eric Blossom]

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