Indeed, “the rest of my code” is 5000+ lines of .cu.in (CUDA with my macros) and a few hundred lines of I (which is a language I invented and have not yet released). Also, legally they don’t belong to me. Otherwise, I’d just post them.
That’s quite unlikely… They’re written in different languages, and compiled to different files (one CUDA exe and one GL dll). The exe doesn’t know a pointer to the GL window class where the texture id is stored.
It’s worth mentioning that I bumped into GL/CUDA memory issues a lot during 0.8. In those days, I used 10+ PBOs and a similar number of CUDA allocations. All of them are doubling vectors. That version of my program works for a few iterations, but never worked enough to produce any useful result. In the end I rewrote the entire thing (which contains loads of geometry shaders) in CUDA and it worked. I haven’t done the same in 1.0 yet.
I’ve been suspecting of some memory management issues with CUDA and some OpenGL functionalities. I would’ve counted on solid texturing and PBO support, because of the SDK examples, but we’ve come to learn that many strange things can happen with CUDA… External Image
As a side note, I was messing with textures with cudaArrays (no OpenGL) and my simple matrix mul kernel would give back bogus results every now and then. For some reason, after I rebuilt the executable (and the planets aligned), the damn thing started to work every single time. :magic: I just sat there and said “whatever…”.
Btw, this test used several kernels in the same .cu. I saw some problems with shared memory in this. Perhaps there are still some hidden bugs in the compiler. If this is your case, you could try separating your kernels and see what happens… who knows…