So your problem is you. I'm not saying you're doing anything wrong, just that if you need more performance. You need to do things differently than what you're doing now. So first off, the uio_pruss driver makes, or can make that memory location visible to userspace. I forget the exact sysfs file location, but it's there.
Secondly, and perhaps this is prefered. You could mmap() that memory location, read the data out, and dump it directly into a tmpfs file. The benefits of this is that you'll have mem to mem copy speeds, which once it hits the tmpfs any application you care to access this with, can. The second benefit to this, is that you mmap() that memory location, then you mmap() the tmpfs location, and it becomes a direct object to object copy ( a = b; ) type of situation. Or can be. On Tue, Apr 18, 2017 at 11:04 AM, <[email protected]> wrote: > The code is simple. I'm using PRU Linux Application Loader API. > <http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide> > > void main (void) > { > //pru initialization... > > u_int32_t ddrSizeInBytes = prussdrv_extmem_size(); > u_int32_t *sharedDdr; > prussdrv_map_extmem(&sharedDdr); > > u_int32_t* destination = new u_int32_t[76800]; //640*480*1 bytes > memcpy(sharedDdr, destination, sizeof(u_int32_t) * 76800); //takes > aprox 10-12 ms > > u_int32_t* localSource = new u_int32_t[76800]; > memcpy(localSource, destination, sizeof(u_int32_t) * 76800); //takes > aprox 0.5 - 1 ms > > //close pru... > } > > > > > On Tuesday, April 18, 2017 at 8:09:44 PM UTC+3, William Hermans wrote: > >> On Tue, Apr 18, 2017 at 4:38 AM, <[email protected]> wrote: >> >>> Hello, >>> I've encountered a problem with very slow reading speed from memory >>> allocated by pru kernel driver uio_pruss comparing to reading from usual >>> address spaces. Here is an performance tests on my Beagle Bone black: >>> >>> Average memcpy from pru DDR start address to application virtual address >>> (300 kB of data): 10.4781ms >>> Average cv::Mat.copyTo (300 kB of data): 11.0681ms >>> Average memcpy from one virtual address to another (300 kB of data): >>> 0.510001ms >>> >>> Kernel version is 4.4.12-bone11 >>> >>> Can somebody explain the issue? May be I should have used new pru rpmesg >>> rproc driver? >>> >> >> I do not think anyone would be able to answer this question properly >> without at least doing a code review of your code. Also you're not really >> giving enough information as to what exactly it is that you're doing it. So >> to me, your numbers and times make sense, but your qualifiers do not mean >> anything to me. >> >> You also need to be aware that memcopy() is notoriously slow . . . >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/0e74ffab-e482-4ff5-bba8-fb0a8d67a2aa%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/0e74ffab-e482-4ff5-bba8-fb0a8d67a2aa%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrrtnPLXO5yzdQD8uu5rE7MYUm5rrhiu2OL3uVPs-uemA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
