It might take a little more effort to sort out exactly how to refine the documentation (and potentially container recipes also) to try to get the containers not only working with mrview, but using manufacturer device drivers when doing so. (Frankly I was content at the time to get it working with something better than software rendering and no terminal warnings or errors...)

Currently the only Linux system I have access to is a laptop with dual GPU (Intel integrated + NVidia) and I have had multiple failed attempts to get Optimus working. I had a go with 3.0.4 and got the following:

When building image using Singularity recipe:

singularity run -B /run MRtrix_3.0.4_fromsingularity.sif mrview
(runs, but uses Intel GPU)

singularity run -B /run --nv MRtrix_3.0.4_fromsingularity.sif mrview
INFO:    underlay of /usr/bin/nvidia-smi required more than 50 (398) bind mounts
mrview: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /.singularity.d/libs/libGLdispatch.so.0)
mrview: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /.singularity.d/libs/libGLX.so.0)

When building Singularity image from dockerhub:

singularity run -B /run MRtrix_3.0.4_fromdockerhub.sif mrview
dbus[35071]: D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to open "/var/lib/dbus/machine-id": No such file or directory; Failed to open "/etc/machine-id": No such file or directory)
  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

I'd rather confirm on a non-Optimus system before committing to changes. I'll also have another go at Optimus on this system...

I think this change may in fact be wrong.

It proposes that a user replace:

    singularity run -B /run MRtrix3.sif mrview

with:

    singularity run --nv /run MRtrix3.sif mrview

However path /run is still intended to be the input argument to the -B option. The --nv option doesn't consume a command-line entry.