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
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, espe
13 matches
Mail list logo
