Unzip the downloaded file into the C:\ directory. Configure Cmake as shown in the attached file Image1.jpg. When I hit the configure button the popup appears, in which I chose Visual Studio 2010. With the provided readme in FlowLib it is unclear to me if CMAKE_MODULE_PATH should be set to C:/FlowLib_2.1_win64/vmlibraries/simple_test or to C:/FlowLib_2.1_win64/vmlibraries/cmake. Anyway I have the same problem with any of those two.
Once I confirm the compiler (hitting Finish in the popup of Image1.jpg) I get the errors shown in the attached Image2.jpg.
Even if I set FlowLib_DIR and ImageUtilities_DIR to the C:/FlowLib_2.1_win64/vmlibraries/cmake directory as said in the error message, I run into the same problem when I hit configure again.
I looked it up and apparently Gmake includes those commands since 2.8. I have a newer version than that so it should recognize it? As I understood there’s no need to do anything if you have that Cmake late version.
The problem you are seeing below is that the find_package(CUDA) call was never made. This is because this call is inside an if block inside FindImageUtilities.cmake:
if(IU_IUCORE_FOUND)
# CUDA
find_package(CUDA 3.1 REQUIRED)
On my mac, the IU_IUCORE_FOUND is false, because the libraries are never found. This is because the libraries have version numbers on them and the find_library command doesn’t include those version numbers in the names of the libraries it searches for. If you explicitly tell CMake where the libraries are, then the configuration process searches for CUDA and the rest of the system seems to behave properly.
I would inform the authors of the package about these problems and perhaps they can fix them.
Ideally the UseImageUtilities.cmake script would have checked for the presence of the IU_IUCORE_FOUND variable and errored out before calling FindCUDA module functions that may not exist.
From the GUI you will need to fill in the entry that says, IO_IOCORE_LIBRARY. There should be a little “button” on the right that should allow you to browse to where the library is on disk. If you don’t see the entry, press the check box labeled “Advanced” (or something like that), then scroll down until you see the entry. There will be an entry for the IO_IOCORE_LIBRARY as well as DEBUG and RELEASE versions of that name. I left the latter two as they were and only filled in the main entry.
You are right. We should check the presence of the core module before looking for cuda. I was not aware that the windows cmake version is not aware of version numbers? It works fine for my test builds in windows. Basically all developement is done on linux. Maybe my libraries in the test build on Win were confused with the developement branch. I will check in more detail for the next release and include a sanity check for the core library… Thanks for pointing that out.
CMake only knows about version numbers so far as you teach it to. If you have version numbers in the library file names, then you should add these version numbers to the name of the library when you look for it using find_library.
Also, I did my experiments on Mac, so these issues weren’t isolated to windows.
Ok thanks. I’ll check that in more detail. I suppose that my test setup mixes something up with the development branch and therefore finds the library though there are the version numbers. I’ll fix that in the next release…
OK, when I configured and got the cuda_included_directories error, I manually set the IU_IUCORE_LIBRARY and IU_IUIO_LIBRARY to their location. As shown in the attached
Image1.jpg, there are a number of other libraries that are not found either, but I can’t manually point to them because they are not included in the /lib directory.
Anyway, at this point I hit configure again, and got a flowlib libraries not found message (as shown in Image2.jpg). So I manually set FLOWLIB_LIBRARY to /lib/flow.lib and hit configure again. The result is shown in Image3.jpg. It says “configuring done”, even though there are still a few non found libraries and got some warnings? in red. I hit now “generate” and just says “generating done”.
So I go to the build folder, and open flowlib_simpletest.vcxproj in VS10 (Image4.jpg). At this point I Build > Build solution and got a Cannot open ‘iu/iucore’ message in flowlib_simpletest.cpp, line 31. No matter if I chose the Debug, Release or any other configuration I still get the error. I guess the libraries were not correctly installed.
So, I manually copy the iu/ and fl/ to the same directory where simple_test it, and change #include <iu/iucore.h> with #include “iu/iucore.h”. But then it won’t find another includes in other files, like #include <iucore/coredefs.h> in coreutil.h, so I also put those between quotations and aadd iu/ in some. But then I get some redefinitions errors (Image5.jpg). At this point I have no idea how to continue.
The redefintions come from Cuda 4.0 as those operators weren’t defined in Cuda 3.2 we had to define them. The library is coded for Cuda 3.2 and not 4.0. If you want it to use it with Cuda 4.0 try to delete the duplicated operators but I cannot guarantee anything.
Thanks for the response. I tried it and compiled successfully but the application will give a memory error message. I will try the whole process using CUDA 3.2, and as I have seen there’s now a workaround Optimus in Linux, will give it a try there too in a few days as I won’t be at home.
which memory error message? If too many resources were requested you can reduce the block_size so it can run on your gpu. (flow->params.intern_params.block_size = 8) hopefully i recall the variables name correctly but you’ll figure it out.
Well I’m not sure if it’s a memory problem. It says “The application failed to initialize properly (0xc000007b). Click OK to terminate the application”. I had googled it and said the reasons are the .dll permissions, but giving full permission to the dlls involved still give the same result.
I am new to cuda programming, and I run into the same CUDA Error: too many resources requested for launch when launching most of the flowlib models. I have an NVidia Quadro FX 1800 and use the SDK 3.2. changing the (static) blocksize to 8 did not change anything. Could this be due to my graphics card?
