When I activate gpu rendering with render type=scanline VRay always fails with “| error: V-Ray rendering failed!” and sometimes freezes Nuke.
When switching to progressive I got this out of the attached setup:
Is this a bug or am I missing something?
lantern_test_v03.nk.zip (2.07 KB)
Can you try updating your gpu drivers and get a latest nightly build?
Seems to be rendering correctly in here.
Cheers,
will do. So using gpu with type scanline does not produce an error for you? I.e. nothing is rendered at all!?
No errors and renders correctly using the latest build and drivers.
sorry for the delay. I just updated to the latest drivers (430.34) but that didn’t help. I can’t see a nightly build for Nuke anywhere, I must be looking in the wrong spot?!
The image you initially sent looks like an legacy fallback renderer which was used somehow if the gpu renderer fails to initialize for some reason - and this reason was usually a problem in the setup/environment failing to load a given shared lib.
If that’s the case, it does not matter which build or driver you are using, the gpu renderer might simply not be loaded at all.
That should be flagged as an error or warning in the log - can you send me that log file (should be in /usr/tmp by default) ?
Are you using an installed version or a zip installation ?
For the nightly build, if you do not have access to the builds under VRay 4.0 for Nuke section, then send our support team an email with your login details and they should fix that.
what is the log file called? there is nothing vray related in /usr/tmp. The terminal does not print any errors while the image is being rendered (or after).
I do have access to nightlies but can’t find a Vray 4 build for Nuke anywhere. Just for Maya, Max and Blender etc and VRay 3 for Nuke.
Yes sorry, it is by default in the default temp directory so /tmp/vray4nuke_log.txt.
Regarding the VRay4, if you see the folder but it is empty, then I think it’s exactly because you do not have yet some kind of access to it.
Ok, I will send an email to support
Ah, found the log file and it says:
[2019/Jul/17|18:34:46] VRayRenderer2 | info: CUDA renderer requested.
[2019/Jul/17|18:34:46] VRayRenderer2 | error: Error loading plugin library “/opt/vray/Nuke_11.3/vray_std/librt_cuda.so”: dlopen failed: libvray_gpu_common.so: cannot open shared object file: No such file or directory
[2019/Jul/17|18:34:46] VRayRenderer2 | info: 1 plugin(s) loaded successfully
[2019/Jul/17|18:34:46] VRayRenderer2 | error: [VUtils::ErrorCode RTRenderer::loadGPUPlugin(VUtils::VRayRenderer &, bool)] Failed to load CUDA renderer plugin from “/opt/vray/Nuke_11.3/vray_std/librt_cuda.so”
Which is weird because it’s right there:
[frank@spiff log]$ ll /opt/vray/Nuke_11.3/vray_std/
total 494500
drwxrwxr-x 3 frank ohufx 4096 Jun 25 17:41 ./
drwxr-xr-x 7 root root 4096 Jun 25 17:49 ../
-rwxrwxr-x 1 frank ohufx 277368 Feb 25 14:55 libcgauth.so*
-rw-rw-r-- 1 frank ohufx 442392 Feb 25 14:56 libcudart.so.9.0
-rw-rw-r-- 1 frank ohufx 302770160 Feb 25 14:55 libcudnn.so.7
-rw-rw-r-- 1 frank ohufx 22408512 Feb 25 14:56 libnvrtc-builtins.so
-rw-rw-r-- 1 frank ohufx 18199288 Feb 25 14:56 libnvrtc.so
-rw-rw-r-- 1 frank ohufx 34995557 Feb 25 14:55 liboptix_denoiser.so.51
-rw-rw-r-- 1 frank ohufx 53526470 Feb 25 14:55 liboptix.so.51
-rwxrwxr-x 1 frank ohufx 28293280 Feb 25 14:55 librt_cuda.so*
-rwxrwxr-x 1 frank ohufx 7493544 Feb 25 14:55 librt_opencl.so*
-rwxrwxr-x 1 frank ohufx 103392 Feb 25 14:55 libvray_gpu_common.so*
-rwxrwxr-x 1 frank ohufx 34755200 Feb 25 14:55 libvray.so*
-rwxrwxr-x 1 frank ohufx 127584 Feb 25 14:55 plgparams.bin*
drwxrwxr-x 4 frank ohufx 4096 Jun 25 17:41 plgparamsdata/
-rwxrwxr-x 1 frank ohufx 396104 Feb 25 14:55 vray.bin*
-rw-rw-r-- 1 frank ohufx 107 Feb 25 14:55 vrayconfig.xml
-rwxrwxr-x 1 frank ohufx 2530904 Feb 25 14:56 vray_gpu_device_select*
My env variables are:
VRAY_FOR_NUKE_11_3_PLUGINS=/opt/vray/Nuke_11.3/nuke_vray
VRAY_RT_GPU_LIBRARY_PATH=/opt/vray/Nuke_11.3/vray_std
LD_LIBRARY_PATH=/opt/vray/Nuke_11.3/nuke_root:/ohufx/pipeline/dlRepo/draft/Linux/64bit
This is a manual zip install and “/opt/vray” is a symlink to “/opt/vray_4.10.01”
Cheers,
frank
Ok I see - yet another loader nightmare… libvray_gpu_common was not there in the previous 3.7 release so it was fine.
In VRay 4 however, it is left to the loader to find it instead of loading it explicitly from a given location.
Simply fix it by adding /opt/vray/Nuke_11.3/vray_std/ to your LD_LIBRARY_PATH variable so that the loader can find libvray_gpu_common.so.
I will also ask our documentation to be fixed as it is still missing that part.
Sorry about that.
awesome, that fixed it, thanks!