CUDA 3.0 Bug? Texture inside namespace...

Accelerated Computing CUDA CUDA Programming and Performance
#1

I believe I found a bug in this new nvcc/toolkit. Adding a texture inside a namespace cause errors in cudaMalloc (error 10500), and probably in many other functions. In 2.3 toolkit this works fine.

To reproduce the bug, just add in any .cu file:

[codebox]namespace MyNamespace{

texture<float,1,cudaReadModeElementType> bugTest;

}[/codebox]

Its a runtime bug.

I`ve tested it only on a GTS 360M, sm_12, driver 197.13, visual studio 2008, Windows 7 x64, but running CUDA x86.

Artur Santos.

#2

I see this same bug, except I get error 10500 when trying to register a gl vbo (I do also get it with a lot of other cuda functions)

By just moving my textures outside the namespace everything works fine.

More details:

win7 x64, compiled as x64

sm_13

vs 2008 sp1

#3

I can confirm this bug , moving from CUDA 2.3 to 3.0 gives me ‘unspecified driver error’ with textures inside namespaces.
I’m running ubuntu 9.10

#4

I can confirm the bug as well. I’ve been trying to figure out where the bug was in my code from moving to 2.3 --> 3.0.

I get an error on the cudaMalloc() function if a texture is declared inside any namespace anywhere. Not the easiest error to track down.

(cudaMalloc((void**) &d_ix, bytesToCpy);

e1 = cudaGetLastError();

printf(cudaGetErrorString(e1));

returns “unspecified driver error”

system is win7 x64, sm_13, VS2008, CUDA build rule v3.0.14

#5

I can confirm that the bug also exists in CUDA 3.1b and 3.1 release. Is there any further progress on this bug? Also, since we spent several days tracking down the reason why a single texture declaration ruins the entire program and finally found that it’s compiler bug, I start wondering if there’s any public bug tracker system for CUDA so that we can check it first before wasting time.