New error

[Nicholas Dana]

Great work Dr. Fang,

Have been running MCXLAB using a GTX 770 with CUDA 7.0 and no issues.

Recently got access to a new Pascal architecture GPU card. Plopped it in and tried running basic demo scripts. Got this error:

GPU=1 (GeForce GTX 1080) threadph=244 extra=5760 np=10000000 nthread=40960 maxgate=10 repetition=1

initializing streams ... MCXLAB ERROR -13 in unit mcx_core.cu:1185

Error: invalid device symbol

I know that CUDA 7.0 or 7.5 doesn't officially support Pascal architecture. Anyone know if there's a quick fix for this in the source, or is this something that's going to have to wait until CUDA 8.0 is out and tested?

Thanks,

Nich

[Qianqian Fang]

On 07/20/2016 08:46 PM, Nicholas Dana wrote:

Great work Dr. Fang,

Have been running MCXLAB using a GTX 770 with CUDA 7.0 and no issues.

Recently got access to a new Pascal architecture GPU card. Plopped it in and tried running basic demo scripts. Got this error:

wow, you are the first one I know who got hands on a 1080,
congratulations! the stock is so scarce at this point.

GPU=1 (GeForce GTX 1080) threadph=244 extra=5760 np=10000000 nthread=40960 maxgate=10 repetition=1

initializing streams ... MCXLAB ERROR -13 in unit mcx_core.cu:1185

Error: invalid device symbol

I know that CUDA 7.0 or 7.5 doesn't officially support Pascal architecture. Anyone know if there's a quick fix for this in the source, or is this something that's going to have to wait until CUDA 8.0 is out and tested?

did you try the nightly-build?

http://mcx.space/nightly/

they were all compiled with CUDA 7.0 statically linked. If 
you still have this error, I would then try CUDA 8.0 RC.
the download link is here

https://developer.nvidia.com/cuda-release-candidate-download

free registration is needed if you haven't done so. once
downloaded, you then need to recompile mcxlab from source.

if you get it to work, I am very curious how it performs. please
share your GPU benchmark results on this page

http://mcx.space/gpubench/

Qianqian

Thanks,

Nich

--
You received this message because you are subscribed to the Google Groups "mcx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mcx-users+...@googlegroups.com.
To post to this group, send email to mcx-...@googlegroups.com.
Visit this group at https://groups.google.com/group/mcx-users.
For more options, visit https://groups.google.com/d/optout.

[Nicholas Dana]

Thanks Dr. Fang,

We had some money we had to spend and we're trying to use the software to optimize some imaging parameters, so buying the new card seemed like a good option.

I got the nightly build from July 21, 2016. I'm trying to run the demo_mcxlab_basic.m and I'm getting the common error below, without the mcxlab output even displaying on the screen

Output argument "flux" (and maybe others) not assigned during call to "mcxlab".

I've also downloaded both CUDA 8.0 RC. I've navigated to the ../src/ folder in the extracted nightly build folder. I have both Cygwin64 and MinGW on the system. I'm trying to compile from cmd.exe, this is what I'm getting:

E:\Box Sync\Data\mcx\mcx-src-nightly.tar\mcx\src>mingw32-make fermimex

process_begin: CreateProcess(NULL, uname -s, ...) failed.

process_begin: CreateProcess(NULL, uname -s, ...) failed.

process_begin: CreateProcess(NULL, uname -m, ...) failed.

-z was unexpected at this time.

Makefile:166: recipe for target 'cudasdk' failed

mingw32-make: *** [cudasdk] Error 255

E:\Box Sync\Data\mcx\mcx-src-nightly.tar\mcx\src>

And when I try to compile from the same location using the Cygwin64 shell, this is what I get.

HR2@HR2-PC /cygdrive/e/Box Sync/Data/mcx/mcx-src-nightly.tar/mcx/src

$ mingw32-make fermimex

/usr/bin/sh: line 0: [: too many arguments

nvcc -c -lineinfo -Xcompiler -Wall -Xcompiler "/openmp /W0" -DUSE_ATOMIC -use_fast_math -DSAVE_DETECTORS -DUSE_CACHEBOX -use_fast_math -arch=sm_20 -DMCX_TARGET_NAME='"Fermi MCX"' --compiler-options "" -DMCX_CONTAINER -o mcx_core.obj  mcx_core.cu

nvcc fatal   : Cannot find compiler 'cl.exe' in PATH

Makefile:161: recipe for target 'mcx_core.obj' failed

mingw32-make: *** [mcx_core.obj] Error 1

I've tried a mingw32-make clean also, but the results are the same. I'm not very savvy with C/C++, so I apologize if I'm overlooking something obvious. I called nvcc --version to verify, and it's calling version 8.0. This is a total guess, but is it possible the calls in the makefile describing CUGENCODE are incomplete, only going up to compute capability 5.2 (the GTX 1080 is 6.1). 

Anything else I should try?

Thanks!

[Qianqian Fang]

On 07/21/2016 11:49 AM, Nicholas Dana wrote:

Thanks Dr. Fang,

We had some money we had to spend and we're trying to use the software to optimize some imaging parameters, so buying the new card seemed like a good option.

I got the nightly build from July 21, 2016. I'm trying to run the demo_mcxlab_basic.m and I'm getting the common error below, without the mcxlab output even displaying on the screen

Output argument "flux" (and maybe others) not assigned during call to "mcxlab".

hi Nich

unfortunately the nightly build mcxlab for windows has not been set up yet.
so the below folder is empty:
http://mcx.space/nightly/mcxlab/win/

do you have a dual-boot Linux on this machine? if yes, please try the
Linux version

http://mcx.space/nightly/mcxlab/linux/

I've also downloaded both CUDA 8.0 RC. I've navigated to the ../src/ folder in the extracted nightly build folder. I have both Cygwin64 and MinGW on the system. I'm trying to compile from cmd.exe, this is what I'm getting:

E:\Box Sync\Data\mcx\mcx-src-nightly.tar\mcx\src>mingw32-make fermimex

process_begin: CreateProcess(NULL, uname -s, ...) failed.

process_begin: CreateProcess(NULL, uname -s, ...) failed.

process_begin: CreateProcess(NULL, uname -m, ...) failed.

-z was unexpected at this time.

Makefile:166: recipe for target 'cudasdk' failed

mingw32-make: *** [cudasdk] Error 255

E:\Box Sync\Data\mcx\mcx-src-nightly.tar\mcx\src>

compiling mcx/mcxlab on windows is not trivial. here are some notes
I took when I prepared for the 2016.4 release:

http://mcx.sourceforge.net/cgi-bin/index.cgi?Doc/MCXLAB_Compile_Log

I installed cygwin64, and mingw64-x86_64-gcc-g++ as my compiler, similar
to what I used for mmclab.

but I do not suggest you to start with compiling mcxlab. Try compiling
mcx binary using the provided Visual Studio project file should be
your first step.

I tested the Visual studio project with VS 2013 community edition,
you should be able to load the .sln file and build the project.

And when I try to compile from the same location using the Cygwin64 shell, this is what I get.

HR2@HR2-PC /cygdrive/e/Box Sync/Data/mcx/mcx-src-nightly.tar/mcx/src

$ mingw32-make fermimex

/usr/bin/sh: line 0: [: too many arguments

nvcc -c -lineinfo -Xcompiler -Wall -Xcompiler "/openmp /W0" -DUSE_ATOMIC -use_fast_math -DSAVE_DETECTORS -DUSE_CACHEBOX -use_fast_math -arch=sm_20 -DMCX_TARGET_NAME='"Fermi MCX"' --compiler-options "" -DMCX_CONTAINER -o mcx_core.obj  mcx_core.cu

nvcc fatal   : Cannot find compiler 'cl.exe' in PATH

Makefile:161: recipe for target 'mcx_core.obj' failed

mingw32-make: *** [mcx_core.obj] Error 1

I've tried a mingw32-make clean also, but the results are the same. I'm not very savvy with C/C++, so I apologize if I'm overlooking something obvious. I called nvcc --version to verify, and it's calling version 8.0. This is a total guess, but is it possible the calls in the makefile describing CUGENCODE are incomplete, only going up to compute capability 5.2 (the GTX 1080 is 6.1).

according to my student, Fanny (CCed), using -arch=sm_20 should work for
new architectures. But if you use -code=sm_20 -code=sm_52 ...
and do not include sm_61 in your compilation, you will get an error.

Fanny is more experience with nvcc. So feel free to email her for help.

In the visual studio project, go to Project\Properties\CUDA C/C++\Device\Code generation
you can specify what architecture to generate code.

see this online doc for screen captures

https://nvlabs.github.io/moderngpu/faq.html

once you can get mcx binary to run, then we can figure out how to compile for mcxlab.

Qianqian

[Nicholas Dana]

Dr. Fang,

I had been meaning to install Linux on this box, so you convinced me to do that.

Updated drivers (nvidia 367) and downloaded the nightly build.

GPU is recognized with ./mcx -L, but trying to run validation script yields similar results to before.

nd@nd-HR-Mint ~/Downloads/mcx/example/validation $ ./run_validation.sh
###############################################################################
#                      Monte Carlo eXtreme (MCX) -- CUDA                      #
#          Copyright (c) 2009-2016 Qianqian Fang <q.fang at neu.edu>          #
#                             http://mcx.space/                               #
#                                                                             #
#         Computational Imaging Laboratory (CIL) [http://fanglab.org]         #
#            Department of Bioengineering, Northeastern University            #
###############################################################################
#    The MCX Project is funded by the NIH/NIGMS under grant R01-GM114365      #
###############################################################################
$Rev::9b5ee4 $ Last $Date::2016-07-02 17:18:52 -04$ by $Author::Qianqian Fang $
###############################################################################
- variant name: [Fermi] compiled for GPU Capability [100] with CUDA [7000]
- compiled with: RNG [xorshift128+] with Seed Length [4]
- this version CAN save photons at the detectors


GPU=1 (GeForce GTX 1080) threadph=2441 extra=16640 np=100000000 nthread=40960 maxgate=50 repetition=1
initializing streams ...    
MCX ERROR(-13):invalid device symbol in unit mcx_core.cu:1218
Command exited with non-zero status 243
0.02user 0.12system 0:00.16elapsed 91%CPU (0avgtext+0avgdata 105012maxresident)k
0inputs+0outputs (0major+4345minor)pagefaults 0swaps

I'll take a look at recompiling either in Linux or Windows (or both) and let you know how it goes.

Thanks again!

[Qianqian Fang]

good, Linux is easier to trouble shoot.

when you recompile mcx, please use "make fermi" instead of "make".

similarly, for mcxlab, use "make fermimex" (you may need to change
-o to -output for the last mex command).

Qianqian

[Qianqian Fang]

I am sorry, I think "make fermi" will make mcx much slower.

I just committed an update to the Makefile and added the support
for sm_61, you should be able to use

"make xorpas" or "make pascalmex" to compile binaries for your 1080.

https://github.com/fangq/mcx/commit/542223d3fdb2fffaf77a50733e41621813abb5e2
https://github.com/fangq/mcx/commit/88441c6c5320e5d17e6f97845d1982878565e143

the updated Makefile can be downloaded here

https://raw.githubusercontent.com/fangq/mcx/master/src/Makefile

Qianqian

[Nicholas Dana]

Dr. Fang,

Thank you for you/your teams swift replies.

I updated the Makefile, and also submitted a github correction in relation to an error I was getting during compilation (Thank you for the Nsight compiler tutorial, very helpful!!!).

After compilation I was able to execute various example scripts using mcx, everything seems to be working, which is great

When trying to compile a Matlab executable, I'm getting an error:

nd@nd-HR-Mint ~/Downloads/mcx/src $ make xorpas
cc mcx_core.o mcx_utils.o mcx_shapes.o tictoc.o mcextreme.o cjson/cJSON.o -o ../bin/mcx -L/usr/local/cuda/lib64 -lcudart -lm -lstdc++  -fopenmp
mcx_core.o: In function `mcx_list_gpu':
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x37b): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x3e0): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x956): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x9fb): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0xa72): undefined reference to `mexPrintf'
mcx_core.o:tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0xb9e): more undefined references to `mexPrintf' follow
mcx_utils.o: In function `mcx_error':
/home/nd/Downloads/mcx/src/mcx_utils.c:231: undefined reference to `mcx_throw_exception'
mcx_utils.o: In function `mcx_printheader':
/home/nd/Downloads/mcx/src/mcx_utils.c:1387: undefined reference to `mexPrintf'
collect2: error: ld returned 1 exit status
make: *** [../bin/mcx] Error 1

nd@nd-HR-Mint ~/Downloads/mcx/src $ make pascalmex
mex mcx_core.o mcx_utils.o mcx_shapes.o tictoc.o mcextreme.o cjson/cJSON.o -o ../mcxlab/mcxlab -L/usr/local/cuda/lib64 -lcudart -lm -lstdc++ CXXFLAGS='$CXXFLAGS -DSAVE_DETECTORS -DUSE_CACHEBOX -DMCX_CONTAINER -fopenmp -DUSE_XORSHIFT128P_RAND ' -lgomp LDFLAGS='$LDFLAGS -fopenmp ' mcxlab.cpp -cxx -outdir ../mcxlab -I/usr/local/cuda/include
Unknown MEX argument '-o'.
make: *** [../bin/mcx] Error 255
nd@nd-HR-Mint ~/Downloads/mcx/src $

I have Matlab R2016a installed.

[Qianqian Fang]

On 07/22/2016 08:17 PM, Nicholas Dana wrote:

Dr. Fang,

Thank you for you/your teams swift replies.

I updated the Makefile, and also submitted a github correction in relation to an error I was getting during compilation (Thank you for the Nsight compiler tutorial, very helpful!!!).

After compilation I was able to execute various example scripts using mcx, everything seems to be working, which is great

When trying to compile a Matlab executable, I'm getting an error:

the first error after you typed "make xorpas" was a result
of compiling for matlab first and then compiling for mcx
binary without cleaning.

to avoid that error, you need to run

make clean

before you type make xorpas.

nd@nd-HR-Mint ~/Downloads/mcx/src $ make xorpas
cc mcx_core.o mcx_utils.o mcx_shapes.o tictoc.o mcextreme.o cjson/cJSON.o -o ../bin/mcx -L/usr/local/cuda/lib64 -lcudart -lm -lstdc++  -fopenmp
mcx_core.o: In function `mcx_list_gpu':
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x37b): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x3e0): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x956): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0x9fb): undefined reference to `mexPrintf'
tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0xa72): undefined reference to `mexPrintf'
mcx_core.o:tmpxft_000016c8_00000000-4_mcx_core.cudafe1.cpp:(.text+0xb9e): more undefined references to `mexPrintf' follow
mcx_utils.o: In function `mcx_error':
/home/nd/Downloads/mcx/src/mcx_utils.c:231: undefined reference to `mcx_throw_exception'
mcx_utils.o: In function `mcx_printheader':
/home/nd/Downloads/mcx/src/mcx_utils.c:1387: undefined reference to `mexPrintf'
collect2: error: ld returned 1 exit status
make: *** [../bin/mcx] Error 1

nd@nd-HR-Mint ~/Downloads/mcx/src $ make pascalmex
mex mcx_core.o mcx_utils.o mcx_shapes.o tictoc.o mcextreme.o cjson/cJSON.o -o ../mcxlab/mcxlab -L/usr/local/cuda/lib64 -lcudart -lm -lstdc++ CXXFLAGS='$CXXFLAGS -DSAVE_DETECTORS -DUSE_CACHEBOX -DMCX_CONTAINER -fopenmp -DUSE_XORSHIFT128P_RAND ' -lgomp LDFLAGS='$LDFLAGS -fopenmp ' mcxlab.cpp -cxx -outdir ../mcxlab -I/usr/local/cuda/include
Unknown MEX argument '-o'.
make: *** [../bin/mcx] Error 255
nd@nd-HR-Mint ~/Downloads/mcx/src $

the second mex error "-o" is a result of matlab mex change of
command line interface. You need to run the last command as

make clean

make pascalmex

mex mcx_core.o mcx_utils.o mcx_shapes.o tictoc.o mcextreme.o cjson/cJSON.o -output ../mcxlab/mcxlab -L/usr/local/cuda/lib64 -lcudart -lm -lstdc++ CXXFLAGS='$CXXFLAGS -DSAVE_DETECTORS -DUSE_CACHEBOX -DMCX_CONTAINER -fopenmp -DUSE_XORSHIFT128P_RAND ' -lgomp LDFLAGS='$LDFLAGS -fopenmp ' mcxlab.cpp -cxx -outdir ../mcxlab -I/usr/local/cuda/include

notice that the -o option is changed to -output.

let me know if are able to compile and run it.

Qianqian

[Nicholas Dana]

Dr. Fang,

I thought I had already called make clean, my apologies.

I reran both make clean, then make pascalmex, getting the following error

nd@nd-HR-Mint ~/Downloads/mcx/src $ make clean
rm -f mcx_core.o mcx_utils.o mcx_shapes.o tictoc.o mcextreme.o cjson/cJSON.o ../bin/mcx ../bin/mcx_atomic ../bin/mcx_det
nd@nd-HR-Mint ~/Downloads/mcx/src $ make pascalmex
nvcc -c -lineinfo -Xcompiler -Wall -Xcompiler -fopenmp -m64 -DUSE_XORSHIFT128P_RAND -DUSE_ATOMIC -use_fast_math -DSAVE_DETECTORS -DUSE_CACHEBOX -use_fast_math -arch=compute_20 -code=sm_20 -code=sm_30 -code=sm_35 -code=sm_50 -code=sm_52 -code=sm_61 -DMCX_TARGET_NAME='"Fermi MCX"' --compiler-options "-fPIC" -DMCX_CONTAINER -o mcx_core.o  mcx_core.cu
nvcc fatal   : Value 'sm_61' is not defined for option 'gpu-code'
make: *** [mcx_core.o] Error 1

Same error occurs for make clean make xorpas

I verified that the lines in the makefile include the -code=sm_61

pascaloct  pascalmex:  CUGENCODE=-arch=compute_20 -code=sm_20 -code=sm_30 -code=sm_35 -code=sm_50 -code=sm_52 -code=sm_61
...
pascal:     CUGENCODE=-arch=compute_20 -code=sm_20 -code=sm_30 -code=sm_35 -code=sm_50 -code=sm_52 -code=sm_61

Still unable to compile mex.

[Fanny Nina Paravecino]

Hi Nicholas,

According to nvcc, compiling with -arch=compute_20 should generate the IR (PTX) for all compute capabilities (including the recent one sm_61), and when you run mcx, it should create the respective binary for sm_61. So I would say try to compile with just -arch=compute_20 (none sm_xx specified)

Hope this helps.

--

Fanny Nina Paravecino

PhD candidate

Computer Engineering

Northeastern University

[Qianqian Fang]

On 07/23/2016 06:28 PM, Fanny Nina Paravecino wrote:

Hi Nicholas,

According to nvcc, compiling with -arch=compute_20 should generate the IR (PTX) for all compute capabilities (including the recent one sm_61), and when you run mcx, it should create the respective binary for sm_61. So I would say try to compile with just -arch=compute_20 (none sm_xx specified)

Fanny,

I notice using -arch=compute_20 has some problem on Maxwell.

The compiled mcx binary does run across architectures, but for the
980Ti on wazu, the speed of example/run_benchmark1.sh dropped
from 25k photon/ms (when using -code=sm_52) to 1.5k photon/ms
using the git code.

This has no impact to Fermi and Kepler. Maybe we found another
bug in CUDA driver?


Nicholas,

it looks like you were using an older version of nvcc. can you run

nvcc -V

and post the output? sm_61 is only recognized with CUDA 8.0 RC at
this point.

Try Fanny's approach (remove all -code=...  and keep only -arch=compute_20)
first. Then run example/run_benchmark1.sh. If the speed is in the range
of 20k to 30k p/ms, then you don't have the speed issue as on my Maxwell.

If your speed is below 3000 photon/ms, then, you should figure out your
nvcc and make sure you specify -code=sm_61 with cuda 8.

by the way, you can always copy/paste individual commands from
"make" output into a text editor, add or remove flags, and then
paste it to the command window to run the compilation manually.


Qianqian

[Nicholas Dana]

Ok... So I re-downloaded the CUDA 8.0 .run file and installed it on the Linux Mint 17 system. It came with driver 367.61 and I could NOT boot with that driver. Mint kept crashing and going into compatibility mode. So I rolled back to 367.35, but I kept nvcc 8.0. That allowed me to use the GTX 1080 without crashing.

I was able to compile mcxlab using nvcc 8.0 without generating an error by copying

{mex mcx_core.o mcx_utils.o mcx_shapes.o tictoc.o mcextreme.o cjson/cJSON.o -o ../mcxlab/mcxlab -L/usr/local/cuda/lib64 -lcudart -lm -lstdc++ CXXFLAGS='$CXXFLAGS -DSAVE_DETECTORS -DUSE_CACHEBOX -DMCX_CONTAINER -fopenmp -DUSE_XORSHIFT128P_RAND ' -lgomp LDFLAGS='$LDFLAGS -fopenmp ' mcxlab.cpp -cxx -outdir ../mcxlab -I/usr/local/cuda/include}

and replacing -o with -output. The result is mcxlab.mexa64 file in the ../mcxlab folder.

Unfortunately, when I open matlab and try to run demo_mcxlab_basic, I get the following error now

{Invalid MEX-file '/home/nd/Downloads/mcx/mcxlab/mcxlab.mexa64': libcudart.so.8.0: cannot open shared
object file: No such file or directory
 }

I've verified that libcudart.so.8.0 is on my path in the /usr/local/cuda-8.0/lib64 folder. I recompiled and tried again, still got the same result. Error is the same if I just try info = mcxlab('gpuinfo')

[Nicholas Dana]

also, incidentally, I'm getting the same error about the libcudart file if I try to use the executable ../bin/mcx -L

[Qianqian Fang]

On 07/25/2016 01:36 PM, Fanny Nina Paravecino wrote:

Hi Nicholas,

libcudart error is because the environment variable wasn't able to be set properly. Try to check it using:

echo $LD_LIBRARY_PATH

You should get the path of your library something like: /usr/local/cuda-8.0/lib64

If not, please export your environment variable using:

export LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64:$LD_LIBRARY_PATH

Also, you can add the last line to your bash profile so it will be added for each time that you log in to that machine.

here are some notes for seting up for mcx. mcxlab is the same.

http://mcx.sourceforge.net/cgi-bin/index.cgi?Doc/Installation#Running_MCX

[Fanny Nina Paravecino]

Hi Nicholas,

libcudart error is because the environment variable wasn't able to be set properly. Try to check it using:

echo $LD_LIBRARY_PATH

You should get the path of your library something like: /usr/local/cuda-8.0/lib64

If not, please export your environment variable using:

export LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64:$LD_LIBRARY_PATH

Also, you can add the last line to your bash profile so it will be added for each time that you log in to that machine. 

[Nicholas Dana]

I corrected the issues with LD_LIBRARY_PATH. For some reason, even when I define it in the .bash_profile file, it's not recognized, but I explicitly define it for the terminal session and it worked.

Anyway, I recompiled both the mcx binary and the mcxlab binary. When I try to run the demo_mcxlab_basic, I'm getting the same error

{Invalid MEX-file '/home/nd/Downloads/mcx/mcxlab/mcxlab.mexa64': libcudart.so.8.0: cannot open shared
object file: No such file or directory}

However, when I run the binary ../bin/mcx -L, the error is different

{No CUDA-capable GPU device found

MCX ERROR(-1):No GPU device found
 in unit mcextreme.c:37}

I've verified using lspci and glxinfo that it is recognizing the NVIDIA card and that it is using the 367.35 driver (since the 367.61 driver that came with cuda 8.0 wouldn't load on my system).

[Nicholas Dana]

nd@nd-HR-Mint ~/Desktop $ nvidia-smi
Mon Jul 25 13:50:02 2016       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 367.35                 Driver Version: 367.35                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1080    Off  | 0000:01:00.0      On |                  N/A |
|  0%   56C    P5    16W / 240W |    218MiB /  8105MiB |      1%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|    0      1629    G   /usr/bin/X                                     173MiB |
|    0      2481    G   cinnamon                                        42MiB |
+-----------------------------------------------------------------------------+

On Mon, Jul 25, 2016 at 1:40 PM Fanny Nina Paravecino <fninapa...@gmail.com> wrote:

Could you check 

nvidia-smi

This should list GPU cards. What I see is that the CUDA framework is not able to see your card.

[Qianqian Fang]

On 07/25/2016 02:32 PM, Nicholas Dana wrote:

I corrected the issues with LD_LIBRARY_PATH. For some reason, even when I define it in the .bash_profile file, it's not recognized, but I explicitly define it for the terminal session and it worked.

Anyway, I recompiled both the mcx binary and the mcxlab binary. When I try to run the demo_mcxlab_basic, I'm getting the same error

{Invalid MEX-file '/home/nd/Downloads/mcx/mcxlab/mcxlab.mexa64': libcudart.so.8.0: cannot open shared
object file: No such file or directory}

However, when I run the binary ../bin/mcx -L, the error is different

{No CUDA-capable GPU device found

MCX ERROR(-1):No GPU device found
 in unit mcextreme.c:37}

start a new terminal, please let me know the outputs of the
following commands

which nvcc
nvcc -V
echo $SHELL
echo $LD_LIBRARY_PATH

and also

cd /path/to/mcx/bin/
ldd mcx

in the same shell, run "matlab -nojvm", and type

! echo $LD_LIBRARY_PATH
! ldd /path/to/mcx/mcxlab/mcxlab.mexa64

it is likely that you set the LD_LIBRARY_PATH but you
did not restart matlab in a shell with this updated variable
(or log out and log in).

But for the mcx error, I am a bit confused because you said
it was working. But I will have better ideas once I have these
outputs.

Qianqian

--

[Fanny Nina Paravecino]

Interesting. Did you try to run the samples that come with CUDA? They are located at /usr/local/cuda-8.0/samples/

You could try the ./deviceQuery example to test that your GPU is being recognized by CUDA, that sample is located at: /usr/local/cuda-7.0/samples/1_Utilities/deviceQuery

[Fanny Nina Paravecino]

Could you check 

nvidia-smi

This should list GPU cards. What I see is that the CUDA framework is not able to see your card.

[Nicholas Dana]

I compiled the deviceQuery and executed, this is the output.

{nd@nd-HR-Mint /usr/local/cuda-8.0/samples/1_Utilities/deviceQuery $ ./deviceQuery
./deviceQuery Starting...

 CUDA Device Query (Runtime API) version (CUDART static linking)

cudaGetDeviceCount returned 35
-> CUDA driver version is insufficient for CUDA runtime version
Result = FAIL}

[Nicholas Dana]

Dr. Fang,

Apologies for missing your earlier reply. Here is what you requested

"which nvcc

nvcc -V
echo $SHELL
echo $LD_LIBRARY_PATH

nd@nd-HR-Mint ~/Downloads/mcx/bin $ which nvcc
/usr/local/cuda/bin/nvcc
nd@nd-HR-Mint ~/Downloads/mcx/bin $ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2016 NVIDIA Corporation
Built on Wed_May__4_21:01:56_CDT_2016
Cuda compilation tools, release 8.0, V8.0.26
nd@nd-HR-Mint ~/Downloads/mcx/bin $ echo $SHELL
/bin/bash
nd@nd-HR-Mint ~/Downloads/mcx/bin $ echo $LD_LIBRARY_PATH
/usr/local/cuda/lib64
nd@nd-HR-Mint ~/Downloads/mcx/bin $

nd@nd-HR-Mint ~/Downloads/mcx/bin $ ldd mcx
    linux-vdso.so.1 =>  (0x00007fffcbb38000)
    libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007fe8814b3000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe8811ad000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe880ea9000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fe880c9a000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe880a7c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe8806b7000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe8804b3000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe8802ab000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe881714000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe880095000)

Also - for matlab calls:

in the same shell, run "matlab -nojvm", and type

! echo $LD_LIBRARY_PATH
! ldd /path/to/mcx/mcxlab/mcxlab.mexa64

nd@nd-HR-Mint ~/Downloads/mcx/bin $ matlab -nojvm

                            < M A T L A B (R) >
                  Copyright 1984-2016 The MathWorks, Inc.
                   R2016a (9.0.0.341360) 64-bit (glnxa64)
                             February 11, 2016

 
For online documentation, see http://www.mathworks.com/support
For product information, visit www.mathworks.com.
 

    Academic License

>> ! echo $LD_LIBRARY_PATH
/home/MATLAB/R2016a/sys/opengl/lib/glnxa64:/home/MATLAB/R2016a/sys/os/glnxa64:/home/MATLAB/R2016a/bin/glnxa64:/home/MATLAB/R2016a/extern/lib/glnxa64:/home/MATLAB/R2016a/runtime/glnxa64:/home/MATLAB/R2016a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/home/MATLAB/R2016a/sys/java/jre/glnxa64/jre/lib/amd64/server:/usr/local/cuda/lib64
>> ! ldd ~/Downloads/mcx/mcxlab/mcxlab.mexa64
    linux-vdso.so.1 =>  (0x00007ffc6d6f5000)
    libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007fe5a19a0000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe5a169c000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fe5a148d000)
    libmx.so => /home/MATLAB/R2016a/bin/glnxa64/libmx.so (0x00007fe5a10f6000)
    libmex.so => /home/MATLAB/R2016a/bin/glnxa64/libmex.so (0x00007fe5a0ec7000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe5a0bc1000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe5a09ab000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe5a05e6000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe5a03e2000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe5a01c4000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe59ffbc000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe5a1e33000)
    libmwresource_core.so => /home/MATLAB/R2016a/bin/glnxa64/libmwresource_core.so (0x00007fe59fdba000)
    libmwi18n.so => /home/MATLAB/R2016a/bin/glnxa64/libmwi18n.so (0x00007fe59fa96000)
    libut.so => /home/MATLAB/R2016a/bin/glnxa64/libut.so (0x00007fe59f7d4000)
    libmwfl.so => /home/MATLAB/R2016a/bin/glnxa64/libmwfl.so (0x00007fe59f3ce000)
    libboost_chrono.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_chrono.so.1.56.0 (0x00007fe59f1c7000)
    libboost_date_time.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_date_time.so.1.56.0 (0x00007fe59efb7000)
    libboost_filesystem.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_filesystem.so.1.56.0 (0x00007fe59eda2000)
    libboost_log.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_log.so.1.56.0 (0x00007fe59eaca000)
    libboost_regex.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_regex.so.1.56.0 (0x00007fe59e7ac000)
    libboost_signals.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_signals.so.1.56.0 (0x00007fe59e594000)
    libboost_system.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_system.so.1.56.0 (0x00007fe59e391000)
    libboost_thread.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_thread.so.1.56.0 (0x00007fe59e16c000)
    libmwcpp11compat.so => /home/MATLAB/R2016a/bin/glnxa64/libmwcpp11compat.so (0x00007fe59df57000)
    libicudata.so.54 => /home/MATLAB/R2016a/bin/glnxa64/libicudata.so.54 (0x00007fe59c52b000)
    libicuuc.so.54 => /home/MATLAB/R2016a/bin/glnxa64/libicuuc.so.54 (0x00007fe59c19f000)
    libicui18n.so.54 => /home/MATLAB/R2016a/bin/glnxa64/libicui18n.so.54 (0x00007fe59bd50000)
    libicuio.so.54 => /home/MATLAB/R2016a/bin/glnxa64/libicuio.so.54 (0x00007fe59bb43000)
    libtbb.so.2 => /home/MATLAB/R2016a/bin/glnxa64/libtbb.so.2 (0x00007fe59b8f8000)
    libtbbmalloc.so.2 => /home/MATLAB/R2016a/bin/glnxa64/libtbbmalloc.so.2 (0x00007fe59b6a6000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe59b48d000)
    libmwservices.so => /home/MATLAB/R2016a/bin/glnxa64/libmwservices.so (0x00007fe59ad4e000)
    libmwmpath.so => /home/MATLAB/R2016a/bin/glnxa64/libmwmpath.so (0x00007fe59aac5000)
    libmwm_dispatcher.so => /home/MATLAB/R2016a/bin/glnxa64/libmwm_dispatcher.so (0x00007fe59a7cf000)
    libmwmlutil.so => /home/MATLAB/R2016a/bin/glnxa64/libmwmlutil.so (0x00007fe599f71000)
    libexpat.so.1 => /home/MATLAB/R2016a/bin/glnxa64/libexpat.so.1 (0x00007fe599d49000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fe599b10000)
    libboost_serialization.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_serialization.so.1.56.0 (0x00007fe5998aa000)
    libunwind.so.8 => /home/MATLAB/R2016a/bin/glnxa64/libunwind.so.8 (0x00007fe59968b000)
    libssl.so.1.0.0 => /home/MATLAB/R2016a/bin/glnxa64/libssl.so.1.0.0 (0x00007fe599420000)
    libcrypto.so.1.0.0 => /home/MATLAB/R2016a/bin/glnxa64/libcrypto.so.1.0.0 (0x00007fe59903d000)
    libmwdisplay_device.so => /home/MATLAB/R2016a/bin/glnxa64/libmwdisplay_device.so (0x00007fe598e36000)
    libmwregexp.so => /home/MATLAB/R2016a/bin/glnxa64/libmwregexp.so (0x00007fe598bee000)
    libmwsettingscore.so => /home/MATLAB/R2016a/bin/glnxa64/libmwsettingscore.so (0x00007fe598776000)
    libmwms.so => /home/MATLAB/R2016a/bin/glnxa64/libmwms.so (0x00007fe5980c4000)
    libmwnativedisplay.so => /home/MATLAB/R2016a/bin/glnxa64/libmwnativedisplay.so (0x00007fe597eba000)
    libmwopccore.so => /home/MATLAB/R2016a/bin/glnxa64/libmwopccore.so (0x00007fe597c5a000)
    libmwopcmodel.so => /home/MATLAB/R2016a/bin/glnxa64/libmwopcmodel.so (0x00007fe5979d3000)
    libmwopczippackage.so => /home/MATLAB/R2016a/bin/glnxa64/libmwopczippackage.so (0x00007fe5977af000)
    libmwopcmwservices.so => /home/MATLAB/R2016a/bin/glnxa64/libmwopcmwservices.so (0x00007fe5972bb000)
    libmwwebproxy.so => /home/MATLAB/R2016a/bin/glnxa64/libmwwebproxy.so (0x00007fe5970ae000)
    libmwmcos.so => /home/MATLAB/R2016a/bin/glnxa64/libmwmcos.so (0x00007fe596e60000)
    libboost_iostreams.so.1.56.0 => /home/MATLAB/R2016a/bin/glnxa64/libboost_iostreams.so.1.56.0 (0x00007fe596c4c000)
    libCppMicroServices.so.2.1.0 => /home/MATLAB/R2016a/bin/glnxa64/libCppMicroServices.so.2.1.0 (0x00007fe5969b5000)
    libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007fe596792000)
    libPocoCrypto.so.23 => /home/MATLAB/R2016a/bin/glnxa64/libPocoCrypto.so.23 (0x00007fe596570000)
    libPocoFoundation.so.23 => /home/MATLAB/R2016a/bin/glnxa64/libPocoFoundation.so.23 (0x00007fe5961bc000)
    libPocoJSON.so.23 => /home/MATLAB/R2016a/bin/glnxa64/libPocoJSON.so.23 (0x00007fe595f6f000)
    libPocoNet.so.23 => /home/MATLAB/R2016a/bin/glnxa64/libPocoNet.so.23 (0x00007fe595c65000)
    libPocoNetSSL.so.23 => /home/MATLAB/R2016a/bin/glnxa64/libPocoNetSSL.so.23 (0x00007fe595a24000)
    libPocoUtil.so.23 => /home/MATLAB/R2016a/bin/glnxa64/libPocoUtil.so.23 (0x00007fe5957b9000)
    libPocoXML.so.23 => /home/MATLAB/R2016a/bin/glnxa64/libPocoXML.so.23 (0x00007fe59552c000)
    libxerces-c-3.1.so => /home/MATLAB/R2016a/bin/glnxa64/libxerces-c-3.1.so (0x00007fe594ea7000)
    libmwflnetwork.so => /home/MATLAB/R2016a/bin/glnxa64/libmwflnetwork.so (0x00007fe594bc5000)
    libmwflstoragevfs.so => /home/MATLAB/R2016a/bin/glnxa64/libmwflstoragevfs.so (0x00007fe5948ff000)
    libmwflstorageprovider.so => /home/MATLAB/R2016a/bin/glnxa64/libmwflstorageprovider.so (0x00007fe59467f000)
    libmwstorageshlibstoragesys.so => /home/MATLAB/R2016a/bin/glnxa64/libmwstorageshlibstoragesys.so (0x00007fe594436000)
    libmwxmlcore.so => /home/MATLAB/R2016a/bin/glnxa64/libmwxmlcore.so (0x00007fe5941bf000)
    libminizip.so => /home/MATLAB/R2016a/bin/glnxa64/libminizip.so (0x00007fe593fb3000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fe593d8a000)
    libmwflstorageevents.so => /home/MATLAB/R2016a/bin/glnxa64/libmwflstorageevents.so (0x00007fe593b84000)
    libmwstoragesharedlib.so => /home/MATLAB/R2016a/bin/glnxa64/libmwstoragesharedlib.so (0x00007fe59396c000)

I should note that, for whatever reason, the "export LD_LIBRARY_PATH=/usr/local/cuda/lib64" call in /.bash_profile does not seem to execute, though the exact same line executes fine manually, which is what I've been doing.

When ../bin/mcx -L was working previously, it had been compiled with cuda-7.5.17 and driver 367.35, not using cuda-8.0

[Qianqian Fang]

On 07/25/2016 03:30 PM, Nicholas Dana wrote:

Dr. Fang,

Apologies for missing your earlier reply. Here is what you requested

"which nvcc

nvcc -V
echo $SHELL
echo $LD_LIBRARY_PATH

all of these settings look perfectly fine.

However, since you said you were able to compile and run mcx binary
fine with cuda 7.5.17 and driver 367.3, then I don't see why we have to
use CUDA 8.

can you remove cuda 8, and reinstall cuda 7.5.15 and the drive (if it was
changed), and recompile mcx and mcxlab? I suppose if mcx works,
mcxlab should also work with this combination.

if you see both cuda-7.5 and cuda-8.0 folders under /usr/local/, all
you need to do is to run

sudo rm /usr/local/cuda
sudo ln -s /usr/local/cuda-7.5 /usr/local/cuda

once this is done, go to mcx/src and make clean, and recompile
for mcx and mcxlab.

Then you can run my previous commands again. they should
now all point to the correct cuda 7.5 libraries.

if these look ok, you should be able to run the examples for
mcx, as well as the demo scripts in matlab (remember to start
from a shell that defines the correct LD_LIBRARY_PATH).


Qianqian

[Nicholas Dana]

I finally got mcx and mcxlab working with a GTX 1080 in Ubuntu 16.04 using CUDA 8.0 and NVIDIA-367.18 driver.

Here's the steps I took from a fresh install of Ubuntu 16.04 (only offer 64bit version):

1. Download NVIDIA-Linux-x86_64-367.18.run driver file (http://www.geforce.com/drivers/results/103732)
2. Download CUDA Toolkit 8.0 cuda_8.0.27_linux.run file (https://developer.nvidia.com/cuda-toolkit)
3. CUDA 8.0 isn't compatible with gcc-5, so I installed gcc and g++ 4.8 in the following way

gedit /etc/apt/sources.list

Added the following lines at the end of the file

deb http://dk.archive.ubuntu.com/ubuntu/ trusty main universe
deb http://dk.archive.ubuntu.com/ubuntu/ trusty-updates main universe

Save file and run the following:
sudo apt-get update
sudo apt-get install gcc-4.8
sudo apt-get install g++-4.8
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 10
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 10

Verify that the system is using the correct version with gcc --version

5. Close the x-server service in order to install the driver with sudo service lightdm stop
6. Log back in on the command line and navigate to driver location, install with sudo sh ./NVIDIA-Linux-x86_64-367.18.run
7. Complete installation and sudo service lightdm restart if desired
8. Navigate to the location of cuda_8.0.27_linux.run file and sudo sh ./cuda_8.0.27_linux.run to install

IMPORTANT: Do not install the driver version 361 when prompted

9. Complete installation with desired options (samples, links, etc.)
10. Update PATH and LD_LIBRARY_PATH variables to include folder with nvcc and libcuda64, respectively - I did the following:

sudo nano ~/.profile
Added the following lines
PATH=$PATH:/usr/local/cuda-8.0/bin
export PATH
LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64
export LD_LIBRARY_PATH
Save file


11. Reboot and verify settings with the following:
nvcc -V
echo $PATH
echo $LD_LIBRARY_PATH





Quirky thing is that a call to nvidia-smi doesn't recognize the GPU, it lists it as "Graphics Device", but the memory, temperature, etc. appear to be recognized correctly

I'm not proficient with Linux at all, so if there are obvious mistakes or unnecessary steps I've done, feel free to correct me. Hope this helps.

Cheers,

Nich

[Qianqian Fang]

On 08/04/2016 12:50 AM, Nicholas Dana wrote:

I finally got mcx and mcxlab working with a GTX 1080 in Ubuntu 16.04 using CUDA 8.0 and NVIDIA-367.18 driver.

Here's the steps I took from a fresh install of Ubuntu 16.04 (only offer 64bit version):

hi Nich

thanks for sharing this! very encouraging.
I just ordered a 1080 myself, this note will be very helpful.

1. Download NVIDIA-Linux-x86_64-367.18.run driver file (http://www.geforce.com/drivers/results/103732)
2. Download CUDA Toolkit 8.0 cuda_8.0.27_linux.run file (https://developer.nvidia.com/cuda-toolkit)
3. CUDA 8.0 isn't compatible with gcc-5, so I installed gcc and g++ 4.8 in the following way

gcc 4.8 is the default compiler for 14.04. I hope I do not need to
upgrade to 16.04 in order to use the 1080.

gedit /etc/apt/sources.list

Added the following lines at the end of the file

deb http://dk.archive.ubuntu.com/ubuntu/ trusty main universe
deb http://dk.archive.ubuntu.com/ubuntu/ trusty-updates main universe

Save file and run the following:
sudo apt-get update
sudo apt-get install gcc-4.8
sudo apt-get install g++-4.8
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 10
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 10

Verify that the system is using the correct version with gcc --version

5. Close the x-server service in order to install the driver with sudo service lightdm stop
6. Log back in on the command line and navigate to driver location, install with sudo sh ./NVIDIA-Linux-x86_64-367.18.run
7. Complete installation and sudo service lightdm restart if desired
8. Navigate to the location of cuda_8.0.27_linux.run file and sudo sh ./cuda_8.0.27_linux.run to install

IMPORTANT: Do not install the driver version 361 when prompted

I think this is the key.

9. Complete installation with desired options (samples, links, etc.)
10. Update PATH and LD_LIBRARY_PATH variables to include folder with nvcc and libcuda64, respectively - I did the following:

sudo nano ~/.profile
Added the following lines
PATH=$PATH:/usr/local/cuda-8.0/bin
export PATH
LD_LIBRARY_PATH=/usr/local/cuda-8.0/lib64
export LD_LIBRARY_PATH
Save file


11. Reboot and verify settings with the following:
nvcc -V
echo $PATH
echo $LD_LIBRARY_PATH





Quirky thing is that a call to nvidia-smi doesn't recognize the GPU, it lists it as "Graphics Device", but the memory, temperature, etc. appear to be recognized correctly

I'm not proficient with Linux at all, so if there are obvious mistakes or unnecessary steps I've done, feel free to correct me. Hope this helps.


I saw your GPU benchmark results at http://mcx.space/gpubench/
the 1080 is shown as "Graphics Devices", so I suppose the cuda
8.0RC may still have some glitches recognizing the card params.
But the speed is quite encouraging.

Once I receive my 1080, I will work with Fanny to optimize mcx
specifically for the Pascal architecture. Currently it shows a 15%
speed increase from 980Ti (Maxwell), I hope to increase that to
25% as I would expect.

Qianqian


Cheers,

Nich

[Nicholas Dana]

Dr. Fang,

FYI, I tried installing nvidia-367.35 driver, as it supports older cards as well 10 series, but it crashed the entire system and I couldn't recover. Was forced to reinstall. Things are working again, but I would stick to the 367.18 driver for now.

Also, I realized an error in the order I posted above

6. Log back in on the command line and navigate to driver location, install with sudo sh ./NVIDIA-Linux-x86_64-367.18.run

This step should be done BEFORE you switch compilers if you're installing on 16.04. I ran into an error during reinstall when I followed the directions I posted above. When I used gcc-5, the error disappeared. Hopefully won't be a problem if you're using 14.04, though I think there cuda 8.0 documentation discussed some bugs related to 14.04 that aren't an issue in 16.04. Pick your poison...

I saw your GPU benchmark results at http://mcx.space/gpubench/
the 1080 is shown as "Graphics Devices", so I suppose the cuda
8.0RC may still have some glitches recognizing the card params.
But the speed is quite encouraging.

Once I receive my 1080, I will work with Fanny to optimize mcx
specifically for the Pascal architecture. Currently it shows a 15%
speed increase from 980Ti (Maxwell), I hope to increase that to
25% as I would expect.

As far as the speed goes, the benchmark results were pretty impressive, I agree, but some of my personal applications show very little improvement over the 770 I was using previously. I'm surprised by this. Not sure if this is a driver issue, or what. The scripts execute fine, and results are as expected, but the speed is lack luster. Perhaps this is something that can be tweaked with optimization, but if you know of any tweaks I can try, I'd be glad to look into it.

You probably know this, but as an aside, the documents suggested Fermi support has been deprecated as of CUDA 8.0 and will be discontinued in future CUDA versions.

Thanks again,

Nich

[Qianqian Fang]

hi Nich

I received my 1080 in the mail yesterday, and did a test drive with mcx,
already have something interesting to share.

first, I stayed with Ubuntu 14.04. After some struggling, I found the
simplest way to install the 367.35 driver from this post:

https://devtalk.nvidia.com/default/topic/926383/cuda-programming-and-performance/testing-ubuntu-16-04-for-cuda-development-awesome-integration-/post/4937043/#4937043

only 3 commands are needed:

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install nvidia-367 libcuda1-367

I first tried to install the driver using the nvidia .run file,
but I got "can not load nvidia.drm module". I was only able
to install the run file after purging nvidia* in apt-get.
however, after reboot, the driver does not appears to
be active. I then used the above apt-get commands and
the driver installed without any problem.

After installing cuda 8.0RC, and compiling mcx, I made
the following changes to mcx's Makefile:

https://github.com/fangq/mcx/commit/5da546632915a52254f1750b632c7b9119d75058

now one can simply compile mcx using "make" and mcxlab using "make mex".
This will generate architecture independent binaries.

I also fixed the -o bug when compiling mcxlab.

Now, the interesting part starts: when I compiled mcxlab using cuda 8+367.35,
and benchmark it for the 1080, I got a score of 83237 (the score is the sum of
speed, in terms of photon/ms, for the 3 benchmarks).

However, when I changed compiler (and linked libcudart library) from
cuda 8 to 7.5, I found the simulation speed jumped from 83237 to 105861,
a 30% speed increase!

I also tested the combination of cuda 7.5 and 367.35 driver with my Maxwells
(980Ti and Titan X), I found similar improvement of speed (~22%)

You can find the updated results at http://mcx.space/gpubench/
all newly compiled binaries are shown with the label (CUDA7.5-367.35).

Previously, cuda 7.5 behaved poorly with mcx. Fanny and I had reported
a bug to nvidia, and was told there were some driver issues.

https://devtalk.nvidia.com/default/topic/925630/cuda-programming-and-performance/cuda-7-5-on-maxwell-980ti-drops-performance-by-10x-versus-cuda-7-0-and-6-5/1

I am so glad that this driver issue was fixed in 367.x series. Not only the
10-fold slow-down was solved, cuda 7.5 even outperforms cuda 8 by 30%!
(in the case of mcx of course).

With cuda 7.5+367.35 driver, the Pascal vs Maxwell improvement is
around 25%, this is close to what I have expected for the new Pascal
architecture.

On the other hand, Fanny and I might report another issue to nvidia
on cuda 8. We hope it can still have the speed gain from 7.5.

Qianqian

[Elan Somasundaram]

Hi Dr. Fang and Nicholas,

Thanks for this excellent discussion.

I am new to CUDA and MCX. We recently got a dual 1080 workstation and I have been trying to setup and run MCX for the past week. Currently we have WIN10-64bit installed and I managed to compile MCX and MCXLAB with CUDA 8.0 toolkit and Driver Version 368.81. I had to make some changes to the MAKEFILE included in the mcx-nightly distribution and some tweaks in the MEX configuration file before I could successfully compile. I ran the benchmark examples and posted some results here.

The results are not very impressive when compared to the 980's and what Dr.Fang managed to get on his 1080. I tried to go back to CUDA7.5 as suggested by Dr. Fang, but I get a compilation error saying, "sm61 is not a valid gpu-id". Is there any other tweaks I could try to improve performance on Windows, without resorting to UBUNTU ?

I also ran into a peculiar error with MCXLAB. When I run the benchmark problems from command line using the MCX binary, the results seem fine for both single and dual GPU simulations. But, when I use MCXLAB to run the benchmark problems, the single GPU runs yield similar statistics as running from command line, but the dual GPU runs returned an "output absorption fraction is incorrect" error.
I ran some diagnostics and found that the flux values returned for both MCX  (data in the MC2 output file) and MCXLAB (flux.data returned by mcxlab(cfg)) simulations are same, but the "energytot" and "energyabs" variables do not agree for the dual GPU simulations. I am attaching some screenshots of the results. I am wondering if this behavior is caused by some incorrect compilation of the MEX file on my side or there is something I am missing.

Looking forward for your suggestions.

Thanks!

Elan

On Wednesday, July 20, 2016 at 7:46:11 PM UTC-5, Nicholas Dana wrote:

Great work Dr. Fang,

Have been running MCXLAB using a GTX 770 with CUDA 7.0 and no issues.

Recently got access to a new Pascal architecture GPU card. Plopped it in and tried running basic demo scripts. Got this error:

GPU=1 (GeForce GTX 1080) threadph=244 extra=5760 np=10000000 nthread=40960 maxgate=10 repetition=1

initializing streams ... MCXLAB ERROR -13 in unit mcx_core.cu:1185

Error: invalid device symbol

I know that CUDA 7.0 or 7.5 doesn't officially support Pascal architecture. Anyone know if there's a quick fix for this in the source, or is this something that's going to have to wait until CUDA 8.0 is out and tested?

Thanks,

Nich

[Qianqian Fang]

On 08/11/2016 05:36 PM, Elan Somasundaram wrote:

Hi Dr. Fang and Nicholas,

Thanks for this excellent discussion.

I am new to CUDA and MCX. We recently got a dual 1080 workstation and I have been trying to setup and run MCX for the past week. Currently we have WIN10-64bit installed and I managed to compile MCX and MCXLAB with CUDA 8.0 toolkit and Driver Version 368.81. I had to make some changes to the MAKEFILE included in the mcx-nightly distribution and some tweaks in the MEX configuration file before I could successfully compile. I ran the benchmark examples and posted some results here.

hi Elan

yes, I noticed your posted results. wow, dual 1080, that's an
impressive gig for running MCX!

compiling mcx on windows has been somewhat finicky, and that's
why I still haven't set up the nightly build script for windows yet.

I have some notes for my past releases, but I realize every time
I upgrade cuda or gcc/visual studio, I had to re-investgiate, and
it was pretty frustrating

http://mcx.sourceforge.net/cgi-bin/index.cgi?Doc/MCXLAB_Compile_Log

anyways, I am glad that you were able to compile both mcx and
mcxlab on your windows. if you don't mind, I am curious to know
your tweaks, should me a lot to set up the nightly build script on windows.

The results are not very impressive when compared to the 980's and what Dr.Fang managed to get on his 1080. I tried to go back to CUDA7.5 as suggested by Dr. Fang, but I get a compilation error saying, "sm61 is not a valid gpu-id". Is there any other tweaks I could try to improve performance on Windows, without resorting to UBUNTU ?

the error you saw was caused by the -code=sm_61 flag I added for the
pascal targets - it is only supported in cuda 8.

In the commit that I made this morning, I removed all the -code flags,
and only leave the -arch flag, as suggested by my student Fanny earlier:

https://github.com/fangq/mcx/commit/5da546632915a52254f1750b632c7b9119d75058

so either you pull the latest code from github, or wait for tomorrow
to download the nightly build tarball, you can use the new Makefile.
With this update, you can just type "make" to compile for mcx, and
"make mex" for mcxlab with either cuda 7.x or 8. I am sure you
may need to merge with your tweaks for this to work on windows.

if you compile this properly, you should see a full command line close to this:

nvcc -c -lineinfo -Xcompiler -Wall -Xcompiler -fopenmp -m64 -DUSE_ATOMIC -use_fast_math -DSAVE_DETECTORS -DUSE_CACHEBOX -use_fast_math -arch=sm_20 -DMCX_TARGET_NAME='"Fermi MCX"' -DUSE_XORSHIFT128P_RAND -o mcx_core.o  mcx_core.cu

where most -D____ flags are important. If you miss any one of the flags,
you may see a speed drop. The most important one is -DUSE_ATOMIC.
If you do not include this flag, you may get a 2x slowdown! plus you get
less accurate solutions! For pre-fermi cards, such as the one used in the
original MCX paper, the result is just opposite: using atomics gives you a huge
speed penalty (which is thread number dependent). So, make sure you
have that flag in your nvcc line.

Other flags such as -DUSE_XORSHIFT128P_RAND line -use_fast_math will also give
you some 5-10% speed improvement. If you miss them, you will see a
slower mcx executable.

Your reported 1080 speed is about 20% slower than mine result (if using
cuda 8). I want you to double check your compilation commands and make
sure we have enabled all the necessary flags.

I also ran into a peculiar error with MCXLAB. When I run the benchmark problems from command line using the MCX binary, the results seem fine for both single and dual GPU simulations. But, when I use MCXLAB to run the benchmark problems, the single GPU runs yield similar statistics as running from command line, but the dual GPU runs returned an "output absorption fraction is incorrect" error.
I ran some diagnostics and found that the flux values returned for both MCX  (data in the MC2 output file) and MCXLAB (flux.data returned by mcxlab(cfg)) simulations are same, but the "energytot" and "energyabs" variables do not agree for the dual GPU simulations. I am attaching some screenshots of the results. I am wondering if this behavior is caused by some incorrect compilation of the MEX file on my side or there is something I am missing.

in most cases, mcx produces robust outputs which are also repeatable when
using the same RNG seed on the same hardware/thread configurations.

I did notice, when I prepared for the gpu_contest script, on some of
my computers, it may halt, or return prematurely, and produced incorrect
outputs. This should be captured with that "output absorption fraction" test.

This seems to happen randomly, and rarely. I suspect it may due to a unstable
hardware state (you can find out by typing nvidia-smi), or multiple users
submitting jobs to the same card at the same time.

I saw you submitted the dual-GPU benchmark data earlier, I assume you
have get around this error. If you see this error in a consistent and reproducible
way, please let me know, it might be a bug, and I definitely need to fix it.

Let me know if you can fix your 1080 speed. If you manage to do that,
your dual 1080 benchmark will be sitting on the top of the list!

Qianqian

Looking forward for your suggestions.

Thanks!

Elan








On Wednesday, July 20, 2016 at 7:46:11 PM UTC-5, Nicholas Dana wrote:

Great work Dr. Fang,

Have been running MCXLAB using a GTX 770 with CUDA 7.0 and no issues.

Recently got access to a new Pascal architecture GPU card. Plopped it in and tried running basic demo scripts. Got this error:

GPU=1 (GeForce GTX 1080) threadph=244 extra=5760 np=10000000 nthread=40960 maxgate=10 repetition=1

initializing streams ... MCXLAB ERROR -13 in unit mcx_core.cu:1185

Error: invalid device symbol

I know that CUDA 7.0 or 7.5 doesn't officially support Pascal architecture. Anyone know if there's a quick fix for this in the source, or is this something that's going to have to wait until CUDA 8.0 is out and tested?

Thanks,

Nich

--

[Elan Somasundaram]

Thanks for the quick reply Dr. Fang.

The new Makefile worked and with CUDA7.5, my results are on top. Thanks a bunch for saving me from going through the trouble of installing UBUNTU!

I am attaching the edited Makefile  with the tweaks I made and also the screen shots of my compilation.

There is one more tweak I had to make to the mex config file:

1. In Matlab, type: mex -setup c++
2. Open the xml file returned by the above command.
3. Replace  '/MD' flags with '/MT' in the CODEFLAGS variable.
4. This will help to avoid dynamic library vs static library mismatch that happened when compiling MCXLAB using mex and linking to the other source file compiled using nvcc.

Also initially I was constantly getting timed out errors  when I tried to run the example problems, even if I tried to run on a dedicated CUDA GPU and I followed the instructions on this link to modify Windows registry and now everything is stable.

Regarding the MCXLAB error, it happened for all Dual GPU runs and I had to get around it by multiplying 2 to the "flux.stat.energytot" variable in the IF condition for benchmarks 1 and 2. Benchmark 3 does not check for that condition. Sorry, I forgot to include this detail in my previous post.

Thanks,

[Qianqian Fang]

On 08/11/2016 07:36 PM, Elan Somasundaram wrote:

Thanks for the quick reply Dr. Fang.

The new Makefile worked and with CUDA7.5, my results are on top. Thanks a bunch for saving me from going through the trouble of installing UBUNTU!

I am attaching the edited Makefile  with the tweaks I made and also the screen shots of my compilation.

thanks for sharing your mods to the Makefile. I had been using
VS for compiling mcx, but for the past few releases, I switched
to cygwin gcc. It looks compiling with VS seems to be smooth
with your makefile. I will definitely give it a try.

On a side note, I think you should do a "make clean" before
moving to "make -f ... mex". There are a couple of macro
defined for matlab in the .c units, you had to recompile
those with make mex.

Apparently, without those, you can still run mcxlab, but I
guess you will not be able to see the printed outputs
and maybe error handling (such as quitting matlab when
an exception is caught).

There is one more tweak I had to make to the mex config file:

1. In Matlab, type: mex -setup c++
2. Open the xml file returned by the above command.
3. Replace  '/MD' flags with '/MT' in the CODEFLAGS variable.
4. This will help to avoid dynamic library vs static library mismatch that happened when compiling MCXLAB using mex and linking to the other source file compiled using nvcc.

Also initially I was constantly getting timed out errors  when I tried to run the example problems, even if I tried to run on a dedicated CUDA GPU and I followed the instructions on this link to modify Windows registry and now everything is stable.

yes, that trick was also reported by another user previously, and
I put it in the FAQ

http://mcx.sourceforge.net/cgi-bin/index.cgi?Doc/FAQ#I_am_getting_a_kernel_launch_timed_out_error_what_is_that

Regarding the MCXLAB error, it happened for all Dual GPU runs and I had to get around it by multiplying 2 to the "flux.stat.energytot" variable in the IF condition for benchmarks 1 and 2. Benchmark 3 does not check for that condition. Sorry, I forgot to include this detail in my previous post.

that's strange. It is not supposed to happen. I ran the dual-Maxwell
simulation this morning on my Ubuntu box with cuda 7.5 and new driver,
I did not see this problem. I will look into this.

Qianqian

Thanks,

Elan



On Wednesday, July 20, 2016 at 7:46:11 PM UTC-5, Nicholas Dana wrote:

Great work Dr. Fang,

Have been running MCXLAB using a GTX 770 with CUDA 7.0 and no issues.

Recently got access to a new Pascal architecture GPU card. Plopped it in and tried running basic demo scripts. Got this error:

GPU=1 (GeForce GTX 1080) threadph=244 extra=5760 np=10000000 nthread=40960 maxgate=10 repetition=1

initializing streams ... MCXLAB ERROR -13 in unit mcx_core.cu:1185

Error: invalid device symbol

I know that CUDA 7.0 or 7.5 doesn't officially support Pascal architecture. Anyone know if there's a quick fix for this in the source, or is this something that's going to have to wait until CUDA 8.0 is out and tested?

Thanks,

Nich

--

[Elan Somasundaram]

thanks for sharing your mods to the Makefile. I had been using
VS for compiling mcx, but for the past few releases, I switched
to cygwin gcc. It looks compiling with VS seems to be smooth
with your makefile. I will definitely give it a try.

 

I actually wanted to try cygwin+gcc. But, from the nvidia forums, the impression I got is that there is no easy way to instruct nvcc to use a compiler of our choice and by default (in Windows) it uses the cl compiler that comes with VS.  I tried removing VS compiler from the path variable and set the gcc compiler instead, but nvcc throws a compiler missing error. Using the VS compiler does cause an issue with the "sys/ioctl.h " header in  the mcx_utils.c source file. I tried including that file from gcc's include directory, but it threw more header file errors. I read about it and suggestions said to use conio.h. But the function of this header is something to do with the window size to display and so I just commented that header for now and it compiled fine.

 

 

On a side note, I think you should do a "make clean" before
moving to "make -f ... mex". There are a couple of macro
defined for matlab in the .c units, you had to recompile
those with make mex.

Apparently, without those, you can still run mcxlab, but I
guess you will not be able to see the printed outputs
and maybe error handling (such as quitting matlab when
an exception is caught).

Thanks for this tip, I will make a fresh compilation for mex.

Thanks,

Elan

[Nicholas Dana]

Dr. Fang and Elan,

Thanks for the tips and tweaks. I was trying to compile mcxlab in Windows 10 (using VS community 2013) using CUDA 7.5 & driver 368.81. I downloaded MakefileCF from Elan's earlier post and commented out the " #include 'sys/ioctl.h' " as mentioned previously. I tried compiling following Elan's instructions, but I'm getting a silly error. 

HR2@HR2-PC /cygdrive/e/Box Sync/Data/mcx/mcx-src-nightly-20160815/src

$ make clean

rm -f mcx_core.obj mcx_utils.obj mcx_shapes.obj tictoc.obj mcextreme.obj cjson/cJSON.obj ../bin/mcx.exe ../bin/mcx_atomic.exe ../bin/mcx_det.exe

HR2@HR2-PC /cygdrive/e/Box Sync/Data/mcx/mcx-src-nightly-20160815/src

$ make -f MakefileCF mex

MakefileCF:184: warning: overriding recipe for target '../bin/mcx'

MakefileCF:172: warning: ignoring old recipe for target '../bin/mcx'

/bin/sh: line 0: [: too many arguments

nvcc -c -lineinfo -Xcompiler -Wall -Xcompiler "/openmp /W0" -DUSE_ATOMIC -use_fast_math -DSAVE_DETECTORS -DUSE_CACHEBOX -use_fast_math -arch=sm_20 -DMCX_TARGET_NAME='"Fermi MCX"' --compiler-options "" -DMCX_CONTAINER -DUSE_XORSHIFT128P_RAND -o mcx_core.obj  mcx_core.cu

mcx_core.cu

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1333) : warning C4701: potentially uninitialized local variable 'gdebugdata' used

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1333) : warning C4703: potentially uninitialized local pointer variable 'gdebugdata' used

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1296) : warning C4701: potentially uninitialized local variable 'greplayw' used

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1296) : warning C4703: potentially uninitialized local pointer variable 'greplayw' used

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1296) : warning C4701: potentially uninitialized local variable 'greplaytof' used

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1296) : warning C4703: potentially uninitialized local pointer variable 'greplaytof' used

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1232) : warning C4701: potentially uninitialized local variable 'gsrcpattern' used

e:\box sync\data\mcx\mcx-src-nightly-20160815\src\mcx_core.cu(1232) : warning C4703: potentially uninitialized local pointer variable 'gsrcpattern' used

nvcc -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.5\include" -I/c/CUDA/include -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp  -DMCX_CONTAINER -c -o mcx_utils.obj  mcx_utils.c

mcx_utils.c

nvcc -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.5\include" -I/c/CUDA/include -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp  -DMCX_CONTAINER -c -o mcx_shapes.obj  mcx_shapes.c

mcx_shapes.c

nvcc -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.5\include" -I/c/CUDA/include -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp  -DMCX_CONTAINER -c -o tictoc.obj  tictoc.c

tictoc.c

nvcc -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.5\include" -I/c/CUDA/include -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp  -DMCX_CONTAINER -c -o mcextreme.obj  mcextreme.c

mcextreme.c

nvcc -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.5\include" -I/c/CUDA/include -c -D_CRT_SECURE_NO_DEPRECATE -DWIN32 -Xcompiler /openmp  -DMCX_CONTAINER -c -o cjson/cJSON.obj  cjson/cJSON.c

cJSON.c

mex.bat mcx_core.obj mcx_utils.obj mcx_shapes.obj tictoc.obj mcextreme.obj cjson/cJSON.obj -output ../mcxlab/mcxlab -L"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.5\lib\x64" -lcudart mcxlab.cpp -cxx -outdir ../mcxlab -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v7.5\include" -I/c/CUDA/include

'C:\Program' is not recognized as an internal or external command,

operable program or batch file.

make: *** [MakefileCF:184: ../bin/mcx] Error 1

I can't figure out where the "C:/Program ..." call is being made that doesn't use quotes. Any insight is appreciated. Thanks.

[Elan Somasundaram]

Hi Nicholas,

Just to make sure there was'nt any formatting errors in the Makefile I uploaded,  I downloaded it and recompiled the mex file and it compiled successfully on my machine. From the log you reported, it is the mex compilation line that is causing the error.  I think for some reason your mex.bat command is not able to read the spaces in the path correctly. I am wondering if it is due to an older version of Matlab. I am running MATLAB2016a on mine.

Another option is to copy the include and lib directories from "..CUDA\v7.5\" and put it in a folder with no spaces in the path (Ex: C:\CUDAfiles\lib,..\include) and try to compile the mex.bat line from command line by changing just the paths to the new directories. To do this:
         1. Copy the lib and include directories to a new location with no spaces.
         2. In cygwin, run make -f MakefileCF clean, make -f MakefileCF mex
         3. Now, you will get the same error as before.
         4. Now, type the last line starting from "mex.bat " in the error message, but change the paths to the include and lib directories to the new directory where you have copied those files and then compile it.

This is just a workaround to check if mex.bat takes paths with no spaces without changing the Makefile. 

One other simple thing you could do before doing all this is, run dos2unix command on the Makefile and see if the error vanishes. You might have done this already, but I have spent lot of time debugging, only to find that dos2unix is all I needed.

Good luck,

Elan  

[Nicholas Dana]

Dr. Fang and Elan,

I took Elan's advice, following several steps. Eventually resolved with copying to new file location sans spaces (C:\CUDAcopy\v7.5\) and compiled without error. I'm guessing the quotes are getting stripped as the outputs are passed between Cygwin and mex.bat, but you'd both know better than I. Either way, this appears to do the trick.

Incidentally, I'm runing MATLAB R2016a, just as you are. I'm guessing your paths are space-free. If not, no idea why it worked for you as-is, but not myself.

Thanks again for the help!