Nvidia Optimus Driver for FreeBSD

shkhln

Aspiring Daemon

Reaction score: 244
Messages: 767

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.
 

shkhln

Aspiring Daemon

Reaction score: 244
Messages: 767

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:

shak

New Member


Messages: 16

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
 

Theron Tarigo

New Member

Reaction score: 2
Messages: 8

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.
 
Top