I would tend to agree, but if we do not outline what we require from manufacturers, we will never get it. I would seriously suggest writing a specification and submitting it to Intel, AMD, etc.
Regards, Mark McCarron > Date: Fri, 17 May 2013 18:04:37 +0200 > From: master.of.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 really convinced that multiple DMA transfers are always > faster than copying data using memcpy - at least if those DMA transfers > copy only a few kilobytes, as is the case with packets from network devices. > The fact that packets are of limited size is not really a problem of > current computing architectures - it's a consequence of having packet > networks. Of course, it would be nice if your hardware would be able to > actually stream data into your userland, that somehow has the (zero > overhead) capability to tell the hardware to send the next sample - but > in reality, hardware-to-cpu-transfers usually happen en block, and that > is just fine for most applications, since there is little use of having > samples one after another; therefore, some buffering is always necessary > (and will always be). > For the sake of adaptivity, hardware supplied data most probably won't > be written to copy device data to multiple RAM addresses, since the data > from the device usually needs some processing (hence the driver). > So in effect, in most imaginable cases a device will do a single > DMA transfer to RAM. > > Greetings, > Marcus > > _______________________________________________ > 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
