- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
could you please describe the problem in more details here? So our expert may take a look on this.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
could you please describe the problem in more details here? So our expert may take a look on this.
Regards,
Vladimir
Hi Vladmir, the problem is related to the access of managed memory in unmanaged code, it seems whomever wrote the c# wrappers didn't quite understand how microsoft expects it to be done and so it leads to crashes. I have rewritten the entire decoder and base classes it uses to properly work and avoid the unmanaged errors, I am just looking for how best to submit a patch with the changes I can include more technical details on the issues presented too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
byte [] managed_mem = new byte[12];
fixed(byte * ptr = managed_mem){
// do things with ptr while managed_mem is fixed
}//released
Fairly simple and straightforward, by no means is it meant to be 100% foolproof, but Microsoft made a good effort to help developers use it properly.
Unfortunately it is also very easy to bypass for example:
byte * real_ptr;
fixed (byte * ptr = managed_mem)
real_ptr = ptr;
//now do things with real_ptr while managed_mem is not locked = crash/BSOD
Normally I would not say BSOD but the intels IPP code can be executed at a driver level by intelppm and thus is not afforded some of the protections normal level code has.
While the intel IPP wrappers in some cases properly use fixed, is many cases it uses tricks just like the example above to save out an unmanaged pointer outside of the fixed block. Frequently saving them to member variables that span cross calls. Not only does it do this for some of the short term managed memory it allocates but other memory like the byte array SetSource takes. At 30fps (@ 640x480) I can generally get a crash within half an hour, and a BSOD a few times a day with the stock code. The generic wrappers are very horrendous in this effect and I would strongly avoid them in any production environment. I was using IPP for jpeg decoding so I have completely rewritten the JpegDecoder and any referenced classes it uses to properly use fixed and proper pointers to unmanaged memory. For the most part this just involved placing fixed statements around the proper blocks of code, but in CJPEGColorComponent I had to change it to reference the managed memory rather than the unmanaged. There is one unmanaged pointer not used in fixed statements and thats the Data8u of the image class. For the decoder this is actually a pointer to the destination buffer, which is past to us as a pointer so we can assume the user has already locked it. This should serve as a more than clear example of how properly the wrappers should be written , hopefully intels next version of them will have them all rewritten to proper implementation.
The patch can be found at http://mitchcapper.com/intel_ipp_fixed_fix.patch and is generated against the latest 6.0 release on the website.
From a performance point of view the new code uses a lot of fixed statements, I did some processing tests, (seeing decoding time on 10,000 frames with and without the fixed library over several tests ) and the fixed version has a less than 1-3% performance hit. Changing the locking could probably be more abstracted to outer classes moving pointers inward but my goal was to fix the code with minimal changes rather than most efficient.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Problem was not in the wrapper but in the application (in encoder and decoder jpeg). Workaround (updated codes) has been provided with IPP 6.1 gold update1.
Please login to Intel Registration Centerto find this update.
By the way, the Intel IPP 6.1 update 1 is also included in the latest Intel Parallel Composer Update 1 as well as Intel Compiler Professional Edition 11.1 update release. Please check http://software.intel.com/en-us/articles/which-version-of-ipp--mkl--tbb-is-installed-with-intel-compiler-professional-edition/ to find more information about each compoent version (Intel IPP, Intel MKL andIntel TBB) in various Intel Compiler Professional Editionproduct releases.
To get more information about new features or bug fixes in Intel IPP 6.1 update 1
http://software.intel.com/en-us/forums/showthread.php?t=67278
Regards,
Naveen GV
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I like to inform you that, we have fixed this issue in the latest release of IPP(6.1 Update 2). Please refer to below forum link to get more information like package download, installation and list of bug fixed in this relase.
http://software.intel.com/en-us/forums/showthread.php?t=69675
Thanks,
Naveen Gv
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page