List of known bugs Collect link to bug reports

Seeing this post:
[url=“http://forums.nvidia.com/index.php?showtopic=46229”]http://forums.nvidia.com/index.php?showtopic=46229[/url]
I come up with the idea that maybe we could build a bug database ourselves here.
That would be useful for work around bugs on ourselves and reduce duplicate reports to nVidia.


I met a problem when writing a “vertex shader”.
[URL=http://forums.nvidia.com/index.php?showtopic=40674]
http://forums.nvidia.com/index.php?showtopic=40674[/url]

A good idea, the bugs I found are

    [*] The first has to do with reading and writing aligned structures to device memory

    http://forums.nvidia.com/index.php?showtopic=44551

    [*] The second has to do with reading constant memory. For some reason in some of my kernels this fails, read out zero or other weird values, unless I prefix the kernel with __synchronizeThreads();

    This one is kind of arcane and I’m not sure exactly when and why they occur. All I did was create a minimal program that still demonstrated the bug to NVidia.

    [*] Under Linux, when you use CUDA in a shared library, and the program terminates you sometimes get a nasty segmentation fault.

    http://forums.nvidia.com/index.php?showtopic=38782&hl=

All of these were reported to NVidia, and are supposedly fixed in the internal development release.

A great idea! Considering that we are somewhat beta-testers here I think the nVidia bug database should be publicly available. This would only be fair.

It took me 2 days to figure this out but I’m experiencing a similar thing when I copy a struct to constant memory and then try to access it from within a kernel. And as my plan was to pass parameters to the kernel with this struct half of the time it crashed my workstation because some values are really off… really really frustrating :(

Aggressive optimization problem (note: Paulius from nVidia claims it’s not a bug, but I consider it useful to post it here):

http://forums.nvidia.com/index.php?showtopic=46732

That may be part of the reason home-brew global mem locks keep failing.

For now, we should only use volatile pointers for loop conditions.

Also note that, in

extern __shared__ int sh[];

sh is not volatile itself.