Matt, My area of research is DSP and massive parallelism. Given the structure of GNU Radio, it is possible to know what data is required upfront. This opens up the possibility of a performance boost. I know how GNURadio works, it was discussed earlier when I raised this question.
There is a different way though. Lets assume we have two branches coming from the source. The first is going to an FFT, the second to some form of flow-graph that performs functions on the IQ stream. Also, we don't want the changes we make to the IQ stream to be reflected in the FFT. Now, we can approach this several ways: 1. Serial - Send the data first to FFT, then to the second portion of the flow-graph. 2. Parallel (memcopy) - Copy the data in memory, provide one to the FFT and the other to the IQ flow-graph. 3. Parallel (DMA/Driver) - Driver duplicates the data in memory according to the needs of the program. This is not a memcopy, but a true parallel creation as the stream is extracted from the wire. The last approach allows us to lighten the load on the application and CPU by off-loading initial memory allocation to DMA controllers. This way, we don't need to manage FIFO streams within the app in relation to the initial input. As I said, I am still checking if this is possible, but when working with multiple branches that require independent copies of the data this would be best performing way to deliver the data. 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 it is better to always make copies of the data rather than just make copies when you need them? In any case, I think you misunderstand both how GNU Radio works and how UHD interacts with it. UHD provides a single copy of data to GNU Radio for two reasons -- first, that is the most efficient thing to do, and second, UHD can't possibly know what GNU Radio plans to do with the data. GNU Radio passes pointers of the data to every block that needs it. Blocks are not allowed to modify their inputs, only their outputs. This is fundamental to how GNU Radio operates. Matt On Thu, May 16, 2013 at 9:02 PM, Mark McCarron <mark.mccar...@live.co.uk> wrote: There is a performance issue with this. If your program needs to manipulate the raw data, but at the same time provide that raw data to another branch(es), a copy much be made. If this is the case, then it would make more sense to duplicate the data in parallel as it enters the system. This 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 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 <mark.mccar...@live.co.uk> wrote: 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 stream, which is then copied by the application? Or does it create two copies of the stream and allow each branch of the flow-graph to manipulate the data via pointers? I'm digging into DMA to see if this is possible, I would be surprised if there was a limitation here. Regards, Mark McCarron _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
