- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Maybe I'm just unable to find it (but I have been browsing the manuals for an hour) but I can't seem to locate a function like ippiCopy_xx that works for overlapping RIOs. ippiCopy doesn't work if the memory areas overlap unless the delta x and delta y are both zero or negative.
It's quite common to want to move around an image within another one so I one such function must exist. It's like memcpy vs memmove. Can someone point me in the right direction?
Btw, am I suppost to post these things on the premier support site?
Cheers,
Mikael
Maybe I'm just unable to find it (but I have been browsing the manuals for an hour) but I can't seem to locate a function like ippiCopy_xx that works for overlapping RIOs. ippiCopy doesn't work if the memory areas overlap unless the delta x and delta y are both zero or negative.
It's quite common to want to move around an image within another one so I one such function must exist. It's like memcpy vs memmove. Can someone point me in the right direction?
Btw, am I suppost to post these things on the premier support site?
Cheers,
Mikael
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mikael,
no sense to submit simple 'how to' questions to premier support channel. That is what this forum stands for.
To copy overlapped memory regions you may need to use ippsMove function. We do not have 2D variant of this function, so youneed todo copy on row by row basis.
Regards,
Vladimir
no sense to submit simple 'how to' questions to premier support channel. That is what this forum stands for.
To copy overlapped memory regions you may need to use ippsMove function. We do not have 2D variant of this function, so youneed todo copy on row by row basis.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, then I know.
Isn't it a bit odd that a 2D version is missing? Especially since it is quite easy, and without performance implcations, to modify a normal copy to be overlap sensitive?
Anyway, thanks for the answer. And the otherwise very good lib!
Cheers,
Mikael
Isn't it a bit odd that a 2D version is missing? Especially since it is quite easy, and without performance implcations, to modify a normal copy to be overlap sensitive?
Anyway, thanks for the answer. And the otherwise very good lib!
Cheers,
Mikael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is performance implication if normal copy had to also support overlapped regions. That is why special functions implemented in C run time and in IPP libraries.
For 2D case you can just write a wrapper on top of ippsMove function and potentially even thread this with OpenMP. This will be very similar to what it may look like if implemented in IPP
Thanks for your feedback. Can I ask you what kind of applications you develop with IPP? What are the most important features of IPP from your prospective and what are the weak areas?
Regards,
Vladimir
For 2D case you can just write a wrapper on top of ippsMove function and potentially even thread this with OpenMP. This will be very similar to what it may look like if implemented in IPP
Thanks for your feedback. Can I ask you what kind of applications you develop with IPP? What are the most important features of IPP from your prospective and what are the weak areas?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
There is performance implication if normal copy had to also support overlapped regions. That is why special functions implemented in C run time and in IPP libraries.
For 2D case you can just write a wrapper on top of ippsMove function and potentially even thread this with OpenMP. This will be very similar to what it may look like if implemented in IPP
Thanks for your feedback. Can I ask you what kind of applications you develop with IPP? What are the most important features of IPP from your prospective and what are the weak areas?
Regards,
Vladimir
For 2D case you can just write a wrapper on top of ippsMove function and potentially even thread this with OpenMP. This will be very similar to what it may look like if implemented in IPP
Thanks for your feedback. Can I ask you what kind of applications you develop with IPP? What are the most important features of IPP from your prospective and what are the weak areas?
Regards,
Vladimir
Thanks Vladimir.
On my system memmove and memcpy seems to have the same speed. Actually you just iterate from the start or beginning depending on if the dest is before source or vice versa. Really simple unless you have some really funky optimizations (which you might have, I have no idea).
I have made such a wrapper. Speed is satisfactoy.
I am creating a VNC-like app with a very advanced codec. It is the high level parts that are advanced btw, and I am using IPP for parts of the codec. Mostly the Jpeg codec and some copy functionality.
I find the speed most satisfactory for the most part. I miss the Java way of documentation, but that is more a C/C++ problem.
The only performance problem I have found is in the function that swaps bytes in an int, essentially converting from lille- to big endian and back. My own function is much faster there (using bswap asm).
You should have a look at quicklz.com. It is an _extremely_ fast compressor/decompressor. Much much faster than anything you have I think. One problem is that if I compile it with ICC 11.1 and enable -parallel then it sucks upp all 4+4 cores on my Mac Pro i7 and performs 50% worse... Strange.
Keep up the good work!
Cheers,
Mikael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Mikael,
regarding quicklz speed - the key phrase I found on the link you provided I believe was: "Speed is favored over backwards compatibility"
It is always possible to simplify the things in favour of performance. But the next question is what customers will do with their already existed achives?
Regards,
Vladimir
regarding quicklz speed - the key phrase I found on the link you provided I believe was: "Speed is favored over backwards compatibility"
It is always possible to simplify the things in favour of performance. But the next question is what customers will do with their already existed achives?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Thanks Mikael,
regarding quicklz speed - the key phrase I found on the link you provided I believe was: "Speed is favored over backwards compatibility"
It is always possible to simplify the things in favour of performance. But the next question is what customers will do with their already existed achives?
Regards,
Vladimir
regarding quicklz speed - the key phrase I found on the link you provided I believe was: "Speed is favored over backwards compatibility"
It is always possible to simplify the things in favour of performance. But the next question is what customers will do with their already existed achives?
Regards,
Vladimir
True, but there are good use cases, like my codec which encode+decode on the other side in real time. I can always keep the two in sync version wise.
Cheers,
Mikael

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page