wow2006 / cudpp

Automatically exported from code.google.com/p/cudpp
Other
0 stars 0 forks source link

satGL produces a garbled image #10

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Build and run the satGL sample app

What is the expected output? What do you see instead?

Correct output can be seen by running the device emulation version.  In
release or debug builds, instead the results are a green and blue smear.

Original issue reported on code.google.com by harr...@gmail.com on 17 Jun 2009 at 1:57

GoogleCodeExporter commented 9 years ago

Original comment by harr...@gmail.com on 17 Jun 2009 at 2:00

GoogleCodeExporter commented 9 years ago
This only seems to affect 32-bit linux (specifically Ubuntu 8.04 32-bit.  
Ubuntu 8.04
64-bit runs fine).

Original comment by harr...@gmail.com on 17 Jun 2009 at 2:22

GoogleCodeExporter commented 9 years ago
Adding OpSys-OSX tag.  I spent the day debugging on OS X -- in the end I ended 
up
filing an NVIDIA bug, because it appears to be a problem with interop 
(specifically
with float4 textures).

The linux issue still remains.

Original comment by harr...@gmail.com on 24 Jun 2009 at 8:50

GoogleCodeExporter commented 9 years ago
Found and fixed this bug for Linux.  Was a really weird one -- I had a global
variable named "timer" in both main.cpp and satGL.cu.  One was an unsigned int, 
the
other was an array of 3 unsigned ints.  This explains the warning we got on OS X
builds, but there was no warning given by g++ on Linux.

However, somehow this caused the satGL.cu timer[1] location to map to the same
address as the scanPlan handle!  As a result the scans couldn't find their 
handle and
the scans weren't even running!

I don't think this is the issue we are seeing on OS X, but I'm marking 
fixed-verified
and will open a new issue if the OS X problem is not either this or a driver 
bug.

Original comment by harr...@gmail.com on 24 Jun 2009 at 10:17