With CUDA 5 it is now possible to build libraries containing cuda code and link with nvcc.
Thrust consisting of only header files results in multiple definition errors when linked in this situation.
Is there anyway around this problem without going through and converting thrust to header and code files and building it as a library?
As discussed on this thrust-users thread, this was indeed a compiler bug. A fix has been made and should be in the CUDA 5.0 release candidate, which is now available.
Can you please try CUDA 5.0 RC and report back if the issue is fixed?
Related
I want to use the AMD HIP framework for my self-written GPU kernels. I do that by using a third-party library, which takes responsibility of taking the code and compiling it with HIP (and additional backends if desired). The technical setup looks as follows:
The kernel code is compiled into a static helper library with AMD HIP linking and toolchain enabled (CMake: set_target_properties(${target_name} PROPERTIES LINKER_LANGUAGE HIP))
This helper library is then linked into the core part of our own library, which is a shared library
This core part is then linked into the final shared library which is shipped at the end
Therefore, we have 3 different libraries in the build process that are linked together.
The build process exits without any errors s.t. that during compile- and link-time there are no errors. However, when I now want to use this library, I get the following error during runtime: undefined symbol: __hip_fatbin.
Because the code used to not even link correctly, I added these two flags to CMake which made it build successfully (as suggested by others on GitHub): -fgpu-rdc --hip-link. However, the library still does not run because of this undefined symbol error during execution. Inspecting the created libraries with nm -gD shows U in front of __hip_fatbin which makes me wonder why it is like that. Shouldn't that be somehow defined when linking with the HIP toolchain?
So my question is if anybody experienced the same issue yet when trying to use AMD HIP across multiple libraries that are linked against each other. Might this be an issue with gcc and HIP's clang? Or is there any chance for me to get further details which makes me understand what to do now. Thank you!
I have an external function from an opencv dll, cvCreateFileCapture, that should take the path as an input and return a structure.
CV_IMPL CvCapture * cvCreateFileCapture (const char * filename)
I created a vs2010 project for testing purposes from where i call this function with a valid file path and get the structure i was supposed to get returned.
When I call this function from a different program (I'm using labVIEW) I jump into the same function with the same input but it returns 0.
Does anyone have an idea why it works 1 way but not the other?
The C call is CvCapture* p = cvCreateFileCapture("C:/Users/****/Downloads/Disturbedloc.avi");
the labview call looks like this:
Load time debugging
If the library call works in one environment but not another, then there's a difference in the environment. There are two main approaches:
Use depends.exe to make sure that opencv has the correct linkage. Perhaps Visual Studio is inspecting opencv for other libraries (like FFMPEG or GStreamer) and adding extra loader instructions to fetch those binaries on launch. LabVIEW, on the other hand, will do a pure dynamic load, and if the library doesn't correctly advertise its dependencies, then those libraries won't be loaded and you'll get a NULL pointer.
Attach Visual Studio to LabVIEW before your VI makes the first call into opencv then watch the Modules window to see if the support libraries are resident in memory. Comparing against your working Visual Studio program would show if any are missing.
Loading missing libraries by force
That run-time linking doesn't work in opencv is a bug in their project. You should report that to them.
You have two workarounds:
Fix the bug, build opencv yourself, and redistribute it with your application.
Call dummy entry points in each dependency to prompt LabVIEW to bring them into the process. Then start calling into opencv.
Once it's working
Since your opencv dll returns a pointer to a struct, you have two options:
Wrap and adapt the opencv library in another C/C++ library so that the inputs/outputs are simpler data types, like numerics.
Use a cluster and some specific Call Library Function node configuration so that LabVIEW can understand the memory layout of the opencv types. NI has a some good documents describing how LabVIEW interfaces with external libraries, but start here: Calling C/C++ DLLs from LabVIEW.
I've just tried and it is working for me.
Here is the front panel:
And the block diagram:
I'm using Labview 2014 and OpenCV 3.0.
I had problems (i.e. 0 returned) with more complex Paths (including spaces, etc.)
I was developing a C based design for someone using Vivado HLS 2015.1.
This design uses the arbitrary precision data types included in "ap_cint.h".
I wanted to know if I could compile this code in a standard gcc compiler by including the relevant header files?
Also can someone point me in the direction of related documentation?
Any help or suggestion would be appreciated.
In 2014.4 I just added include path in eclipse and it does work.
/opt/Xilinx/Vivado_HLS/2014.4/include
Maybe in 2015.i it is same.
(/opt/Xilinx/Vivado_HLS/2014.4/ is my vivado hls home)
Using bare gcc you need to specify include path by -I
in the document UG902 of Xilinx you can find all the information that you need about this topic.
In this case at the page 346 (of the link) there is the chapter High-Level Synthesis C Libraries where, inside, you can find the Arbitrary Precision Data Types Library section.
Vivado uses, that i know, the gcc compiler so, if you are carefull to link the right library, I think that you will never have a problem but I haven't tried yet the same library in Visual Studio (for instance).
Since this is my first question after years of finding answers in this site, id like to say a big thanks to everyone.
I want to use FANN in an embedded platform, and i am using UVision 4 to code in C.
Since i am a C/C++ rookie, i cant figure out if i can / how i can use that library.
When i try to simply include the files, i get this error:
FANN\fann.h(51): error: #5: cannot open source input file "sys/time.h": No such file or directory
which makes sense because i am not compiling for windows platform.
Can i use the FANN library for embedded C? If so, how to include it?
Thanks
You have to write your own "sys/time.h" for your embedded system. It must offer everything the original one does to be compatible with your external library. Wether you write one from scratch or wrap something around an existing code base which is compatible to your embedded device is up to you.
You can also have a look at this SO question.
If you're not compiling on windows you'll have no problem - simply include sys/time.h like this :
#include <sys/time.h>
Note the < and > character, these will make sure that your header is looked up within $PATH.
If your compiler still wont find that header you will need to install libc, on debian this can be done with tools like apt-get
I am using GPU for faster face detection. I have found an acceptable tutorial here. I am using VC10 compiler along with CUDA 4.2. The device is well installed and devicequery passes the tests. I also have written programs in CUDA which leaves me no choice but to say that OpenCV has problems with GPU. The real problem is an access violation when I try to get an instance of CascadeClassifier_GPU. Also, getCudaEnabledDeviceCount returns zero. I have compiled OpenCV with CUDA flag on and there was no serious problem during the compilation only a python interface failed which is absolutely non-relevant to GPU. Is there anyone out there who actually succeeded in running a face detection code with haar features on a GPU with OpenCV? Can you give me a hint about what I am missing?
The problem was with OpenCV CMake. The output directory is assumed to be the /build directory however once you check it, you see that all files in the /build are old. You should gather new dll and lib files from /bin and /lib. This is a major flaw in my opinion since many people will use the old files and think their compile was unsuccessful. Please also note that the CUDA version must be 4.2.9 both SDK and Toolkit once you are building the project. Now GPU module works just fine for me.