The CUDA 4.2 SDK example project simpleTexture compiles and runs correctly in vs2008 sp1, but when I attempt to add textures to an ongoing CUDA kernel project, some of the necessary functions to create and use the binding are not recognized:
1>c:/ProgramData/NVIDIA Corporation/NVIDIA GPU Computing SDK 4.2/C/src/rohan/Rohan-kernel.cu(67): error: identifier "channelDesc" is undefined
1>c:/ProgramData/NVIDIA Corporation/NVIDIA GPU Computing SDK 4.2/C/src/rohan/Rohan-kernel.cu(664): error: identifier "tex2d" is undefined
The texture declaration itself seems okay:
texture<cuDoubleComplex, cudaTextureType2D, cudaReadModeElementType> tex;
I have duplicated all of the #includes from simpleTexture, include paths look the same, and the ongoing project uses the supplied template project/solution files customized as directed.
Everything was working well before adding the texture bits, what gives?
Try to compile with the flag -arch sm_20
Related
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.
After persistently getting error : identifier "atomicAdd" is undefined, I've found the solution to be to compile with -arch sm_20 flag. But how to pass this compiler flag in VS 2010? I have tried like so under Project > Properties:
But this apparently has had no effect and the error persists - what am I doing wrong?
Many thanks.
You can select the options for the GPU Code Generation in this dialog:
In this case "compute_20" means that i am compiling for the virtual compute architecture 2.0 - virtual architecture influences the PTX generation stage.
The second part that comes after the coma is "sm_21".This influences the CUBIN generation stage. It defines the real GPU architecture i want to compile the PTX to.
You can find detailed description of the nvcc command line parameters that control the code generation here.
Go to the "Device" section under "CUDA C/C++". There, within "Code Generation" you can specify your sm_20. No need for the -arch.
Be aware that there's separate properties for both the project and .cu files. Apparently they get merged before compilation.
I'd gotten caught by this trying to specify GPUs for compute 3.0 & greater, but .cu properties had some leftover specifications for 1.0 & 2.0
Can anybody provide a simple example of how to compile and link a function in a standalone ARM assembly file (a .s file) that compiles in XCode 4.5 for iPhone with the llvm 4.1 compiler ? In other words, latest XCode with default compiler.
I'm trying to call the ARM assembly function from a .cc or .mm file (both cplusplus compatible).
I would like to drop this file into one of the XCode template projects for iPhone (such as OpenGL Game) and call the function defined within (say a function that adds 1 to the input int and returns the value).
I tried this example:
Compile Arm Assembly directly in XCode
I get a linker failure when I try the code from this posting:
Undefined symbols for architecture armv7:
"add_in_asm(int)", referenced from:
Thanks much.
Since you are using C++/ObjC++, the linker won't find a C name unless it is declared as such.
Thus, you should declare your function as
extern "C" int myfunction(...); // or what signature ever...
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.
I have encountered an unexpected Access Error while running a project I've built using two different versions of Visual Studio. My general configuration is as follows:
LibA is a static lib, static runtime linkage, msvc 8.0
LibB is a static lib, static runtime linkage, msvc 9.0
My target project for integration is a msvc 9.0 COM dll, which statically links the above libraries
This project builds, but crashes up at runtime with an access violation in some STL code. The stack seems to indicate that I've passed through headers both versions (8 and 9) during a call into a stream insertion operator. I realize that this is a problem.
Somehow, this call:
ost << std::dec << port_; //(originating from an object in LibA)
...descends through the following stack trace:
std::basic_ostream::operator<<(...) (ostream:283, msvc 8.0 version <-- expected, since LibA was built with this version)
std::num_put::put(...) (xlocnum:888, msvc 8.0 version <-- expected, since LibA was built with this version)
std::num_put::do_put(...) (xlocnum:1158, msvc 9.0 version!! !##$!%! <-- not expected, since LibA was built with msvc 8.0)
std::ios_base::flags() (xiosbase:374, msvc 9.0 version <-- follows from above)
The access violation happens in std::ios_base::flags(). I suspect it is due to the mix of implementations in the call stack (although I am not sure).
My questions are.
1.) Is the likely cause of this access violation the mixing of msvc header implementations?
2.) Is there a way to prevent these implementations from mixing?
3.) Is there a better way to configure these three projects for integration (assuming moving LibA from msvc 8.0 is undesirable)?
I am aware of the ideas raised in this question and this one. Here I am most interested in this specific problem, and if there is some way to avoid it.
Any insights would be appreciated.
You can't use different STL implementation in the same project. This means even different versions from the same compiler. If your LibA has a function that accepts std::vector as an argument you are only allowed to pass vector object from STL that LibA was built with. This is why many C++ libraries expose only C API.
Either you change your API or you rebuild all your projects using the same compiler.
You are doing something that you shouldn't. You are in the world of undefined behavior. There is no point in trying to debug this particular crash. Even if you managed to make this line work you would get a new crash somewhere else.
There is no guarantee of library binary compatibility between major versions of MSVC. STL code is mostly template code that gets expanded into your code. So you're static libraries probably have incompatible chunks of STL code inside of them.
In general, this shouldn't be a problem, unless that STL code is part of the interface to the library. For example, if you pass iterators or a reference to a vector from one library to another, you're in trouble.
The best solution is to build everything with the same version of the compiler. If you can't do that (e.g., if the one of the libraries is from a third-party), you're probably stuck.