Compiling JNPP for CUDA 6.5


#1

I am trying to compile the source for JNPP but it looks like the CUDA JDK has changed slightly from I am guessing 5.0.

For the first 3 errors it looks like Npp64f * pNormDiff was added.

For the 4th error it looks like nppiSqrIntegral_8u32s32f_C1R was removed and a few other functions were added.

Unfortunately I am not familiar with this to resolve the issues. Does anyone have some tips on resolving these issues?

Error 1 error C2660: ‘nppiNormDiff_L1_8u_C1R’ : function does not take 6 arguments C:\Users\kvasko\Downloads\JNpp-0.5.0.35-beta03-src\JNpp-0.5.0.35-beta03-src\JNppJNI\src\JNppi.cpp 163066 1 JNpp
Error 2 error C2660: ‘nppiNormDiff_L2_8u_C1R’ : function does not take 6 arguments C:\Users\kvasko\Downloads\JNpp-0.5.0.35-beta03-src\JNpp-0.5.0.35-beta03-src\JNppJNI\src\JNppi.cpp 163160 1 JNpp
Error 3 error C2660: ‘nppiNormDiff_Inf_8u_C1R’ : function does not take 6 arguments C:\Users\kvasko\Downloads\JNpp-0.5.0.35-beta03-src\JNpp-0.5.0.35-beta03-src\JNppJNI\src\JNppi.cpp 163252 1 JNpp
Error 4 error C3861: ‘nppiSqrIntegral_8u32s32f_C1R’: identifier not found C:\Users\kvasko\Downloads\JNpp-0.5.0.35-beta03-src\JNpp-0.5.0.35-beta03-src\JNppJNI\src\JNppi.cpp 163363 1 JNpp


#2

Hello

The update of the main JCuda libraries was just finished a few days ago, and I did not yet have the time to look at the changes of NPP in the latest version.

If there are “only” these 4 errors, then it might be possible to just fix them manually by adding the required parameter and omitting the function that obviously does no longer exist. However, I would not recommend this, because there may be further changes. I’ll have a look at the differences of the new version later today, and try to create an update of JNpp for 6.5. (due to some time constraints, this may probably not be earlier than beginning of next week, but I’ll start today and see how much there actually has to be updated)

bye
Marco


#3

Thanks.

I was actually able to fix those 4 issues manually.

But unfortunately I ran into an issue with CommonJNI64d.lib missing. I see there is a CommonJNI in the JCUDA source but not sure how to make it generate the CommonJNI64d.lib instead of CommonJNI.lib


#4

The “d” indicates that you’re trying to compile the “Debug” version.

Regardless of that: When you compile the CommonJNI library based on the project files that are generated by CMake, the file name will be “CommonJNI.lib”, and simply not carry information about whether it’s 32 or 64 bits. So in doubt, it should be possible to simply rename the file (or the dependency in the JNpp project file, respectively).

BTW: I have to emphasize that JNpp is (unfortunately still) an early beta and some functions may not work properly … there’s a LOT of functions in NPP, it’s hard to verify each possibly call configuration…

However, I’ll try to create an updated version of JNpp as soon as possible.


#5

I feel I’m so close to getting this compiled.

I switched the name from CommonJNI64D.lib to CommonJNI.lib in the vcxproj as you suggested and that particular issue went away but now I have about 2k errors saying.

Error 3 error LNK2019: unresolved external symbol nppiMalloc_8u_C1 referenced in function Java_jcuda_jnpp_JNppi_nppiMalloc_18u_1C1Native C:\Users\kvasko\Downloads\JNpp-0.5.0.35-beta03-src\JNpp-0.5.0.35-beta03-src\JNppJNI\JNppi.obj JNpp

I have a feeling its still due to the CommonJNI.lib not linking correctly. I’m still going to keep trying to troubleshoot this and hopefully I get somewhere in the meantime of you working on it.

As for JNpp being in the early stages I completely understand. I just want to get the HistogramEqualization sample on the jcuda.org site working for a proof of concept. Obviously as things progress I might even be able to help make improvements to JNpp/JCuda if I continue down this path.

Thanks!

PS. I sent an email to jcuda@jcuda.org with a link to the Windows x64 bit dll binaries for JCuda. I wasn’t sure how you packaged the *.jar and *.dll files but the binaries.


#6

I’m not sure whether there’s a real reason for you to go through this hassle, but if your longer-term intention is to contribute to JNpp, this will be welcome, of course :slight_smile:

I’m currently not at my main development PC, but will handle your e-mail soon.


#7

[QUOTE=Marco13;100978]I’m not sure whether there’s a real reason for you to go through this hassle, but if your longer-term intention is to contribute to JNpp, this will be welcome, of course :slight_smile:

I’m currently not at my main development PC, but will handle your e-mail soon.[/QUOTE]

Thanks! I guess the hassle is to learn more about what is going on as I’m completely new to all of this, in addition would like to expedite this process if possible so I can test some other things.

Thanks again!


#8

Just an update.

I solved the above issue.

After adding these two libraries to “Configuration Properties --> Linker --> Input --> Additional Dependencies”

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\lib\x64
ppi.lib
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\lib\x64
pps.lib

Doing this allowed me to generate the Jnpp-windows-x86_64.dll.

This corrected my issue inside of my JCUDA application.

I am now trying to troubleshoot why I am getting a black image as the result in my lena512color_pale_histEqualization.png file when I run the JNppHistEqualization.java sample code.


#9

Just an update to anyone else that might be going down this path.

As I mentioned earlier I was able to get the JNpp source to work with a few modifications and was able to successfully run the JNppHistEqualization.java example thats on the jcuda site.

Unfortunately when I ran the code on the sample image it would fail silently (I would only get a black image back).

The nppiLUT_Linear_8u_C1R() call is returning -106 error code which translates into NPP_LUT_NUMBER_OF_LEVELS_ERROR. Changing the function call to the following.

nppiLUT_Linear_8u_C1R(
oDeviceSrc.data(), oDeviceSrc.pitch(),
oDeviceDst.data(), oDeviceDst.pitch(),
oSizeROI,
lutDevice,
levelsDevice,
binCount); // remove the + 1 from here

Once I did this it started working.


#10

Marco13,

It seemed that every time I would run the JNppHistEqualization sample to process an image it would always end up being square. Every time ImageNPP_8u_C1(w,h) was called it would would work fine. However if I called ImageNPP_8u_C1(ImageNPP) it would square the image up. I started digging into it and I think I found a mistake in the AbstractImage.java code.

   public int width()
   {
       return oSize_.nHeight();
   }
   
   @Override
   public int height()
   {
       return oSize_.nHeight();
   }

I think i should be

   public int width()
   {
       return oSize_.nWidth();
   }
   
   @Override
   public int height()
   {
       return oSize_.nHeight();
   }

Once I made that change and recreated the jar it seemed to work correctly.

Thanks!


#11

Thanks for the infos, … this “AbstractImage” bug seems so familiar, I think there once was a similar one…

In any case: Today I can finally continue to work on the update of JNpp, then I can also fix this bug in AbstractImage.

Concerning the call to “nppiLUT_Linear_8u_C1R”: I have to admit that I mainly ported the sample from NVIDIA, so I’m not sure about the reason for this behavior (i.e. whether it is a bug that was fixed or introduced), but of course I’ll run the test with the Histogram Equalization sample when the update is done. (In fact, I have to admit that this is basically the only test for JNpp that I can sensibly run… there are no unit tests at the moment ;))


#12

Thanks!

I can completely understand for the nppiLUT_Linear_8u_C1R issue. I didn’t do much validation on it either. I just saw the error and debugged it to see what the value that was being passed into the function and then corrected what I thought was wrong.

Thanks again.

Eventually I’ll probably be trying to implement more image processing algorithms but for now Histogram Equalization is the main one I’m going to be testing with. If I find anything else I’ll let you know.

Thanks


#13

Not being sure about which of the functions actually work nevertheless leaves an uncanny feeling. Maybe I should not even have tried to create bindings for NPP: It’s such a tremendously complex library.

I started an update, and there are quite a lot of changes between the last version for which I did a “real” update. (For some intermediate versions, I only compiled the library against the new NPP version, but did not really update it based on the changes in NPP). I’m currently once more mind-blown by functions like

NppStatus
nppiEncodeOptimizeHuffmanScan_JPEG_8u16s_P3R(Npp16s * pSrc[3], Npp32s aSrcStep[3],
                                             Npp32s nRestartInterval, Npp32s nSs, 
                                             Npp32s nSe, Npp32s nAh, Npp32s nAl,
                                             Npp8u * pDst, Npp32s * pLength,
                                             Npp8u * hpCodesDC[3], Npp8u * hpTableDC[3],
                                             Npp8u * hpCodesAC[3], Npp8u * hpTableAC[3],
                                             NppiEncodeHuffmanSpec * aHuffmanDCTable[3], 
                                             NppiEncodeHuffmanSpec * aHuffmanACTable[3], 
                                             NppiSize oSizeROI[3], Npp8u * pTempStorage);

Seriously, I mean: What the … ?! :sick: (Translating something like this already is a hassle, but who can use something like this…?)

However, I made some progress, maybe can provide the update soon.

In any case, if you are actually using NPP (not necessarily the function mentioned above ;)) and can create code snippets or samples (maybe by porting NVIDIA samples, like the Historgram Equalization), that would be great, of course :slight_smile:

*** Edit ***

And … Eclipse Juno seems to have a problem with a 5 MB .java file that contains 4500 methods like this:

Eclipse Helios seems to sray responsive, however (I’m looking forward to pasting the 12 MB (!) .C file into Visual Studio :rolleyes: )


#14

For what it is worth I am glad you spend the time doing it. I believe it is going to save me some time.

Yeah I’m REALLY new to all of this stuff and am a complete beginner so I am having to learn as I go. I’m honestly going into this stuff blind as I have no idea what is in the CUDA domain, the JCuda domain, Image processing domain etc.

I’m not sure how much benefit I’ll be but anything I find I’ll be glad to return to help you out.

Have you tried Eclipse Luna?

Thanks again.


#15

Concerning Eclipse: I’m not sure what exactly causes the delays/hangups, but I don’t want to investigate this now. It works with Helios, and once I got the update done, I can see whether it can be handled with Juno or Luna.

At the moment, there’s a bit of a hassle. Some functions (like the one mentioned above) are not covered properly by my toolchain, but updating the toolchain (and particularly: verifying that this function afterwards does what it should do) is impossible for me at the moment, so this function (and few others) will probably throw an “UnsupportedOperationException” for now…

Additionally, there are other functions which seem to be missing in the nppi.lib (I posted this at https://devtalk.nvidia.com/default/topic/774389/cuda-programming-and-performance/functions-missing-in-npp-lib-npp-on-win32-cuda-6-5-14/ - a similar issue happened in one of the first NPP versions). Admittedly, I’m not sure whether I can finish the update this week, but will try to get it done ASAP.


#16

I’m currently uploading an updated version of JNpp for CUDA 6.5.14, and it should be available in a few minutes at http://www.jcuda.org/downloads/downloads.html#JNppDownload

(A side note: The bug in the “utils” library was actually fixed more than one year ago, but I simply did not create an update in the meantime - obviously, JNpp had a comparatively low priority in this time :o )

You mentioned that you encountered a bug (a black image) when using the original “JNppHistEqualization.java” - is this still the case? I tested it with the new version, and the correct output was produced even without changing the binCount…


#17

[QUOTE=Marco13;101444]I’m currently uploading an updated version of JNpp for CUDA 6.5.14, and it should be available in a few minutes at http://www.jcuda.org/downloads/downloads.html#JNppDownload

(A side note: The bug in the “utils” library was actually fixed more than one year ago, but I simply did not create an update in the meantime - obviously, JNpp had a comparatively low priority in this time :o )

You mentioned that you encountered a bug (a black image) when using the original “JNppHistEqualization.java” - is this still the case? I tested it with the new version, and the correct output was produced even without changing the binCount…[/QUOTE]

Marco13,

As for the JNppHistEqualization.java I think there is a discrepancy in the histEqualiationNPP.cpp file sample and the JNppHistEqualization.java code on your site.

If you look in histEqualizationNPP.cpp binCount is initialized to 255 on line 172. In your sample on your website

        // allocate arrays for histogram and levels
        //

        const int binCount = 255;```

In your JNpHistEqualizationSample.java posted on the jcuda.org site it is initialized to 256.

   // Allocate arrays for histogram and levels
    int binCount = 256;

Without wanting to change the original value I made the modification in the calling function of nppiLUT_Linear_8u_C1R to simply be 256 which seemed to work and got me the image correctly.

I changed the JNppHistEqualizationSample.java binCount to 255 and that fixed it for me.

#18

Attached are the 64-bit windows .dll binary I compiled.

I’m going to be doing this on Linux as well I should be able to produce you the Linux 64-bit binaries for Npp if you would like.

If you need them you can credit Kevin Vasko

If you need me to compile the 64-bit jar files or need something else with these binaries let me know.

Thanks,

-Kevin

*** Edit ***

Just out of curiosity do you have a 64-bit machine? I see you mostly compiling 32-bit windows stuff, so I wasn’t sure if I was wasting my time submitting the 64-bit windows binaries.


#19

Thanks for this contibution, I’ll upload the binaries tomorrow, with credits going to you.

I don’t have a 64bit machine on my own but… occasionally take the chance to compile something on the 64bit machine in my office…


#20

Oh wow.

Well if you need some packages compiled for 64-bit let me know.

I’ll probably send you some more binaries for other architectures (Linux 64bit) when I resolve some other stuff with my other tasks.