Linux Binary compatibility - Nvidia Drivers and CUDA for Blender

linuxnunix

New Member

Reaction score: 1
Messages: 7

Hi!

I've managed to run Blender 2.79 for Linux x64 in FreeBSD 11.1 with Binary compatibility "linux-c7" in a virtual QEMU machine.
My question is if it is possible to install the latest 390.25 Nvidia Drivers and CUDA 9.1 within the FreeBSD compatibility layer for Blender's Cycles render engine?
Native FreeBSD does not include a working CUDA package. I can't test this in a virtual machine and i may switch to FreeBSD if this is possible.
Has anyone tried this or would i waste my time testing this on my native Desktop machine?
 

Snurg

Daemon

Reaction score: 580
Messages: 1,349

Thank you shkhln for that information!
I guess suspend/resume can be fixed using the older driver, as 390 broke that, too.
Luckily one can download a few older drivers like 375.66 here: http://www.nvidia.com/drivers/beta
(I downloaded 375.66 just in case Nvidia stops keeping it available for download soon)
 

shkhln

Daemon

Reaction score: 904
Messages: 2,113

drhowarddrfine

Son of Beastie

Reaction score: 2,101
Messages: 4,111

I've managed to run Blender 2.79 for Linux x64 in FreeBSD 11.1 with Binary compatibility "linux-c7" in a virtual QEMU machine.
I'm not on my machine but blender can be installed from ports on FreeBSD without all that.
My question is if it is possible to install the latest 390.25 Nvidia Drivers
Yes. nVidia supports FreeBSD.

The CUDA stuff I can't comment on.
 
OP
L

linuxnunix

New Member

Reaction score: 1
Messages: 7

Thanks for the answers. It's CUDA what prevents me to install FreeBSD because i use Blender a lot and render times are much faster with CUDA.
For now i stay with Archlinux but i may try Binary compatibility + CUDA at some point.
 

shkhln

Daemon

Reaction score: 904
Messages: 2,113

Ok, I managed to run OpenGL and Vulkan under 64-bit linuxulator with 384.111 driver by registering nvkms ioctls (in addition to the patch in the issue 206711) and then decided to test CUDA.

Code:
% nvcc -o test -lcuda test.c
% truss ./test
...
linux_newstat("/usr/bin/nvidia-modprobe",0x7fffffffc930) ERR#-2 'No such file or directory'
linux_open("/dev/nvidia-uvm",0x80002,00)     ERR#-2 'No such file or directory'
linux_open("/dev/nvidia-uvm",0x2,00)         ERR#-2 'No such file or directory'
linux_ioctl(0xfffffffe,0x30000001,0x7fffffffc9e0) ERR#-9 'Bad file descriptor'
linux_ioctl(0xfffffffe,0x30000002,0x0)         ERR#-9 'Bad file descriptor'
close(-2)                     ERR#-9 'Bad file descriptor'
linux_newfstat(1,0x7fffffffcfe0)         = 0 (0x0)
linux_mmap2(0x0,0x1000,0x3,0x22,0xffffffffffffffff,0x0) = 34366578688 (0x800686000)
cuInit failed: 999
write(1,"cuInit failed: 999\n",19)         = 19 (0x13)
linux_exit_group(0x1)      
process exit, rval = 1

It seems to be probing nvidia-uvm, which is not present in the FreeBSD driver. That part (a kernel module) of the Linux driver appears to be fully open-source because I don't see any precompiled objects lying around and should in principle be possible to port, but there is likely zero interest in that. I can't imagine FreeBSD devs doing that work. Maybe stubbing a few things here and there would be sufficient in practice, we'll see.
 
Last edited:

shkhln

Daemon

Reaction score: 904
Messages: 2,113

It's NVidia that supplies the code. So it's NVidia that needs to do the work.
Don't get me wrong, I agree this is Nvidia's responsibility, however at this point CUDA is a 10 years old technology and it never has been available for FreeBSD natively. It is pretty clear they just don't care.
 

Snurg

Daemon

Reaction score: 580
Messages: 1,349

It's NVidia that supplies the code. So it's NVidia that needs to do the work.
The FreeBSD devs doing the video stuff knew for years that vesa.ko and newcons() break Nvidia suspend/resume, and instead of fixing that, they recommend to use AMD/ATI because "Nvidia makes problems".
So, why should Nvidia care?
 

shkhln

Daemon

Reaction score: 904
Messages: 2,113

they recommend to use AMD/ATI because "Nvidia makes problems"

To be fair, Mesa has a public bugtracker. Nvidia is a bunch of jerks in comparison. Yeah, they have more capable hardware, more performant and less buggy drivers, extremely competent people, whatever. But can you actually check whether your suspend/resume problem has been reported to them? Nope.
 

pbp_jackd

Member

Reaction score: 7
Messages: 48

Hi!

I've managed to run Blender 2.79 for Linux x64 in FreeBSD 11.1 with Binary compatibility "linux-c7" in a virtual QEMU machine.
My question is if it is possible to install the latest 390.25 Nvidia Drivers and CUDA 9.1 within the FreeBSD compatibility layer for Blender's Cycles render engine?
Native FreeBSD does not include a working CUDA package. I can't test this in a virtual machine and i may switch to FreeBSD if this is possible.
Has anyone tried this or would i waste my time testing this on my native Desktop machine?
How did you manage to start the linux binary of blender ?
At least in my tests with Blender 2.91 I always get:
Code:
Error! Unsupported graphics card or driver.
A graphics card and driver with support for OpenGL 3.3 or higher is required.
The program will now close.

glxinfo for compat gives me OpenGL version 2.1, which according to the error message is definetly a problem.
Code:
 LIBGL_ALWAYS_SOFTWARE=1 /compat/linux/bin/glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 7.0, 128 bits)
OpenGL version string: 2.1 Mesa 18.3.4
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.3.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

vs. the results with "FreeBSD Mesa"

Code:
glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon RX 5700 XT (NAVI10, DRM 3.35.0, 13.0-CURRENT, LLVM 10.0.1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.2.3
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.2.3
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
 
Last edited by a moderator:
OP
L

linuxnunix

New Member

Reaction score: 1
Messages: 7

Since Blender version 2.80 it requires OpenGL 3.3. You can try 2.79, it should work with OpenGL 2.1.
And i think i had to disable Blender Sound output with a parameter. (./blender -noaudio)
 

pbp_jackd

Member

Reaction score: 7
Messages: 48

Since Blender version 2.80 it requires OpenGL 3.3. You can try 2.79, it should work with OpenGL 2.1.
And i think i had to disable Blender Sound output with a parameter. (./blender -noaudio)
Blender 2.79b works. Thank you. But pitty, I need 2.9.

Just wondering if anyone knows a way to make linux mesa report a higher OpenGL version ?
 

kpedersen

Son of Beastie

Reaction score: 1,753
Messages: 2,622

I generally fall back to LLVMpipe (which is software rendering but supports up to OpenGL 4.x). Unless you have any really complex models it should work.

$ LIBGL_ALWAYS_SOFTWARE=1 blender

Frankly I am getting a little sick of Blender. It is either getting too "professional" for me or it is starting to be pulled apart by many commercial companies trying to push their agenda and incorrect decisions. All I know is it is changing too much (they broke the Blender Render which was great for easy shadowmap baking), trying to look like Maya too much and consuming too much hardware.

(Annoyingly this was further exacerbated by the Linux Intel drivers dropping support for OpenGL 2.1 on my slightly older GMA 965 GPU. FreeBSD seems to have gotten affected by the upstream but OpenBSD oddly didn't).

As a small side project I have been bastardizing a Quake III level editor to make it work as a generic modeller just because I can see Blender becoming a pain in the butt in future (http://thamessoftware.co.uk/openradiant)
 

kpedersen

Son of Beastie

Reaction score: 1,753
Messages: 2,622

I imagine LIBGL_ALWAYS_SOFTWARE=1 has something to do with it.

The software renderer (LLVMpipe) should give more than 2.1
On a machine I haven't updated for a while I get:

Code:
    Max core profile version: 3.3
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 8.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.8
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

Though perhaps the Mesa in linux compat is old?
 

pbp_jackd

Member

Reaction score: 7
Messages: 48

Why do you want a Linux binary in the first place?


I imagine LIBGL_ALWAYS_SOFTWARE=1 has something to do with it.
I was hoping I could OpenCL somehow working with the Linux Version and get GPU rendering this way in Blender. Did not think the whole concept through though. Just starting here and then solve the next issue and so on.

I'm also using Darktable quite a bit and GPU rendering would be very welcome too.

It seems to me it all depends on clover getting image support implemented and there is https://bugs.freedesktop.org/show_bug.cgi?id=87738 and a couple of other bugs but with no visible progress.

For Blender I was also wondering if one could somehow get https://www.amd.com/en/technologies/radeon-prorender to work this way. Most likly not because they say it requires the AMD drivers but yeah, that is what I was after.

About LIBGL_ALWAYS_SOFTWARE=1.
If I run glxinfo withouth the variable set it gives me this:
Code:
/compat/linux/bin/glxinfo  | grep version               
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: amdgpu_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: amdgpu
libGL error: pci id for fd 4: 1002:731f, driver (null)
pci id for fd 5: 1002:731f, driver (null)
libGL error: failed to create dri screen
libGL error: failed to load driver: radeonsi
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
 
Last edited by a moderator:

shkhln

Daemon

Reaction score: 904
Messages: 2,113

So, you want OpenCL libs from AMDGPU-Pro? Otherwise this doesn't make any sense.
 

pbp_jackd

Member

Reaction score: 7
Messages: 48

So, you want OpenCL libs from AMDGPU-Pro? Otherwise this doesn't make any sense
I don't if that is the only way. But yes I have read somewhere that it should be possible to extract those from the AMD driver.
 

pbp_jackd

Member

Reaction score: 7
Messages: 48

It is, but that's beside the point. Although, now that I think of it, it might have some problems working with the newest AMD cards.
Just happend to stumble over https://phoronix.com/scan.php?page=news_item&px=AMD-Navi-RADV-Mesa-19.2 today.
Without checking mesa git repo yet you might be right that mesa 18.3 as in linuxlator today is missing some bits to support Navi10 cards.

Just wondering if building mesa head from git and putting it into linuxlator would be any good ?
 

kpedersen

Son of Beastie

Reaction score: 1,753
Messages: 2,622

In this case, would the LIBGL_ALWAYS_INDIRECT stuff work? This should just send the OpenGL drawing commands outside of the Linux compat to then be rendered natively on the FreeBSD Mesa (which does have working AMD GL drivers).

The problem is, I can't recall the last time I saw indirect rendering actually working.
 
Top