__constant memory issues

My application for the developer program was accepted. I’m trying to put together a reduced test case at the moment and will submit another bug report with the test case.

stefanw, did NVidia say which driver fixed the problem? Maybe it’s fixed in the (not yet released) OpenCL 1.1 branch.
Anyway, they should really release another OpenCL 1.1 beta. :)

OK, it seems the erratic nature of this problem makes it very hard to make a simple test case… Anyway, I noticed that reordering kernel arguments can fix this problem, especially ordering the arguments by memory space, putting all __constant arguments first, seems to help. Can someone verify?

OK, it seems the erratic nature of this problem makes it very hard to make a simple test case… Anyway, I noticed that reordering kernel arguments can fix this problem, especially ordering the arguments by memory space, putting all __constant arguments first, seems to help. Can someone verify?

I have written a fairly complex OpenCL 1.0 based code that uses lots of __constant memory. It also does a lot of OpenGL sharing. I am running on a Geforce 9800 GT, but not the latest drivers. I have not come across this __constant memory access problem, but I did have to work around other (strange) problems. All my kernels do have the property that the __constant arguments are first.

Here are some the problems:

  1. Non-deterministic OpenGL texture corruption. After using the software for a while, my opengl textures would become corrupted with random data. No GL errors or CL errors would be reported. This problem would persist in my application until I rebooted the computer. The resolution was to make sure each kernel was in a separate CL program object. Anytime I attempted to put multiple kernels into a single program, I would get inevitably get corruption issues.

  2. Build log output. As I changed my kernels, the build log output would change. Sometimes it would be more verbose, sometimes less. I could not determine any reason for the output to var.

I have written a fairly complex OpenCL 1.0 based code that uses lots of __constant memory. It also does a lot of OpenGL sharing. I am running on a Geforce 9800 GT, but not the latest drivers. I have not come across this __constant memory access problem, but I did have to work around other (strange) problems. All my kernels do have the property that the __constant arguments are first.

Here are some the problems:

  1. Non-deterministic OpenGL texture corruption. After using the software for a while, my opengl textures would become corrupted with random data. No GL errors or CL errors would be reported. This problem would persist in my application until I rebooted the computer. The resolution was to make sure each kernel was in a separate CL program object. Anytime I attempted to put multiple kernels into a single program, I would get inevitably get corruption issues.

  2. Build log output. As I changed my kernels, the build log output would change. Sometimes it would be more verbose, sometimes less. I could not determine any reason for the output to var.

Yes, this apparently all boils down to having multiple kernels per program. While it is an acceptable workaround for now to use only one program per kernel, this clearly needs to be fixed.
I also noticed the varying build log verbosity. Looks like the driver does some internal caching?

FYI, I filed a bug with NVidia’s internal bugtracker and they said they’ll look into it. I pointed to this thread for reference.

Yes, this apparently all boils down to having multiple kernels per program. While it is an acceptable workaround for now to use only one program per kernel, this clearly needs to be fixed.
I also noticed the varying build log verbosity. Looks like the driver does some internal caching?

FYI, I filed a bug with NVidia’s internal bugtracker and they said they’ll look into it. I pointed to this thread for reference.

FW 260 beta solved the problem for me, yay ! :))

FW 260 beta solved the problem for me, yay ! :))

Hey,

I tried this test out and its interesting what I found. If I have more than on __constant argument to the same kernel, it works! But, if there is a __constant argument to any other kernel in the file it DOES NOT work! Another thing, if I try to pass a __constant variable to the kernel instead of a __constant pointer (i.e __constant float f instead of __constant float * f), clBuildProgram throws a compile time error! The error is as follows:

1060: error: invalid address space for argument to __kernel function

                                                     __constant float dummy

                                                                            ^

Is this expected??

Hey,

I tried this test out and its interesting what I found. If I have more than on __constant argument to the same kernel, it works! But, if there is a __constant argument to any other kernel in the file it DOES NOT work! Another thing, if I try to pass a __constant variable to the kernel instead of a __constant pointer (i.e __constant float f instead of __constant float * f), clBuildProgram throws a compile time error! The error is as follows:

1060: error: invalid address space for argument to __kernel function

                                                     __constant float dummy

                                                                            ^

Is this expected??

Well, I think we already established that this is one of constant memory related problems. In devdriver 260.24 (CUDA 3.2 Release Candidate) it seems to be fixed, but I am not completely sure about it, since the behavior with earlier drivers was very… random.

That’s not allowed, so it’s expected.

Well, I think we already established that this is one of constant memory related problems. In devdriver 260.24 (CUDA 3.2 Release Candidate) it seems to be fixed, but I am not completely sure about it, since the behavior with earlier drivers was very… random.

That’s not allowed, so it’s expected.