[CMake] CUDA, CMAKE, and an attempt to build nbody
Brian Davis
bitminer at gmail.com
Sat Jan 2 13:26:50 EST 2010
Part 2 - continued from above
<begin rant - skip this if not interested>
Now finding where allocateNBodyArrays is in the files should not be hard,
but then again I am suing Win7. On a REAL os I would use grep. In the
search bar in Win7 I type in allocateNBodyArrays and search NVIDIA SDK and I
wait for Win7 to allow me to select find in files (why this is not an option
in the first place is anyone's guess) and it returns bodysystemcuda.cpp but
not bodysystemcuda.cu. And here is where you gotta love Win7. So I search
all of C: find in files. On a 500 gig drive this takes a while. There is
hope at first when the status bar cruises along to 50% (going through
indexed locations) then the status bar goes to an exponentially decaying
speed. At this point all hope is lost at finding it in the next centry with
Win7. Not only that, but all the windows Lock up at about 99% or so (about
the time the status bar reaches the recycle arrows on the path bar/search
status bar). I can Alt->ctrl->del and launch task manager which never
appears. I can tab between windows, but they are unresponsive. I then
hard reboot the system. "My Idea for Win7 is to have a DO_NOT_SUCK_FLAG to
be passed at boot time". Lets see if MS can implement that one.
Cygwin grep also does not work. And after installing Cygwin worked for
about a week and now startx script crashes just before flashing 3 dos
command windows before giving up the show. "I'm a PC... with Windows, but
not by choice"
<end rant>
This can be found using eclipse or visual studio which can search .cu files
Above errors are due to code in bodysystemcuda.cu:
extern "C"
{
void setDeviceSoftening(float softening)
{
float softeningSq = softening*softening;
cutilSafeCall(cudaMemcpyToSymbol("softeningSquared", &softeningSq,
sizeof(float), 0,
cudaMemcpyHostToDevice));
}
void allocateNBodyArrays(float* vel[2], int numBodies)
{
// 4 floats each for alignment reasons
unsigned int memSize = sizeof( float) * 4 * numBodies;
cutilSafeCall(cudaMalloc((void**)&vel[0], memSize));
cutilSafeCall(cudaMalloc((void**)&vel[1], memSize));
}
...
...
}
and code in bodysystemcuda.cpp:
extern "C"
{
void cudaInit(int argc, char **argv);
void setDeviceSoftening(float softening);
void allocateNBodyArrays(float* vel[2], int numBodies);
void deleteNBodyArrays(float* vel[2]);
...
...
}
So I begin checking build settings (below are the important parts) and
comparing between NVIDIA and CMAKE
NVIDIA:
/OUT:"../../bin/win64/Debug/nbody.exe"
/INCREMENTAL:NO
/LIBPATH:"C:\CUDA\lib"
/LIBPATH:"../../common/lib"
/MANIFEST
/MANIFESTFILE:"x64\Debug\nbody.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/DEBUG
/PDB:"x64\Debug/nbody.pdb"
/SUBSYSTEM:CONSOLE
/DYNAMICBASE:NO
/MACHINE:X64
cudart.lib cutil64D.lib glew64.lib glut64.lib kernel32.lib user32.lib
gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
CMAKE:
/OUT:"C:\projects\NIH2009\source\branches\brian\build\Windows-6.1\ouput\bin\Debug\nbody.exe"
/VERSION:0.0
/INCREMENTAL
/LIBPATH:"C:\NVIDIA Corporation\NVIDIA CUDA SDK\common\lib\Debug"
/LIBPATH:"C:\NVIDIA Corporation\NVIDIA CUDA SDK\common\lib"
/MANIFEST
/MANIFESTFILE:"nbody.dir\Debug\nbody.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/DEBUG
/PDB:"C:/projects/NIH2009/source/branches/brian/build/Windows-6.1/ouput/bin/Debug/nbody.pdb"
/SUBSYSTEM:CONSOLE
/DYNAMICBASE
/NXCOMPAT
/IMPLIB:"C:\projects\NIH2009\source\branches\brian\build\Windows-6.1\ouput\bin\Debug\nbody.lib"
/machine:x64
/debug kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib C:\CUDA\lib\cudart.lib
C:\CUDA\lib\cuda.lib C:\CUDA\lib\cudart.lib "C:\NVIDIA Corporation\NVIDIA
CUDA SDK\common\lib\cutil64D.lib" "C:\NVIDIA Corporation\NVIDIA CUDA
SDK\common\lib\glew64.lib" "C:\NVIDIA Corporation\NVIDIA CUDA
SDK\common\lib\glut64.lib"
So I point CMake to just my CMakeLists.txt file for my nbody project, not
the upperlevel CMakeLists.txt file which add_subdirectory the nbody
CMakeList.txt file.
What I get is an executable and the follwoing text when it is run (answer to
why it compiled is forthcoming):
"The application has failed to start because its side-by-side configuration
is incorrect. Please see
the application event log or use the command-line sxstrace.exe tool for more
detail."
Anyone who has seen this error has to appreciate the obscurity that is
Windows. Translated: "I can't find my DLLs"
So I launch in as Administrator by (right clicking the command window Icon -
<begin rant> must be done from start menu as we sure would'nt want this
feature/option at the "Pined" Icons on the task bar <end rant>) and I
preform the following:
C:\Windows\system32>cd
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug>sxstrace
WinSxs Tracing Utility.
Usage: SxsTrace [Options]
Options:
Trace -logfile:FileName [-nostop]
Enabling tracing for sxs.
Tracing log is saved to FileName.
If -nostop is specified, will not prompt to stop tracing.
Parse -logfile:FileName -outfile:ParsedFile [-filter:AppName]
Translate the raw trace file into a human readable format and save
the result to ParsedFile.
Use -filter option to filter the output.
Stoptrace
Stop the trace if it is not stopped before.
Example: SxsTrace Trace -logfile:SxsTrace.etl
SxsTrace Parse -logfile:SxsTrace.etl -outfile:SxsTrace.txt
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug> SxsTrace Trace
-logfile:SxsTrace.etl
Tracing started. Trace will be saved to file SxsTrace.etl.
Press Enter to stop tracing...
I then run nbody.exe and then I do:
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug>SxsTrace Parse
-logfile:SxsTrace.etl -ou
tfile:SxsTrace.txt
Parsing log file SxsTrace.etl...
Parsing finished! Output saved to file SxsTrace.txt.
Which gives me in SxsTrace (<begin rant>why MS has to take a good idea,
strace, and turn it into this convoluted process of convolution is anyone's
guess <end rant>):
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = AMD64
CultureFallBacks = en-US;en
ManifestPath =
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\nbody.exe
AssemblyDirectory =
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\
Application Config File =
-----------------
INFO: Parsing Manifest File
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\nbody.exe.
INFO: Manifest Definition Identity is (null).
INFO: Reference:
Microsoft.VC90.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"
INFO: Resolving reference
Microsoft.VC90.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
INFO: Resolving reference for ProcessorArchitecture amd64.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at
C:\Windows\assembly\GAC_64\Microsoft.VC90.DebugCRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT.MANIFEST.
INFO: Attempt to probe manifest at
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at
C:\projects\NIH2009\source\branches\brian\build\nbody\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.MANIFEST.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
ERROR: Cannot resolve reference
Microsoft.VC90.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
ERROR: Activation Context generation failed.
End Activation Context Generation.
And here is where the developer learns of MS Manifesto files.
Now an answer to why it compiled in the first place: Default Build settings
were overrided in CMakeLists.txt file above (in upper level directory)
project file for nbody. I have an opinion (yea I know doesn't everyone) as
to the logic of linking project build settings to directory hierarchy. Why
relate one abstract thing, directory structure, to another abstract thing,
project settings. This can cause the developer to layout their directory
structure so that it plays nice with the build tool. Which ok may not be a
bad thing, but the two should kept separate. Bjam did the same thing and I
always questioned the logic of this. At least BJam (and maybe CMake as well
- I did try this and ran into the CMake policy issue) allowed to put project
files out on leaves of the trees instead of at branches for example:
At branches:
project->Jamfile.v2
project->subDir1->Jamfile.v2
project-->subDir2->subDir2->Jamfile.v2
At Leaves
project->build->Jamfile.v2
project->subDir1->build->Jamfile.v2
project-->subDir2->subDir2->build->Jamfile.v2
Then project settings could be inherited through specification of inherited
projects not by inherited directory structure of Jamfiles as the inheritance
structure was broken by the Leaf ends. Is there such a thing as Project
Inheritance specification within CMake?
There were some great things about BJam in this regard:
1) project structure could be made completely independent from directory
structure.
2) Projects and settings could be inherited through specification.
3) The project specification could completely remap the build directory
structure, see CMake Policy reference below:
For instance when I change:
add_subdirectory( source/cpp cpp_source )
to:
add_subdirectory( source/cpp ./ )
I get:
CMake Warning (dev) at CMakeLists.txt:128 (add_subdirectory):
Policy CMP0013 is not set: Duplicate binary directories are not allowed.
Run "cmake --help-policy CMP0013" for policy details. Use the
cmake_policy
command to set the policy and suppress this warning.
The binary directory
C:/projects/NIH2009/source/branches/brian/build/dvip4-Win64
is already used to build a source directory. This command uses it to
build
source directory
C:/projects/NIH2009/source/branches/brian/source/cpp
which can generate conflicting build files. CMake does not support this
use case but it used to work accidentally and is being allowed for
compatibility.
This warning is for project developers. Use -Wno-dev to suppress it.
FULL_FILE_PATH = platform/3rdParty/Win32/dcmtk/dcmtk-3.5.4.zip
UNPACK_DIRECTORY = source/cpp/lib/3rdParty/Win32
Well that was my experience, some issues with Win7, some issues with CMake,
and some issues with me not understanding what CMake does and doesn't do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100102/5a19c072/attachment.htm>
More information about the CMake
mailing list