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, tryi
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
> >> wit
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 increa
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 Man
On Thu, Sep 2, 2010 at 08:39, Matt Ettus 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, lik
On Thu, Sep 2, 2010 at 5:53 PM, 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?
I know several ways tha
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
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 wh
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 50Ms
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
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
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
12 matches
Mail list logo
