Your suspicion might be valid, but it I'd prefer if you could verify this
through more standard means too; if you confirm that requesting dynamic
cudart linking is not honored, than there might be an issue in the GROMACS
build system.
BTW, on my binary I built with
I suspect CUDA is not linked dinamically. I'm almost 100% sure.
function cuGetExportTable not supported. Please, report this error to <
supp...@rcuda.net> so that it is supported in future versions of rCUDA.
this function is called when CUDA Runtime is compiled statically.
The ld command is
On Thu, Dec 13, 2018 at 6:07 PM Jaime Sierra wrote:
>
> My cmake config:
>
> ~/cmake-3.13.1-Linux-x86_64/bin/cmake .. -DGMX_BUILD_OWN_FFTW=ON
> -DREGRESSIONTEST_DOWNLOAD=ON -DGMX_GPU=ON
> -DCUDA_TOOLKIT_ROOT_DIR=/nfs2/LIBS/x86_64/LIBS/CUDA/8.0
>
My cmake config:
~/cmake-3.13.1-Linux-x86_64/bin/cmake .. -DGMX_BUILD_OWN_FFTW=ON
-DREGRESSIONTEST_DOWNLOAD=ON -DGMX_GPU=ON
-DCUDA_TOOLKIT_ROOT_DIR=/nfs2/LIBS/x86_64/LIBS/CUDA/8.0
-DCMAKE_INSTALL_PREFIX=/nfs2/opt/APPS/x86_64/APPS/GROMACS/2018/CUDA/8.0
-DCUDA_USE_STATIC_CUDA_RUNTIME=OFF
AFAIK the right way to control RPATH using cmake is:
https://cmake.org/cmake/help/v3.12/variable/CMAKE_SKIP_RPATH.html
no need to poke the binary.
If you still need to turn off static cudart linking the way to do that
is also via a CMake feature:
I'm trying to rewrite the RPATH because shared libraries paths used by
GROMACS are hardcoded in the binary.
ldd /nfs2/opt/APPS/x86_64/APPS/GROMACS/2016/CUDA/8.0/bin/gmx
linux-vdso.so.1 => (0x7ffddf1d3000)
libgromacs.so.2 =>
On Sat, Dec 8, 2018 at 10:00 PM Gmail wrote:
>
> My mistake! It was a typo. Anyway, this is the result before executing
> the chrpath command:
>
> chrpath -l $APPS/GROMACS/2018/CUDA/8.0/bin/gmx
> $APPS/GROMACS/2018/CUDA/8.0/bin/gmx: RPATH=$ORIGIN/../lib64
>
> I'm suspicious that GROMACS 2018 is
My mistake! It was a typo. Anyway, this is the result before executing
the chrpath command:
chrpath -l $APPS/GROMACS/2018/CUDA/8.0/bin/gmx
$APPS/GROMACS/2018/CUDA/8.0/bin/gmx: RPATH=$ORIGIN/../lib64
I'm suspicious that GROMACS 2018 is not being compiled using shared
libraries, at least, for
Hi,
Your final line doesn't match your CMAKE_INSTALL_PREFIX
Mark
On Sun., 9 Dec. 2018, 07:00 Jaime Sierra Hi pall,
>
> thanks for your answer,
> I have my own "HOW_TO_INSTALL" guide like:
>
> $ wget ftp://ftp.gromacs.org/pub/gromacs/gromacs-5.1.4.tar.gz
> $ tar xzf gromacs-5.1.4.tar.gz
> $ cd
Hi pall,
thanks for your answer,
I have my own "HOW_TO_INSTALL" guide like:
$ wget ftp://ftp.gromacs.org/pub/gromacs/gromacs-5.1.4.tar.gz
$ tar xzf gromacs-5.1.4.tar.gz
$ cd gromacs-5.1.4.tar.gz
$ mkdir build
$ cd build
$ export EXTRA_NVCCFLAGS=--cudart=shared
$ export
Hi Jaime,
Have you tried passing that variable to nvcc? Does it not work?
Note that GROMACS makes up to a dozen of CUDA runtime calls (kernels
and transfers) per iteration with iteration times in the range of
milliseconds at longest and peak in the hundreds of nanoseconds and
the CPU needs to
Hi,
my name is Jaime Sierra, a researcher from Polytechnic University of
Valencia, Spain. I would like to know how to compile & install GROMACS
2018 with CUDA features with the "--cudart=shared" compilation option to
use it with our rCUDA software.
We haven't had this problem in previous
12 matches
Mail list logo
