Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
6709 Discussions

Access violation in ippiRemap_64f_C1R with large inputs/outputs

tj5
Beginner
423 Views

I am running into an access violation when using ippiRemap_64f_C1R with large inputs/outputs, both with and without using TBB blocked_range or TBB blocked_range2d. I am seeing this on Mac, Windows, and Linux platforms. When stepping through the code in debugging mode on linux, I did not observe the issue. With my repro steps, I am using source and destination images with a width of 27485 and a height of 26588. Any suggestions about what could be happening here?

 

IPP Libarary info:

ippIP AVX-512F/CD/BW/DQ/VL (k0)

2021.1 (r0xe13a8835)

2021.1.0.-516257739

Nov 12 2020

 

#include <ippdefs.h>
#include <ipps.h>
#include <ippcore.h>
#include <ippi.h>

int main ()
{

    const int32_T width =  27485;
    const int32_T height = 26588;   

    real64_T *pSrc = ( real64_T *) malloc(width*height * sizeof(real64_T));
    real64_T *pDst = ( real64_T *) malloc(width*height * sizeof(real64_T));
    real64_T *xLocations = ( real64_T *) malloc(width*height * sizeof(real64_T));
    real64_T *yLocations = ( real64_T *) malloc(width*height * sizeof(real64_T));

    for (size_t i = 0; i < height; i++) 
    {
        for (size_t j = 0; j < width; j++)
        {
            pSrc[j + i*width] = static_cast<real64_T>(1);
        } 
    }

    for (size_t i = 0; i < height; i++) 
    {
        for (size_t j = 0; j < width; j++)
        {
            xLocations[j + i*width] = static_cast<real64_T>(i);
        } 
    }

    for (size_t i = 0; i < height; i++) 
    {
        for (size_t j = 0; j < width; j++)
        {
            yLocations[j + i*width] = static_cast<real64_T>(j);
        } 
    }
    
    const real64_T srcSize[2] = {height,width};    
    const real64_T dstSize[2] = {height,width}; 

    IppiSize sizeSrc = { static_cast<int32_T>(srcSize[0]), static_cast<int32_T>(srcSize[1]) };
    IppiRect srcRoi = { 00static_cast<int32_T>(srcSize[0]), static_cast<int32_T>(srcSize[1]) };
    IppiSize dstRoiSize = { static_cast<int32_T>(dstSize[0]), static_cast<int32_T>(dstSize[1]) };

    int32_T StatusCode = ippiRemap_64f_C1R(pSrc,
                                           sizeSrc, 
                                           static_cast<int32_T>(srcSize[0] * sizeof(real64_T)), 
                                           srcRoi, 
                                           xLocations, 
                                           static_cast<int32_T>(srcSize[0] * sizeof(real64_T)),
                                           yLocations, 
                                           static_cast<int32_T>(srcSize[0] * sizeof(real64_T)),
                                           pDst, 
                                           static_cast<int32_T>(dstSize[0] * sizeof(real64_T)),
                                           dstRoiSize, 
                                           IPPI_INTER_LINEAR);

free(pSrc), free(pDst), free(xLocations), free(yLocations);

}
0 Kudos
1 Reply
Gennady_F_Intel
Moderator
400 Views

Tim,

The issue is caused by integer overvlow. The only way to proceed with big images at this version of IPP is to split the original image into several tiles and make remapping with each of these tiles separately.


IPP contains so-called platform-aware functions for image processing. These functions work with 64-bit object sizes.

However, I have to notice, that the current version doesn't support platform-aware API for ippiRemapping functionality.

Therefore, if you are interested to see this platform-aware mode with ippiRemap functionality - please let us know here or You may submit the Feature Request to the official channel -Intel Online Service Center.


-Gennady




0 Kudos
Reply