McCarron
Date: Fri, 17 May 2013 22:35:25 +0200
Subject: Re: [Discuss-gnuradio] Question about UHD driver
From: master.of.knowle...@gmail.com
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
Hi Mark,
I wasn't assuming you didn't know what a driver is - I was just hoping you'd
part in scheduling, but the data goes from the device into memory and
> a pointer is returned. The FIFO buffer in an app makes use of this pointer.
>
> Regards,
>
> Mark McCarron
>
> ----------
> Date: Fri, 17 May 2013 20:23:34 +0200
>
> Subject:
into memory and a pointer is
returned. The FIFO buffer in an app makes use of this pointer.
Regards,
Mark McCarron
Date: Fri, 17 May 2013 20:23:34 +0200
Subject: Re: [Discuss-gnuradio] Question about UHD driver
From: master.of.knowle...@gmail.com
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio
> The ideal scenario is to never copy data and it is achievable, to a
degree, through proper planning.
I have to strongly disagree with that.
You have to realize what a /driver/ is. And why it is needed:
A driver takes whatever ressources a piece of hardware offers and makes
these ressources usable
better to copy than to have a pointer.
I can't agree with that.
Regards,
Mark McCarron
From: johnat...@corganlabs.com
Date: Fri, 17 May 2013 10:06:08 -0700
Subject: Re: [Discuss-gnuradio] Question about UHD driver
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
On Fri, May 17, 20
On Fri, May 17, 2013 at 9:55 AM, Mark McCarron wrote:
> In order to support massive parallelism, data must be duplicated as it
> comes of the wire and into memory. Not duplicated in FIFO streams in an
> application.
>
There is no duplication of buffer contents in GNU Radio.
To elaborate on wha
I think you are missing the point. In order to support massive
parallelism, data must be duplicated as it comes of the wire and into
memory. Not duplicated in FIFO streams in an application. The latter
is a software implementation of a hardware task and is consuming
resources.
It requires
hardware and architecture changes to implement properly.
Regards,
Mark McCarron
> Date: Fri, 17 May 2013 18:44:51 +0200
> From: master.of.knowle...@gmail.com
> To: mark.mccar...@live.co.uk
> Subject: Re: [Discuss-gnuradio] Question about UHD driver
>
> > I would tend to ag
knowle...@gmail.com
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Question about UHD driver
>
> Hi Mark,
>
> as interesting as your point is, that's not something that
> can be fixed within the scope of GNU Radio or even UHD...
>
> Anyhow, I'm not r
Hi Mark,
as interesting as your point is, that's not something that
can be fixed within the scope of GNU Radio or even UHD...
Anyhow, I'm not really convinced that multiple DMA transfers are always
faster than copying data using memcpy - at least if those DMA transfers
copy only a few kilobyte
Marcus,
I have been running into that issue as well. It seems that we are in
a transition period with the introduction of multi-core processors and
OpenCL. Bus design has not been modified to cope with the parallel
duplication of data from high speed serial streams.
The problem is that most
defined solutions more cost effective.
Regards,
Mark McCarron
> Date: Fri, 17 May 2013 16:53:07 +0200
> From: master.of.knowle...@gmail.com
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Question about UHD driver
>
> Hi Mark,
>
> for currently availab
Regards,
Mark McCarron
From: m...@ettus.com
Date: Thu, 16 May 2013 21:11:42 -0700
Subject: Re: [Discuss-gnuradio] Question about UHD driver
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
Are you saying that
n
From: m...@ettus.com
Date: Thu, 16 May 2013 21:11:42 -0700
Subject: Re: [Discuss-gnuradio] Question about UHD driver
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
Are you saying that it is better to always make copies of the data rather than
just make copies when you need them?
In any case, I
ate: Thu, 16 May 2013 20:51:32 -0700
> Subject: Re: [Discuss-gnuradio] Question about UHD driver
> To: mark.mccar...@live.co.uk
> CC: discuss-gnuradio@gnu.org
>
>
>
> There is no need to create multiple copies. The consuming blocks are each
> given a pointer to the same data,
should be more
efficient than memcopy.
I am looking into DMA to see if this is possible.
Regards,
Mark McCarron
From: m...@ettus.com
Date: Thu, 16 May 2013 20:51:32 -0700
Subject: Re: [Discuss-gnuradio] Question about UHD driver
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
There
On 16 May 2013 23:51, Matt Ettus wrote:
> There is no need to
create multiple copies. The consuming blocks are each given a pointer to
the same data, and the memory is not freed until all the consuming
blocks indicate they are done with it.
>
> Matt
Also, the "contract"
that work functions
There is no need to create multiple copies. The consuming blocks are each
given a pointer to the same data, and the memory is not freed until all the
consuming blocks indicate they are done with it.
Matt
On Thu, May 16, 2013 at 11:00 AM, Mark McCarron wrote:
> I am wondering if the UHD driver
I am wondering if the UHD driver has the ability to create multiple
copies of the stream in memory???
Let's say I have a flow-graph that has two branches, the first pushes
complex data to an FFT, whereas the second demodulates a portion of
that data into AM.
Does the driver supply a single s
I am wondering if the UHD driver has the ability to create multiple copies of
the stream in memory???
Let's say I have a flow-graph that has two branches, the first pushes complex
data to an FFT, whereas the second demodulates a portion of that data into AM.
Does the driver supply a single stre
20 matches
Mail list logo
