Easy Question, what compile flag for atomicAdd ?

Accelerated Computing CUDA CUDA Programming and Performance
1

We are using atiomicAdd with float which is supported under CUDA 3.2.

On windows specifying architecture sm_20 is good enough. I need to compile same lib for Linux and seemingly no combination of arch and compute flags gives me what I want –namely a successful build .

Errors look like:

CVA_kernel.cu(212): error: no instance of overloaded function "atomicAdd" matches the argument list

argument types are: (float *, float)

When compute sm_11 is specified or:

CVA_kernel.cu(212): error: identifier "atomicAdd" is undefined

When sm_11 is omitted but sm_20 is specified…

Present Makefile looks like:

# Add source files here

EXECUTABLE      := libfastIRD.so

# Cuda source files (compiled with cudacc)

CUFILES         := dev_host_interface.cu

# C/C++ source files (compiled with gcc / c++)

CCFILES         :=

CU_DEPS         := 

##################################

# Rules and targets 

CUDACCFLAGS     := -arch=compute_11 -code=compute_11,sm_11,sm_13,sm_20

CCFLAGS         := -fopenmp

CXXFLAGS        := -fopenmp 

include ../../common/common.mk

NVCCFLAGS += -Xcompiler -fPIC

CFLAGS += -fPIC -fopenmp

CXXFLAGS += -fPIC -O2 -fopenmp 

LINK += -shared

Can someone please help me fix this makefile, I’m sure it’s something simple…

Tim

2

Floating point atomic add support is only supported for compute 2.0 or greater. You can’t compile code with floating point atomic operations for compute 1.1 targets.

3

Quite right, but if I do not specify sm_11 some where in the Makefile it complains that it does not know about atomicAdd.

In those cases I get

CVA_kernel.cu(212): error: identifier "atomicAdd" is undefined

If I specify sm_20 only, which is what I want, I get the above…

To reformulate the question a little…

Which compile flags should I use to compile atomic functions such as atomicAdd for floating point where Fermi is my target architecture using nvcc 3.2???

4

-arch=sm_20. This is all discussed in some detail in the documentation.

5

Thanks avidday, you have confirmed what I beleive I already know which is why this thing is driving me craaaazy!

Again, my Makefile now looks like:

# Add source files here

EXECUTABLE      := libfastIRD.so

# Cuda source files (compiled with cudacc)

CUFILES         := dev_host_interface.cu

# C/C++ source files (compiled with gcc / c++)

CCFILES         :=

CU_DEPS         :=

##################################

# Rules and targets

CUDACCFLAGS     := -arch=sm_20

CCFLAGS         := -fopenmp

CXXFLAGS        := -fopenmp

include ../../common/common.mk

NVCCFLAGS += -Xcompiler -fPIC

CFLAGS += -fPIC -fopenmp

CXXFLAGS += -fPIC -O2 -fopenmp

LINK += -shared

Which results in:…

[tim@gputestgrid fastCVA]$ make clean; make

IRD_kernel.cu(212): error: identifier "atomicAdd" is undefined

IRD_kernel.cu(269): error: identifier "atomicAdd" is undefined

IRD_kernel.cu(326): error: identifier "atomicAdd" is undefined

IRD_kernel.cu(382): error: identifier "atomicAdd" is undefined

IRD_kernel.cu(457): error: identifier "atomicAdd" is undefined

IRD_kernel.cu(538): error: identifier "atomicAdd" is undefined

6 errors detected in the compilation of "/tmp/tmpxft_0000031f_00000000-10_dev_host_interface.compute_10.cpp1.ii".

make: *** [obj/x86_64/release/dev_host_interface.cu.o] Error 2

[tim@gputestgrid fastIRD]$

What could be going wrong? What can I check?

Thanks

6

If you really want to use the SDK built system (and I would urge you not to), then try running make verbose=1 and see what the compilation statements are. It is likely that one or more of the variables defined in your Makefile is either being ignored or overwritten by the contents of common.mk. That file is a horrible mess that really shouldn’t used for anything outside of the SDK, and even then I question the sanity and technical competence of those who wrote it.

7

Thanks avidday, that’s a good answer. I generally just truat the common.mk file but perhaps I shouldn’t. I will look into it and see what I can find. When I solve this I’ll be sure to post the solution because I can’t beleive I’m the only one to run into this. The machine I’m working with is a more or less clean install on 100% supported software/hardware which is part of the reason it’s driving me mad…

8

RESOLVED

@avidday

You were 100% correct, somewhere in the common.mk file there was indeed a setting over writing my arch=sm_20 argument.

I did a find and replace from sm_10 to sm_20 and now everything works just fine :)