Matlab is easily reprogrammable but sometimes slow. CUDA is theoretically fast for some applications but is driving me mad lately. I was programming the GPU via OpenGL through the Psichophysics Toolbox from Matlab when I finally realized that there appeared mysterious errors that depended on the computer you were running the software on (available functional code at my web page: CUDA + Matlab).
Now I am using CUDA through MEX files from Matlab but I have reached a dead end.
Does someone know how to compile in debug mode from Matlab? Is it a matter of correctly modifying the nvmex_helper.m file (like adding -deviceemu somewhere)? Is it really possible or the only solution will be to convert all my code into C?
Are you compiling on Windows or Linux?
It should be possible to add the -deviceemu in the compile stage and all the proper libraries during the link stage.
The nvmexopts.bat is apparently already prepared for debugging:
[i]rem ********************************************************************
rem Compiler parameters
rem ********************************************************************
set COMPILER=nvcc
set COMPFLAGS=-c -Xcompiler “/c /Zp8 /GR /W3 /EHsc- /Zc:wchar_t- /DMATLAB_MEX_FILE /nologo”
set OPTIMFLAGS=-Xcompiler “/MD /O2 /Oy- /DNDEBUG”
set DEBUGFLAGS=-Xcompiler “/MD /Zi /Fd”%OUTDIR%%MEX_NAME%%MEX_EXT%.pdb"
set NAME_OBJECT=-o
rem ********************************************************************
rem Linker parameters
rem ********************************************************************
set LIBLOC=%MATLAB%\extern\lib\win32\microsoft
set LINKER=link
rem set LINKER=nvcc
set LINKFLAGS=/dll /export:%ENTRYPOINT% /MAP /LIBPATH:“%LIBLOC%” libmx.lib libmex.lib libmat.lib /implib:%LIB_NAME%.x /MACHINE:X86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
set LINKOPTIMFLAGS=
set LINKDEBUGFLAGS=/DEBUG /PDB:“%OUTDIR%%MEX_NAME%%MEX_EXT%.pdb”
set LINK_FILE=
set LINK_LIB=
set NAME_OUTPUT=/out:“%OUTDIR%%MEX_NAME%%MEX_EXT%”
set RSP_FILE_INDICATOR=@
[/i]
I have made several tial-and-error attempts to put -deviceemu somewhere, but it doesn’t seem to work. Where exactly do I tell the compiler to debug?
Ok, cool, thanks for the tip, it seems to be the correct modification as it doesn’t complain.
However, no printf in global functions appears in the Matlab command line, what am I doing wrong?
And there is yet another question, can I run the code now in debug mode?
I’m using Matlab+CUDA too. I like different solution. I create a dll Microsoft VC++ project and than I can use standrad VC debuger which is fine.
In project You have to include #include “mex.h” only and do export of mexFunction().
Build project with debug (and if You need to debug kernel with deviceemu) settings and set breakpoints.
Than You can use “Attach to Process” (select matlab) and run the function from matlab - now You can play with VC debuger as usually.
If You need pritfs - use mexPrintf as was metioned above.
Not quite sure what the problem is (German isn’t my strong suit and google translator isn’t that great either), but I can say that " the dllexport/dllimport conflict with “clock” and the dropped dllimport/dllexport?" is not related to the problem, as all code I compiled in Matlab ran fine even when that warning appeared.
I would try replacing all functions dependent on the math_functions.h, and removing all references to the header, then add it back later if you really need it.
That is what even I did (removing references to math_functions.h) to solve the problem at least for now. I was getting some other errors (which I do not remember now)…but adding “-c -deviceemu” to DEBUGFLAGS solved that problem for me.
Have you tried using [post=“0”]CUDA MEX - File Exchange - MATLAB Central ? Rather like nvmex, cuda_mex is similar but sets up the environment using the mex environment. I have tried using deviceemu succesfully in a simple example included in this tool, with Visual C++ 2008 and Windows XP, Matlab 2009b.