I am trying to test some code that has recently passed into my responsibilities. While the CUDA projects passed onto me work, I can't seem to get a [new Project] inside the VS13 [Solution] to work.
I've created a CUDA 6.5 runtime project. I've also added the dependencies needed for my own code.
Upon compiling, I receive several [error C2061: Syntax error : Identifier 'surface'] or 'texture'.
I'm currently at a loss as to what I am missing. I would guess there is some dependency I need to add to the project, but it is hard to find any relevant resources online when looking for this error message. I've already added "compute_30,sm_30" in the correct place (i.e. the same place as in the projects that compile).
EDIT: Relevant is that the file throwing errors is #included in someClass.h which is included in the main function.
As is pointed out below, the problem is that CUDA-specific files are included in the visual compiler.
As discussed in the cross-posting here, the root cause of this problem is that the code that involves surface and texture keywords is in a .h file that is ultimately being included in a .cpp file
In a VS CUDA project, by default, .cpp files get compiled by cl.exe, the windows host code compiler. .cu files get compiled by nvcc, the NVIDIA GPU compiler/driver.
cl.exe does not understand the surface or texture keywords, and so throws the mentioned syntax errors.
The only solution is to arrange your project such that those constructs only appear in, or get included in, files that will be process by nvcc, which is the compiler that understands surface and texture (and other CUDA) keywords.
For reference, there are various CUDA sample codes (such as this one) that use surface and texture constructs, and also have project code partitioned between .cpp and .cu files. You can study these if you wish for examples of how such projects might be organized.
Related
I have a CUDA project that originates from a C++ project. I will need to add CUDA code to different compilation units over time. Let's say I have two files, kernel.cuh and kernel.cu that contain my kernels' headers and bodies. Then, I change the extension of a module from .cpp to .cu, include kernel.cuh, and call my kernels using the < syntax (myKernel<<<blocksPerGrid, threadsPerBlock>>>). When I do this, I get an error in the module that says syntax error: < . The problem is that this file is still compiled by the C++ compiler instead of nvcc, and I don't know how to change that in Visual Studio manually. I thought the compiler was chosen according to the extension of the files. The problem wouldn't go away until I create a new project from scratch. Does anyone know how to fix this so that I will not need to create a new project?
For the question to get off the unanswered list, I will give a simple solution that solves the problem but does not answer my question about VS. I didn't have to make a new project from scratch. I only had to remove the file from the project and then add it again (Idk why I hadn't tried this before).
Recently I want to change my run-time shader compilation into build-time shader compilation by use vs built-in shader compiler (so you could right click on the hlsl file from vs solution explorer, and change the item type to HLSL compiler to use this built-time shader compilation thing, so every time you compile your project, the shader will be compiled, and you only need to load the compiled byte code in runtime). The problem I have is that most of my shaders files need to compiled to multiple versions (different macro define flags), it's very easy to do it during run-time (just compile, change define flag, and compile again), however I can't find any option in vs which allow you to compile the same hlsl file multiple times with different defines.
So I come here and ask you guys for help, suggestions.
Thanks
You can create multiple project configurations, and set up different preprocessor definitions for them in the HLSL Compiler/General settings.
I have much trouble compiling OpenCV 245 with GPU support. With some effort I managed to have cuda support up and running, but now I am stuck on opencl, here is the problem:
At some point during the compilation, the file kernels.cpp is generated, containing all kernel functions as strings. For what I understand, they are converted automatically from the .cl files with the cl2cpp.cmake script.
What I don't understand is that one file is excluded from the build: nonfree_surf.cl (which is on my disk, alongside all other .cl files) is not included, either in the visual studio project, or in the kernels.cpp that is automatically generated. This leads to an undefined error at link time.
I have tried manually adding the nonfree_surf.cl to the visual studio project. This does not change anything. In the CMakeLists.txt for ocl module, all the cl files seem to be automatically added with the line:
file(GLOB CL_FILES "${CMAKE_CURRENT_SOURCE_DIR}/src/kernels/*.cl")
I have tried manually adding nonfree_surf to CL_FILES, with no effect.
I have very little knowledge of CMake, hence I don't understand well what is going on. Can somebody give me a clue how I could find the reason of this behavior, namely:
Why are all .cl files added to my VS project, except nonfree_surf.cl ?
How can I correct this ?
Maybe I can execute cl2cpp.cmake script manually ? If so, how ?
Managed it by manually running the script:
cmake -DOUTPUT_PATH=c:/opencv/kernels2.cpp -DCL_DIR:PATH=c:/opencv/modules/ocl/src/kernels -P "c:\opencv\modules\ocl\cl2cpp.cmake"
For some reason (probably the same that makes nonfree_surf not be processed), not every necessary function are processed this way, so I juste copy-pasted the nonfree_surf string into kernels.cpp, and proceeded with the build.
If anyone needs the binaries, since they are a pain to compile, here they are:
Opencv 2.4.5 binaries compiled with VS2010 x86 (WIN32) including ocl and gpu library.
I am lost in a rabbit hole, please bear with me.
I'm trying to use the OpenCV Stitching module from the 2.3.1 Win superpack distribution. I dragged all the source files in /modules/stitching into a Visual Studio project, resolved the Includes and Libs as best I could, and got it to compile.*
The first strange runtime error I had was that I could not read a JPG file from disk with imread(). It did not throw an error, but was returning true for myImage.empty(). I reverted to cvLoadImage() and then it worked.
Now, after that, there is a new runtime error:
Unhandled exception at 0x00870d8f in MyStitcher.exe: 0xC0000005: Access violation writing location 0x010e7000.
This occurs in /modules/stitching/matchers.cpp when trying to pass reference to features.keypoints as a detector_->detect() argument. I assume detect() is supposed to populate the keypoints with its result. features appears to be uninitialized (it has 612933850 empty keypoints at the breakpoint). Now this is starting to sound like the source I'm trying to compile is just broken, but opencv_stitching.exe that comes prebuilt works just fine. Was it compiled from different source?
By the way, I do not know how to use the CMake system to generate Visual Studio projects, as recommended, for OpenCV. The CMakeLists.txt file in the /modules/stitching folder did not work. Is it not supposed to be used as a starting point?
*One note on this: CMakeLists.txt in /modules/stitching specifies some
libs named opencv_core, opencv_imgproc, opencv_highgui, etc. (without
a version indication) but the libs included with OpenCV 2.3.1 Win32
superpack (which I'm linking to) are named opencv_core231.lib,
opencv_imgproc231.lib, etc. Is this a clear indication that I am using
mismatched binaries for the stitching module?
I got this working after building the latest from the OpenCV SVN. The stitching module came a long way since the 231 release.
we're building a cross-platform utility which must have a small footprint. We've been pulling header files from boost as and when we need them but now we must link against some boost C++ thread code. The easiest immediate solution was to create our own custom library using CMake's "add_library" command to create a static library composed of some boost thread source files. These compile without any problems.
The difficulty arises when I try to link to this library from an executable. Visual Studio 2008 returns an error saying that it cannot link to "libboost_thread-vc90-mt-sgd-1_40.lib". What really puzzles me is that I've grepped through all the source code and CMake config files and I can't find any reference to this libboost library, leading me to think that this has been autogenerated in some way.
This works OK in Linux, can anyone point out why I'm experiencing these issues in Windows?
#Gearoid
You found the correct reason for your problem, but not the correct solution. The BOOST_AUTO_LINK_NOMANGLE is an internal, i.e. for library authors, definition to control the auto-linking. The user level definition is BOOST_ALL_NO_LIB which when defined disables the auto-linking feature for all Boost Libraries code you use. This is described in the user.hpp configuration header (see user.hpp near the bottom and the Boost Config documentation). You can also control this on a per library level as describe in that header.
Ok, well, it turns out that Boost uses this auto-link feature for Visual Studio which embeds references to a mangled (ie, platform-compiler-mult-threaded, etc) boost library name.
The header file which controls this is called "auto_link.hpp" which lives in the config directory of the boost include tree. There's a special preprocessor definition called "BOOST_AUTO_LINK_NOMANGLE" which toggles this behaviour.
Another triumph of mediocrity for Microsoft.