Hello all. I have been modifying the sobel filter project from the sdk to work on short data instead of unsigned char data.
I am able to draw an image on the screen. However the fourth time that the display function executes, if I try to step over the following call:
Thanks for the link. I did come across the thread you linked and it did help in my debugging effort. This thread led me to capture the error code and grep the headers to find the enum. I see that program was generating the old 10208 error code.
I any case I found a .ppt somewhere via google. I tried the following modification and it is working better. (Now I am getting an exception in the cleanup funciton when I exit the program via the escape key. I will have to debug this as well.)
This works better for me:
CUDA_SAFE_CALL(cudaGLRegisterBufferObject(pbuffer));
error = cudaGLMapBufferObject((void**)&data, pbuffer);
assert(data != NULL);
Call CUDA Kernel Here
cudaGLUnmapBufferObject(pbuffer);
CUDA_SAFE_CALL(cudaGLUnregisterBufferObject(pbuffer));
This registers and unregisters the pbuffer with every call to display.
randgraham :
Yes you have to register/unregister the buffer before/after the mapping and processing of the PBO.
But I never got the error you mentioned (10205), probably because I was havign the registering code in place.
But have you tried to create more than one PBO at a time? That was where I was getting the 10208 error.
Also, you mention that the error is an ‘old error’. Does that mean you know how to solve it? If so, I would appreciate if you could tell me how to solve it. I have not been able to.
paulius, who was helping me out had told me to check out the multi-threaded glew. I have not tried that yet and have it listed on my white board as a to-do. As soon as I am done with this new thing…
For now, removing the CUDA_SAFE_CALL macro lets me run the program w/o a crash. But I want to get rid of that problem in a better way.
If you try the multi-threaded glew or some other way that solves it , please let me know. Thanks.
I have not gotten the 10208 error. Referring to it as “the old 10208 error” was a bit of humor that didn’t translate well into a forum post. Basically the numbers 10205 and 10208 are meaningless. We know that they are greater than the largest defined enum value. We also know that they are not assigned to any enum value. I can only guess what they mean. The documentation on error handling is limited. What could possibly be causing these errors? How should they be handled?
I have not tried to create more than one PBO.
Let us know how the multi threaded glew investigation turns out. I wouldn’t be surprised if two host threads are trying to access a shared resource on the device. Some kind of mutex might be needed to prevent this. I wouldn’t be surprised if there were some mutex code in the cudaGLRegisterBufferObject library calls. But I am still puzzled why my code was failing on the 4th call.
When propagating driver API error codes, the CUDA runtime (CUDART) adds 10000 (cudaErrorApiFailureBase) to them. So 10205 and 10208 correspond to the driver API error codes CUDA_ERROR_MAP_FAILED and CUDA_ERROR_ALREADY_MAPPED, respectively. MAP_FAILED can happen when the OpenGL driver has resized or relocated the buffer. If you take the time to develop a targeted repro case that causes that error return, please file a bug and we will investigate.
ALREADY_MAPPED happens when you try to map a buffer that has already been mapped; this could be caused by incorrect app code, or app code that isn’t handling an error condition gracefully. But this also could be caused by a driver bug. If you eliminate other possible explanations for the problem, please file a bug.