CUDA 4.0 NPP VS2008 FilterMax and Dilate

[TurtleSC]

I thought I would cross post this from (http://stackoverflow.com/questions/6298574/cuda-npp-anchor-errors-with-dilation-and-filtermax) to see if anyone here could verify an issue or propose a solution:

I am using CUDA 4.0 on Windows 7 and Visual C++ 2008 to run the NVIDIA Performance Primitives (NPP). I have tried running nppiDilate_8u_C1R and nppiFilterMax_8u_C1R and am experiencing errors specifying the anchor points in the center of the kernel. I can specify an anchor of {0,0} or {Positive, Negative} but never {Positive, Positive} and to center the kernel I need to be positive/positive. Has anyone else encountered this problem?

NppiSize mySize = {Nx, Ny};
NppiSize myKernSize = {3,3};
NppiPoint myKernAnchor = {1,1}; // fails, but {1,-1} works!
NppStatus myStatus = nppiFilterMax_8u_C1R (dataA, strideBytes, dataB, strideBytes, mySize, myKernSize, myKernAnchor);
if(myStatus != NPP_SUCCESS)
{
cout << "Error Code: " << myStatus << endl;
}

The result is

Error Code: -24

Where -24 is defined as NPP_TEXTURE_BIND_ERROR.

Any ideas why an anchor in the center will fail? I’ve been digging around and will not that the entries are malloc independently and were made small and odd sized for test (10x10, 32x32, 16x16, all same results.
Thanks for looking!

[Frank_Jargstorff]

My initial suspicion is, that you’re not adjusting your ROI size accordingly. Say you have a kernel of size 3x3 and you try to center it, i.e. offset it by (1, 1). That now means that when output pixel (0, 0) is computed the kernel attempts to access pixels (-1, -1), (-1, 0), (-1, 1), etc.

As you can see, unless you moved your ROI down one row and over one column, you’re trying to access pixels with negative indices, which in all likelyhood results in accessing memory locations that aren’t valid.

As for the Texture-Bind Error: Internally, the kernel uses these offsets to bind the input image such that the the top/left pixels is at the surface’s base address. In your case that would be pixel -1, -1 and again my suspicion is, that that address is not valid and therefor the internal texture bind fails.

[TurtleSC]

Frank, thanks for the advice.

This looks to be correct–I had assumed that the edge conditions would be handled in NPP and couldn’t find anything in the documentation indicating otherwise.

I moved everything as you suggested----that is specified an ROI with 1/2 the kernel width/height removed around the border and centered int he image–and the kernel anchor then worked.

Right now it looks like the only way to get the full image dilated will be to copy one image into a larger and then crop it.

My initial suspicion is, that you’re not adjusting your ROI size accordingly. Say you have a kernel of size 3x3 and you try to center it, i.e. offset it by (1, 1). That now means that when output pixel (0, 0) is computed the kernel attempts to access pixels (-1, -1), (-1, 0), (-1, 1), etc.

As you can see, unless you moved your ROI down one row and over one column, you’re trying to access pixels with negative indices, which in all likelyhood results in accessing memory locations that aren’t valid.

As for the Texture-Bind Error: Internally, the kernel uses these offsets to bind the input image such that the the top/left pixels is at the surface’s base address. In your case that would be pixel -1, -1 and again my suspicion is, that that address is not valid and therefor the internal texture bind fails.

[TurtleSC]

Frank, thanks for the advice.

This looks to be correct–I had assumed that the edge conditions would be handled in NPP and couldn’t find anything in the documentation indicating otherwise.

I moved everything as you suggested----that is specified an ROI with 1/2 the kernel width/height removed around the border and centered int he image–and the kernel anchor then worked.

Right now it looks like the only way to get the full image dilated will be to copy one image into a larger and then crop it.

My initial suspicion is, that you’re not adjusting your ROI size accordingly. Say you have a kernel of size 3x3 and you try to center it, i.e. offset it by (1, 1). That now means that when output pixel (0, 0) is computed the kernel attempts to access pixels (-1, -1), (-1, 0), (-1, 1), etc.

As you can see, unless you moved your ROI down one row and over one column, you’re trying to access pixels with negative indices, which in all likelyhood results in accessing memory locations that aren’t valid.

As for the Texture-Bind Error: Internally, the kernel uses these offsets to bind the input image such that the the top/left pixels is at the surface’s base address. In your case that would be pixel -1, -1 and again my suspicion is, that that address is not valid and therefor the internal texture bind fails.