Solved Davinci Resolve running on Freebsd using the linuxulator the GPU is working but full

I have managed to get Davinci Resolve running on Freebsd,
using the linuxulator the GPU is working but full


Davinci Resolve is installed using the linuxulator in a ubuntu chroot
and the gpu is working with the dummy-uvm.so by shkhln

using waypipe which like x11 forwarding for wayland

i create a waypipe client socket in the tmp directory inside the ubuntu chroot from the freebsd host
and then run waypipe inside the chroot and connect to the client socket as the server and launch davinci resolve

the display is forwarded over the waypipe socket
and davinci resolve runs as a xwayland rootless window on freebsd

i had to enable xwayland support in dwl my wayland window manager on freebsd

i created a pro res video clip and imported it into davinci resolve
but i couldnt drag the clip into the timeline because i got an error saying the gpu was full

i have installed the same nvidia drivers on ubuntu in the chroot as i have on the freebsd host
nvidia-smi works in the chroot and cuda is also enabled

using the dummy-uvm.so by shkhln we can access the gpu from the chroot


i use LD_PRELOAD in a ~/.zshenv and export the location of the dummy-uvm.so

Code:
export LD_PRELOAD=/home/djwilcox/.config/gpu/dummy-uvm.so

i just need to fix the gpu memory issue
thats the last piece of the puzzle and then we will be able to run Davinci Resolve on Freebsd

if anyone knows what the fix is let me know

when davici resovle is running its listed in the output of the nvidia-smi command on freebsd

in my ~/.login_conf on the freebsd host :memorylocked=unlimited:
Code:
me:\
  :charset=UTF-8:\
  :lang=en_GB.UTF-8:\
  :setenv=LC_COLLATE=C:\
  :memorylocked=unlimited:

i also created the ~/.login_conf.db

launching davinci resolve

freebsd
create the client socket in the ubuntu chroot tmp directory

Code:
waypipe --socket /compat/ubuntu/tmp/waypipe.sock client &

ubuntu chroot launch resolve and forward the display

Code:
waypipe --socket /tmp/waypipe.sock server /opt/resolve/bin/resolve

davinci resolve runs as a xwayland application

so we set the QT_QPA_PLATFORM=xcb in the ~/.zshenv file in the chroot

Code:
export QT_QPA_PLATFORM=xcb

you can also set that option with waypipe

Davinci Resolve launch screen

1-resolve-launch.png


Davinci Resolve running in the ubuntu linuxulator chroot

with the display forwarded over the waypipe socket
davinci resolve runs as a xwayland rootless window on freebsd

Davinci Resolve main interface

2-interface.png


Davinci Resolve settings for Memory and GPU
Showing the GPU and Cuda enabled

3-gpu.png



nvidia-smi run on freebsd showing davici resolve is using the gpu
i forgot to run nv-sglrun nvidia-smi

Code:
nv-sglrun nvidia-smi

which would have shown cuda in the screenshot below

running just nvidia-smi doesnt show cuda in the output
my bad

Code:
nvidia-smi

4-nvidia-smi.png


top running on freebsd
showing the Xwayland rootless window that is displaying davinci resolve

5-top.png
 
Instead of forwarding an application from the linux chroot
you can forward the entire desktop

For instance you can install gnome, kde or another desktop in the linux chroot
and forward the whole desktop and display it as a wayland rootless window on freebsd
 
Showing the GPU and Cuda enabled
Wait... what? Do we have CUDA support via the official Nvidia binaries nowdays?!
Surely limitations imposed by Nvidia's FreeBSD drivers still apply despite running userspace software via linuxulator, correct?

Are you sure that you're running CUDA?
1708354426654.png



(Apologies for ignoring the whole rest of your guide - I appreciate you sharing this - Working CUDA would just open a new can of worms on my end).
 
HI Mate, yes we have cuda support for nvidia on freebsd

my bad i took the screenshot using the wrong command which didnt show cuda

packages installed

Code:
sudo pkg install nvidia-driver linux-nvidia-libs libc6-shim libvdpau-va-gl libva-nvidia-driver

libc6-shim is the magic package

have a look at this page for the fix


heres the steps

make with-glibc-shim writable

Code:
sudo chmod +w /usr/local/bin/with-glibc-shim

edit with-glibc-shim

Code:
sudo vi /usr/local/bin/with-glibc-shim

change line 27 from

Code:
if libdir_suffix == '' && File.exist?("/usr/librt.so.1")

to

Code:
if libdir_suffix == '' && File.exist?("/lib/librt.so.1")

run an application like obs studio and enable cuda

Code:
sh -c 'LD_LIBMAP="`nv-sglrun printenv LD_LIBMAP | grep -v libGL`" obs'

you can also add the code to a desktop entry

Code:
vi ~/.local/share/applications/com.obsproject.Studio.desktop

obs desktop entry for nvenc encoding

Code:
[Desktop Entry]
Version=1.0
Name=OBS
GenericName=Streaming/Recording Software
Comment=Free and Open Source Streaming/Recording Software
Exec=sh -c 'LD_LIBMAP="`nv-sglrun printenv LD_LIBMAP | grep -v libGL`" obs'
Icon=com.obsproject.Studio
Terminal=false
Type=Application
Categories=AudioVideo;Recorder;
StartupNotify=true
StartupWMClass=obs

run nv-sglrun nvidia-smi

Code:
nv-sglrun nvidia-smi

nvidia-smi output on freebsd showing cuda enabled

cuda.png


let me know if you any help getting cuda working

the screenshot above isnt showing anything running just cuda enabled
i just forgot the correct command when i took the screen when resolve was running

yes cuda works from within the linuxulator chroot

i just have some work to do to figure out why the gpu is full with resolve

heres a video with the setup

 
Thank you - This seems very helpful. I am building the necessary packages right now and will report back.

I have a couple of questions on the CUDA side of things but those are not related to Davinci-Resolve.
How would you feel about creating a dedicated HowTo specific to setting up & using CUDA only? That way less knowledgeable people like myself can ask questions there rather than polluting this guide.

SirDice This thread should probably be moved to the HowTo section?
 
Hi Mate, i already posted a guide here about obs nvenc


you can just omit the obs section

not sure the mods would want me to post the same tip as a different post
because then the conversation is happening in multiple places
 
You realize I fixed the typo (and updated the port) way before you posted these instructions, do you?

I originally ran into the issue just before you pushed the update
good to hear that the temporary fix isnt needed any more

ill add an update to my notes that the fix isnt needed any more
but keep it there for reference, sorry for any confusion

im using your dummy-uvm.so in the chroot to access the gpu
nvidia and cuda show up from within the chroot

but im getting gpu full error messages with resolve
even trying to drag a clip into the timeline

do i need to use anything else in combination with the dummy-uvm.so

im using LD_PRELOAD in the ~/.zshenv config file in the chroot to load dummy-uvm.so

Code:
export LD_PRELOAD=/home/djwilcox/.config/gpu/dummy-uvm.so

just wondering if im missing anything

this is a fix i used on fedora using davinci resolve
have to see if that fixes the gpu full error message with resolve

Code:
export __NV_PRIME_RENDER_OFFLOAD=1
export __GLX_VENDOR_LIBRARY_NAME=nvidia

thanks for all your great work
 
but im getting gpu full error messages with resolve
VRAM is full? Pay to attention to the nvidia-smi output, it will either list the offending apps directly or you'll see the increase in consumption when you start them. I run both Firefox and Chromium with software rendering for that very reason.
 
from memory the error was gpu is full
and thats just opening resolve and trying to draging a clip into the timeline

ill try exporting the NV_PRIME_RENDER_OFFLOAD and GLX_VENDOR_LIBRARY_NAME settings
and run resolve again

and take a look nvidia-smi output

waypipe does have a option to turn off the gpu
but id have thought you would want that enabled

Code:
-n, --no-gpu
    Block protocols like wayland-drm and linux-dmabuf which require
    access to e.g. render nodes.

just going to have some pie and mash
and then ill run some test and trying and figure out what the issue is
 
i just added the following code to the ~/.zshenv file in the chroot

Code:
export __NV_PRIME_RENDER_OFFLOAD=1
export __GLX_VENDOR_LIBRARY_NAME=nvidia

now the gpu error message is gone

and i can import footage into the timeline and play it back

no audio yet
i think i need to start pulseaudio on the host

screen shot of big buck bunny pro res footage in the time line

timeline.png
 
trying to figure how to route the audio from chroot to the host using pulseaudio

starting pulseaudio on the host

Code:
pulseaudio --start

doesnt get the audio working

the linux-browser-installer


has a script that look like it starts pulseaudio with a socket


i tried modifying it a bit to see if that would work but no luck

Code:
#!/bin/sh

get_pa_sock_path()
{
    PA_SOCK_PATH=$(sockstat | awk -v me=$(whoami) -F'[ \t]+' '
        $1 == me && $2 == "pulseaudio" && $6 ~ /native/ {
            print $6;
            exit 0
        }'
    )
}

get_pa_sock_path
if [ ! -S "$PA_SOCK_PATH" ]; then
    while killall pulseaudio; do
        sleep 0.5
    done
    pulseaudio --start
    get_pa_sock_path
fi
[ -S "$PA_SOCK_PATH" ] && export PULSE_SERVER=unix:$PA_SOCK_PATH

i suppose what you need is a pulse audio socket in /tmp
that the chroot will be able to access

also im getting a lot of crashes using waypipe to forward the display

not sure if theres an option that can be set the other thing that might cause the issue is the resolve splash screen
the screen that pops up before resolve opens, i remember you had to install some opencl package just for the splash screen

i wonder if disabling the resolve splash screen would help

it maybe that you have to run X11 and use X11 forwarding instead of wayland and waypipe

anyone got an idea on what the X11 command to forward the display from the chroot to the host might look like
 
omg this is huge

i have just come up with a new way to open applications from the chroot on freebsd using xwayland
this can also be used to forward the entire desktop and not just an application

its so simple its brilliant if i do say so myself

i dont like to toot my own horn
but toot, toot

rather than using waypipe
we create a new Xwayland rootfull window on freebsd

Code:
Xwayland :01

that opens a blank window with a display id of :01

then in the chroot in a ~/.zshenv file we add

Code:
export DISPLAY=:1

then in the chroot we open resolve

Code:
/opt/resolve/bin/resolve

and resolve is displayed on freebsd in the Xwayland window

no crashes like with using waypipe

i just need to get the audio working
thats the last piece of the puzzle

if anyone knows how to get pulseaudio working from the chroot
then let me know

screen shots below

xwayland1.png



xwayland2.png
 
Sorry man,but you have created 1000 tutorials. That's not good because its hard to follow 1000 tutorials at a time. Only one,full and well made tutorial is what we need to replicate your steps. Thanks.
 
just found this post about getting pulseaudio working with the choot


Code:
# Use pactl info on host to see server string of pulseaudio
pactl info
Server String: /tmp/pulse-c0nud56S1vuf/native
# chroot into guest
chroot /compat/ubuntu /bin/bash
# switch to user, i created an user with same uid with on host machine
su yusuf
# export PULSE_SERVER variable
export PULSE_SERVER=/tmp/pulse-c0nud56S1vuf/native
# And launch your application. in my case it is minecraft :D

time for tea and biccies

then onto the last piece of the puzzle getting the audio working
 
Not all uses zsh ; can you change the instructions for the users who want to use csh,that's the default shell used by freebsd ? thanks.
 
For the users which use csh,this is the correct procedure to start dwl on 14.0-RELEASE-p3 :

Code:
nano /home/marietto/.xinitrc :

setxkbmap it
set XDG_RUNTIME_DIR="/var/run/user/1001"
exec ck-launch-session dbus-launch --exit-with-session dwl -s 'dwlb -font "monospace:size=16"'
 
I'm trying to install wayfire watching the tutorial below,at minute : 21:07

View: https://www.youtube.com/watch?v=dVNC1z016M8&t=1267s


because I would like to install wayland / wayfire on my FreeBSD 14.0,but it does not work for me (my graphic card is one nvidia GTX 1060).

When I did :

Code:
rot@marietto:/usr/home/marietto # wayfire -c ./config/wayfire/wayfire.ini

II 20-02-24 08:44:06.531 - [src/main.cpp:334] Starting
wayfire version v0.8.0

II 20-02-24 08:44:06.531 - [backend/x11/backend.c:395]
Creating X11 backend

II 20-02-24 08:44:06.531 - [backend/x11/backend.c:478] X11
does not support shared pixmaps

EE 20-02-24 08:44:06.531 - [backend/x11/backend.c:607]
Failed to query DRI3 DRM FD

EE 20-02-24 08:44:06.531 - [src/main.cpp:134] Fatal error:
Segmentation fault

EE 20-02-24 08:44:06.531 - #1  0x363b40 <main+0x1580> at /
usr/local/bin/wayfire

EE 20-02-24 08:44:06.531 - #2  0x82df1d53f
<pthread_sigmask+0x53f> at /lib/libthr.so.3

EE 20-02-24 08:44:06.531 - #3  0x82df1cafb
<pthread_setschedparam+0x83b> at /lib/libthr.so.3

EE 20-02-24 08:44:06.531 - #4  0x820bdc2d3 <???> at ???

EE 20-02-24 08:44:06.531 - #5  0x82210d5d4
<wlr_backend_get_drm_fd+0x4> at /usr/local/wlroots016/lib
/libwlroots.so.11

EE 20-02-24 08:44:06.531 - #6  0x362a3a <main+0x47a> at /
usr/local/bin/wayfire

EE 20-02-24 08:44:06.531 - #7  0x82d23dafa
<__libc_start1+0x12a> at /lib/libc.so.7

full story here :

 
Not all uses zsh ; can you change the instructions for the users who want to use csh,that's the default shell used by freebsd ? thanks.

i cant write instructions for another shell because then i would have to change my shell
and spend time learning that shell to make sure the instructions work

my view is that if your using another shell you would know to use it to set environmental variables, thats quite basic
and if you dont a quick read of the man page, freebsd handbook or a google would clue you in

if i write instructions for csh someone else will want instructions for bash or fish
and ill spend my time writing instructions for basic shell use which people should know

freebsd user arent like window users how have just switched to linux and need everything spelled out
they wouldnt expect to be spoon fed basic instruction they should know or could look up in a couple of minutes

its just a matter of what i spend my time on to get resolve working
and trying to cover every shell that people use isnt a productive use of my time

using open source you expect to do some of the leg work yourself
 
Last edited:
final round

getting pulseaudio working from the chroot to the host

start pulseaudio on the host

Code:
pulseaudio --start

run pactl info

Code:
pactl info

output

Code:
Server String: /var/run/user/1001/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 0
Tile Size: 65472
User Name: djwilcox
Host Name: pollux
Server Name: pulseaudio
Server Version: 16.1
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: oss_output.dsp1
Default Source: oss_input.dsp0
Cookie: 8004:438f

server string

/var/run/user/1001/pulse/native

which is a directory accessible by both the host and chroot

when i run pactl in the chroot after i have started pulseaudio on the host
i get permission denied

both the host and chroot have the same hostname

so either there is some access control with pulseaudio i need to enable to allow access to the server
or its an issue with the chroot
 
NOTE: ziomario edited his posts after my response...

ziomario I would strongly recommend you to check your attitude right now. So far, plenty of us have been considerate enough to keep our mouths shut. You do not want us to start the game of "I have already told you" with you.

NapoleonWils0n A personal advice: Don't get discouraged. Feedback/criticism is always a good thing to accept but sometimes it's worth checking some background history of who's providing such feedback/criticism.
Your efforts are certainly appreciated.

if i write instructions for csh someone else will want instructions for bash or fish
and ill spend my time writing instructions for basic shell use which people should know
The way I personally try to handle this is to only do things that are POSIX compliant and defaulting to /bin/sh for any sorts of scripts. It's not always the nicest or best solution, but I found that to be a suitable path with regards to accessibility, maintenance and portability.
 
Back
Top