- 4. April 2019 at 22:26 #20419
Following my last message, I tried something: I ran bforartsist2 from the command line, so to see any warning printed to the stderr output, and it did pay !
When opening the Preferences panel, I get:
which: no nvcc in (/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/games:/usr/games)
Meaning bforartsist2 is searching for the NVIDIA CUDA compiler and, not finding it (which is normal, since I don’t have the CUDA toolkit installed), prints an empty list of CUDA devices in the Preferences panel… This does not happen with either blender v2.80 or bforartsist1.
So, I created a fake nvcc (I created a /usr/local/bin/nvcc link to /bin/true), and, miracle, bforartsist2’s Preferences panel now does find my graphics card, as well as my CPU (it did not even find the latter with nvcc missing while it’s not related in any way with it !)…
So there. Something went amiss in the Preferences panel UI code, that causes this useless check (since Cycles can still use CUDA devices without the help of the CUDA nvcc compiler anyway)…5. April 2019 at 5:46 #20420
Good catch. I am still lost here though what is missing and what we could do. I have no linux
EDIT, have you ticked WITH_CUDA_DYNLOAD in cmake? MoxFulder guesses that this could be related here. But could be also totally unrelated.
I wish i would have a bit more clue about Linux :’35. April 2019 at 8:06 #20421
Yes, I have the following Cycles-related options in the cmake command line:
-DWITH_CUDA_DYNLOAD=ON -DWITH_CYCLES=ON -DWITH_CYCLES_OSL=ON -DWITH_CYCLES_DEVICE_CUDA=ON -DWITH_CYCLES_DEVICE_OPENCL=ON
I also do observe that the nvidia-uvm module gets loaded as soon as I select CUDA in the “Cycles render devices” radio-buttons of the Preferences panel in bforartists2 (and 1, and blender), even without the fake nvcc trick. So, it does seem to dynamically load CUDA.
Note however that the fake nvcc trick is still insufficient for rendering with the GPU (bforartists2 complains it cannot get the nvcc version, which is normal since it’s just /bin/true that is actually executed) which, again, does not happen with v1 or blender.
So, I also ‘grep’ped the sources for “nvcc” and found an option that might have explained it and I recompiled, adding -DWITH_CYCLES_CUBIN_COMPILER=ON, but to no avail (it does not change anything at all)…21. May 2019 at 22:40 #20502
I uploaded the RPM packages for Bforartists 2 alpha 4 on my site.
Like for former Bforartists2 alpha releases, CUDA-capable devices are still not detected/usable (see my former messages about it: same problem with alpha 4).22. May 2019 at 5:39 #20503
Thanks a bunch24. May 2019 at 14:35 #20513
I just talked to my linux friends that use Blender. Blender won’t run the CUDA GPU right up automatically like Windows. They run a code: primusrum in the executable to make the machine startup the GPU. Maybe that is why it’s not really activatin CUDA in linux?
:dance:24. May 2019 at 15:56 #20514MoxFulderKeymaster
- Posts 23
This is required for a specific setup, where you have an Intel and a Nvidia GPU.
@linuxdev: Is that the case for your hardware setup?27. May 2019 at 23:02 #20525
No, my main computer got the IGP disabled at Linux kernel level, so it’s plain CPU + NVIDIA GPU: no mix-up (plus, the CPU is a 2500K which got an IGP that is too old to use with OpenCL Intel drivers).
Note also that neither blender v2.80 nor Bforartists1 got any trouble to find and use my NVIDIA GPU as a CUDA device. There is a bug in Bforartists2, obviously (read my former messages for my findings)…28. May 2019 at 1:41 #20526
Ah. Maybe I’ll do a virtual machine and install Manjaro or something and give it a whirl. i’ve been curious of Linux, but haven’t had a need to use it. What does the crash feel like? It just.. hangs when trying to render on GPU?
:dance:30. May 2019 at 9:47 #20527
What crash ?… There is no crash. Bforartists 2 simply fails to find and use the GPU.30. May 2019 at 16:46 #20528
Ah, so you can select the GPU but it does nothing? Or you can’t even activate the GPU via the UI because it just won’t show?
It seems my drivers for Nvivida is a bit difficult to make it work in my Virtual Box, and so I’ve got limited driver troubleshooting… hmm.. what other way could I trouble shoot.
:dance:30. May 2019 at 19:01 #20530
Please… Read my previous posts, where I describe the issue in details (and even with screen shots)… The CUDA backend is not detected by bforartists2 while it is for bforartists1 (when compiled in the exact same way on the same machine) and blender.
I also found out why; read my previous post “Hint about the GPU detection bug” about the bogus call to nvcc (nvcc, which is part of the CUDA toolkit used by developpers should not be needed at all and is certainly not needed with blender and bforartist1).
As for using a Linux VM to diagnose the bug, it is a bad idea since those VMs do not give access to the bare metal GPU (which is virtualized instead). You should try and boot from live Linux DVD (or USB key). You could even use a PCLinuxOS DVD and install the RPM packages both bforartists 1 and 2 from my site to reproduce the issue.30. May 2019 at 21:06 #20531
Yeah. I came late to the party. I’ll try a live USB drive next time.
:dance:5. June 2019 at 19:14 #20542
I just uploaded Bforartists 2 alpha 5 for PCLinuxOS on my site together with some updated libraries (OpenColorIO, OpenVDB and OSL) which needed a recompilation since the boost libraries they depend upon have been updated in PCLinuxOS. I also recompiled Bforartist v1, for the same reason.
Note: the CUDA device detection bug is still present in Bforartists 2 alpha 5.6. June 2019 at 5:57 #20543
And we have still no idea where this comes from, sorry
- You must be logged in to reply to this topic.