cudaCreateTextureObject problem

I’m trying to use cudaCreateTextureObject with latest JCUDA 0.6.0
And the problem is that it always fails with invalid argument error.

In the example code I’m trying to create cuda texture from existing OpenGL texture. Note that the same code in C++ works like a charm.

//registering gl texture as cuda resource
	_graphRes = new cudaGraphicsResource();
	checkResult(cudaGraphicsGLRegisterImage(_graphRes, glTextureId, Gl.TEXTURE_2D, cudaGraphicsRegisterFlags.cudaGraphicsRegisterFlagsSurfaceLoadStore));	// OK
		
	// mapping resource		
	checkResult(cudaGraphicsMapResources(1, new cudaGraphicsResource[]{_graphRes}, null));// OK

	cudaArray  cuArray = new cudaArray();
	checkResult(cudaGraphicsSubResourceGetMappedArray(cuArray, _graphRes, 0, 0));// OK
		
	cudaExtent  arrayToSize = new cudaExtent();
	checkResult(cudaArrayGetInfo(null, arrayToSize, null, cuArray)); // OK
	width = (int) arrayToSize.width;// OK
	height = (int) arrayToSize.height;// OK
		
        cudaResourceDesc resDesc = new cudaResourceDesc();
        resDesc.resType = cudaResourceType.cudaResourceTypeArray;
        resDesc.array_array = cuArray;		

	cudaTextureDesc texDesc = new cudaTextureDesc();

	texDesc.normalizedCoords = 0;
	texDesc.filterMode = cudaTextureFilterMode.cudaFilterModeLinear;

	texDesc.addressMode[0] = cudaTextureAddressMode.cudaAddressModeClamp;
	texDesc.addressMode[1] = cudaTextureAddressMode.cudaAddressModeClamp;
	texDesc.addressMode[2] = cudaTextureAddressMode.cudaAddressModeClamp;
			
	texDesc.readMode = cudaTextureReadMode.cudaReadModeNormalizedFloat;
			
	_texInput = new cudaTextureObject();
				
	checkResult(cudaCreateTextureObject(_texInput, resDesc, texDesc, null));// FAIL

All previous functions return SUCCESS, width and height are correct.
But only **cudaCreateTextureObject ** returns invalid argument.

And I can’t figure out why…

The texture API is rather complex, and I don’t have a dedicated test case yet for the runtime version of the texture API. I’ll try to have a look at this as soon as possible, but unfortunately, I won’t be able to do this before monday evening (sorry about that), and in fact, I can not really test it, because I don’t have a CC 3.0 device. But maybe I see what may be wrong from looking over the code and creating a test case (regardless of whether I can run it or not).
Sorry for the inconveniences.

I’m digging the JNI code now, may be problem there

BTW surfaces are working without problems

E.g. replacing texture code by this snippet works

checkResult(cudaCreateSurfaceObject(_surfOutput, resDesc));```

OK, this helps to narrow down the search space a bit. I’ve also been looking over the JNI part right now, but did not yet find anything “obvious” (yet). But the structures there are comparatively complex, so I may have overlooked something. I’ll have to examine the getCudaResourceDesc/getCudaTextureDesc part more closely. From a first glance, I think that possible bugs could only hide there (althogh, in the worst case, I’ll have to check whether any initialization from the preceding calls went wrong, even when there was no explicit error…). Just for the record: I assume that you are on Win64, right?

Hi Marco

I’ve found the problems and after fixing them everything is working!

  1. Java_jcuda_runtime_JCuda_cudaCreateTextureObjectNative
    Raw pointer must be replaced by reference
cudaTextureObject_t nativePTexObject;
int result = cudaCreateTextureObject(&nativePTexObject...
  1. *getCudaTextureDesc(JNIEnv env, jobject texDesc)
    This function is not working properly because field cudaTextureDesc_mipmapFilterMode is not initialized

Please add this line

if (!init(env, cls, cudaTextureDesc_mipmapFilterMode,    "mipmapFilterMode",    "I")) return JNI_ERR;

next to other fields

It would be nice having the update soon :slight_smile:
Thanks

OK, that was subtle (but I should have noticed it…)

I’ll try to do the update as soon as possible (as I said, somewhere early next week)!

Thanks for digging this up! ::manklatsch

So this bug has been fixed, and will be available with the next release. (BTW: ```
if (!init(env, cls, cudaTextureDesc_maxAnisotropy, “maxAnisotropy”, “I”)) return JNI_ERR;


The reasons of why I'll probably not create a new "hotfix" release for this bug include
- It seems like you already fixed it locally for you as well
- There are probably not sooo many users who already actively use the CC3.0 features
- The native libs for Linux and Mac have been published only a few days ago - let's wait whether Linux/Mac-Users also encounter errors ;)

And finally, I'd anyhow like to create an updated version where some of the pending tasks have been integrated (Stream Callbacks, maybe? Or the new Xt-libraries?), so maybe I can create an updated version that contains more than a single bugfix. But if more users stumble over this bug (and are not able to fix it on their own), I'll create an "emergency update", of course :)