Nvidia Optimus Driver for FreeBSD

My point is that GLVND is marginally useful but neither significantly helps nor hinders the work that is needed.

I'm not talking about libglvnd usefulness for your work. It is relevant to you in a sense that you have to support both libglvnd and legacy configurations, whether libglvnd is actually useful to you is not for me to decide.

From the perspective of FreeBSD project, what does GLVND accomplish?

Libmap overrides are static, while libglvnd selects appropriate OpenGL implementation dynamically. That doesn't seem like much, but once you actually tried to explain to multiple people why OpenGL applications break on Intel GPU with nvidia-driver port installed (with zero success rate in my case), it's pretty clear that this functionality is indeed necessary.

430.40 needs libglvnd somewhere; it doesn't have to be /usr/local/lib/libGL.so.1.

Yes, I know that, otherwise I wouldn't refer to nvidia-driver shenanigans.
 
Requirement of the actual libGL implementation to explicitly support GLVND (and inability of such an implementation to work without GLVND once it supports it) seem like serious design bugs in GLVND itself, but what can we do?

Let's take a closer look. Both legacy libGL.so.430.40 and GLVND-enabled libGLX_nvidia.so.430.40 from the 430.40 Linux driver have the same size in bytes, although they are not exactly identical. Swapping one for another seems to work fine in either direction. Whatever explicit support there exists for libglvnd, it likely consists of some very subtle changes, if any.

This might or might not work for 390.x FreeBSD drivers.
 
Last edited:
Can someone explain me why the cpu sky rocks when i start the optirun service ? It won't start automatically and if i start it manually the cpu and gpu fans go crazy. I have to stop the service to fix it.

ANy ideas
 
Looks like I should be moving ahead on bringing my ports up to date with everyone's contributions and ready for PR on the assumption that PR 232645 is stalled indefinitely.

Libmap overrides are static, while libglvnd selects appropriate OpenGL implementation dynamically. That doesn't seem like much, but once you actually tried to explain to multiple people why OpenGL applications break on Intel GPU with nvidia-driver port installed (with zero success rate in my case), it's pretty clear that this functionality is indeed necessary.

What I meant by suggesting GLVND is unnecessary is this:

The only reason nvidia-driver port "needs" to break Mesa libGL graphics is libmap and nothing more. Libmap is needed because otherwise the user would need LD_LIBRARY_PATH. Now, what about a hybrid graphics system? Some change of environment is always needed to select the other device, no matter whether it is "optirun" command or an environment variable such as DISPLAY or DRI_PRIME. Then, something like LD_LIBRARY_PATH is not such a big deal (and software such as VirtualGL and Bumblebee have worked fine without GLVND). Sure, GLVND becomes very useful when a single application wants to use multiple devices. But in that case it is reasonable to explicitly build the application against it, rather than to use GLVND system-wide.

So long as the default Mesa libGL configuration on FreeBSD doesn't use GLVND, I certainly wouldn't try to enable it just to make Nvidia happy.

So, it should be possible to move forward with everything that previously was working (64-bit freebsd, 64-bit linux, and 32-bit linux OpenGL apps on Nvidia through VirtualGL) without making any special accommodation for GLVND's new layers.
 
I am currently taking some time to work on this. As I start, here is a list of what I plan to change/add:
  • Rename nvidia_headless_xorg to nvidia_xorg
  • Add kmod load to service startup
  • Add nvidia vs. nvidia-modeset option
  • Add ConnectedMonitor and UseEDID options to nvidia xorg conf template
  • Add port option to symlink "optirun" to nvrun-vgl
  • Test nvrun-vgl with x11/linux-virtualgl to graphically run Linux apps (I've had this working in the past)

Did I miss anything important? In particular I don't want to be leaving out any critical features of Pouya's port.
 
Update: I've got this all done with the exception of the Linux compat, but I need to figure out what changed that nvidia-headless-driver is once again replacing Xorg's libglx.so with its own.
 
Ah, I forgot about that one. It has been renamed to libglxserver_nvidia.so, however my patch still keeps the bit that copies it over Xorg's libglx.so for a smaller diff to 390.87.
 
It's a little thing, but the name "headless" for the ports is bothering me, and I think maybe I should call it "secondary" or something else. So "nvidia-headless-driver" becomes "nvidia-secondary-driver". I bring it up now because once it is committed as a port the name will never change.

Right now, the only direct use of nvidia-headless-driver is by a headless Xorg process (hence the name), but with PRIME that could change.

So, with the principle difference between the two driver ports being that one asserts itself as the default GL/GLX provider (conflicting with Intel) and the other does not, how best to name the new driver port?
 
@Theron Tarigo

Testsetup:
OS: FreeBSD 13.0-CURRENT
Ports: ports version head ( 2019-11-18)
Graphics Card: MX150
Device: Huawei Matebook X Pro

Thumb Up! Just tested against ports head as of today using your 440 branch. The only minor hickup was that I had to reboot after the installation was done due nvrun-vgl wasn't able to run an X server on display :8 . Just tested nvrun-vgl command so far.

Would love to see you bringing this into the portstree. Keep up with the good work. :)

Thank you and also shkhln !
 
After installation: did you service nvidia_xorg (one)start before trying nvrun(-vgl), and it still did not work until reboot?

I myself am not having such a good experience with it since switch to 440.x (these problems never existed before):
  • Having Nvidia loaded prevents suspend from working (it seems to start to suspend but bounces); having nvidia not loaded prevents it from working after suspend until a dance with acpi_call and more suspend/resumes to unstick its power state.
  • Nvidia Xorg seems to "fall asleep" causing all users of it to suffer very low performance until I use x11vnc to send input to the server, then it recovers. Maybe someone knows there is an Xorg config or command option to fix this?

Granted, if this is the best Nvidia can do, and it doesn't implicate a problem with the port itself, I guess there is nothing I can do but complain to Nvidia and wait for an update.

Just barely relevant: Firefox worked flawlessly with VirtualGL until some recent versions, now a webpage creating a WebGL context hangs the browser more often than not. It's distressing to see a major app break compatibility with the only currently working solution on FreeBSD for piping graphics from one GPU to another.
 
Theron Tarigo
After installation: did you service nvidia_xorg (one)start before trying nvrun(-vgl), and it still did not work until reboot?
I did do that. I guess irrelevant but there was no nvidia driver installed before on this system.

Having Nvidia loaded prevents suspend from working (it seems to start to suspend but bounces); having nvidia not loaded prevents it from working after suspend until a dance with acpi_call and more suspend/resumes to unstick its power state.
No issue witht that so far. zzz or closing the lid just works. Resuming also does work without any noticeable issue so far.
I did not enable the ACPI powersaving support option while installing the driver. I wanted to test with all default first.
Would enabling this option make a difference ?

  • Nvidia Xorg seems to "fall asleep" causing all users of it to suffer very low performance until I use x11vnc to send input to the server, then it recovers. Maybe someone knows there is an Xorg config or command option to fix this?
Also not seen yet. How to test that ?

Just barely relevant: Firefox worked flawlessly with VirtualGL until some recent versions, now a webpage creating a WebGL context hangs the browser more often than not. It's distressing to see a major app break compatibility with the only currently working solution on FreeBSD for piping graphics from one GPU to another.
Just tested Firefox 70.0.1 real quick. No issue so far with WebGL.
 
Back
Top