Bug 192617 - [NEW PORT] x11/nvidia-driver-optimus
Summary: [NEW PORT] x11/nvidia-driver-optimus
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexey Dokuchaev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-12 16:55 UTC by David Mackay
Modified: 2019-03-11 18:51 UTC (History)
11 users (show)

See Also:


Attachments
x11/nvidia-driver diff (1.84 KB, patch)
2014-08-12 16:55 UTC, David Mackay
no flags Details | Diff
This is the SHAR archive of the port. (1.92 KB, application/x-shar)
2014-08-12 16:55 UTC, David Mackay
no flags Details
Patch to x11/nvidia-driver adding OPTIMUS option. (4.66 KB, patch)
2014-09-28 14:07 UTC, David Mackay
no flags Details | Diff
Simple slave port to x11/nvidia-driver which sets as a default option the OPTIMUS option. (899 bytes, text/plain)
2014-09-28 14:08 UTC, David Mackay
no flags Details
Patch to x11/nvidia-driver adding OPTIMUS option. (4.97 KB, patch)
2015-03-03 20:43 UTC, David Mackay
no flags Details | Diff
WIP: Not working for Linux option, just an example (3.98 KB, patch)
2018-09-03 22:41 UTC, Thibault Payet
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Mackay 2014-08-12 16:55:07 UTC
Created attachment 145720 [details]
x11/nvidia-driver diff

This is a very simple slave port of nvidia-driver.

Its purpose is simple: for use with Optimus, one needs access to the nVIDIA kmod and the nVIDIA libGL.so.1 and libglx.so. nvidia-driver automatically creates symlinks of the nVIDIA versions of those into the system library directories, which interferes with Optimus by rendering the Intel card unusable.

This port installs them into .nvidia_optimus/ instead of .nvidia/ and will therefore not symlink them.

There are very small changes to x11/nvidia-driver as well, which I've also attached.
Comment 1 David Mackay 2014-08-12 16:55:27 UTC
Created attachment 145721 [details]
This is the SHAR archive of the port.
Comment 2 John Marino freebsd_committer 2014-08-12 17:42:36 UTC
I normally ask for test logs as proof of QA for new ports, but since this is a simple slave port, I'll give you the benefit of the doubt.  Moving to patch-ready
Comment 3 Alexey Dokuchaev freebsd_committer 2014-08-24 14:27:33 UTC
I'd rather not create another slave port, but add an OPTION to the master port instead.  Would it be fine with you?

Slaves (we already have a few of nvidia-driver) add certain non-zero maintenance burden, and in the long run many of them we have right now in the Ports Tree will likely go away once the framework learns sub-packages.

I'll post a patch for reviews shortly.
Comment 4 David Mackay 2014-08-24 15:25:59 UTC
(In reply to Alexey Dokuchaev from comment #3)
> I'd rather not create another slave port, but add an OPTION to the master
> port instead.  Would it be fine with you?
> 
> Slaves (we already have a few of nvidia-driver) add certain non-zero
> maintenance burden, and in the long run many of them we have right now in
> the Ports Tree will likely go away once the framework learns sub-packages.
> 
> I'll post a patch for reviews shortly.

An option would work fine, but it might be pertinent to keep a very simple slave port that simply sets the default options to include an 'Optimus' option as well. This allows its installation via `pkg install'.
Comment 5 David Mackay 2014-09-19 19:00:19 UTC
(In reply to Alexey Dokuchaev from comment #3)
> I'd rather not create another slave port, but add an OPTION to the master
> port instead.  Would it be fine with you?
> 
> Slaves (we already have a few of nvidia-driver) add certain non-zero
> maintenance burden, and in the long run many of them we have right now in
> the Ports Tree will likely go away once the framework learns sub-packages.
> 
> I'll post a patch for reviews shortly.

Hiya,

Have you made any progress with a patch yet? 

Thanks,
David
Comment 6 David Mackay 2014-09-28 14:07:12 UTC
(In reply to Alexey Dokuchaev from comment #3)
> I'd rather not create another slave port, but add an OPTION to the master
> port instead.  Would it be fine with you?
> 
> Slaves (we already have a few of nvidia-driver) add certain non-zero
> maintenance burden, and in the long run many of them we have right now in
> the Ports Tree will likely go away once the framework learns sub-packages.
> 
> I'll post a patch for reviews shortly.

Hiya,

As you have not replied in a month I went ahead and redone this port today in the manner of an OPTION.

Newly attached are the updated patch to x11/nvidia-driver and an (extremely basic) slave port that simply manipulates default options, so that nvidia-driver-optimus will be installable via `pkg`.
Comment 7 David Mackay 2014-09-28 14:07:38 UTC
Created attachment 147752 [details]
Patch to x11/nvidia-driver adding OPTIMUS option.
Comment 8 David Mackay 2014-09-28 14:08:21 UTC
Created attachment 147753 [details]
Simple slave port to x11/nvidia-driver which sets as a default option the OPTIMUS option.
Comment 9 Marcus von Appen freebsd_committer freebsd_triage 2014-09-29 19:10:25 UTC
Assigned to nvidia-driver maintainer.
Comment 10 Alexey Dokuchaev freebsd_committer 2014-11-03 08:12:17 UTC
Thanks for going the OPTIONS knob way!

Before proceeding with the patch, I'd like to update nvidia-driver ports (stable and -304) to their recent versions.  Would you mind testing this patch and report if it works fine for you (both with and without OPTIMUS option)?

http://people.freebsd.org/~danfe/nvidia-update.diff
Comment 11 David Mackay 2014-11-03 10:43:51 UTC
Hi,

I've manually merged your patch into the already-patched x11/nvidia-driver port which I had attached to this PR.

Linked is the diff between the original attached x11/nvidia-driver/Makefile and the new one after applying your patch.

https://dpaste.de/M8Ym

This works fine both Optimus or not.
Comment 12 Alexey Dokuchaev freebsd_committer 2014-11-05 17:46:07 UTC
Thanks for testing.  I've committed the update as ports r372198; Optimus support will follow shortly.  Since new version 340.58 was released today, I will probably commit Optimus support along with an update, so you might want to test 340.58 as well.
Comment 13 David Mackay 2015-03-03 20:43:11 UTC
Created attachment 153729 [details]
Patch to x11/nvidia-driver adding OPTIMUS option.

As part of my final attempt to get this committed I have updated the patch to work against nvidia-driver in ports head.
Comment 14 Koop Mast freebsd_committer 2015-03-03 20:49:34 UTC
Just a observation, is it really needed that the libGL.so and libEGL.so get installed in a different location?

For one this breaks the graphics/libGL and graphics/libEGL scripts that expect the lib/.nvidia/ syntax. Also nvidia only installed either non-optimus or the optimus variant so would it matter?
Comment 15 David Mackay 2015-03-03 21:09:38 UTC
(In reply to Koop Mast from comment #14)
More than needed, this is the primary purpose of this patch: the installation to an alternate path and consequent prevention of the libGL and libEGL scripts from behaving as though the nvidia-driver is installed. 

On nVIDIA Optimus, the main driver used is Intel, and consequently, Intel's libGL.so.1 and libEGL.so.1. The nVIDIA driver is used only in conjunction with VirtualGL and a special slave X server (which has no display of its own), which uses LD_PRELOAD manipulation to use a special wrapper libGL.so that calls into both nVIDIA's libGL and Intel's libGL.
Comment 16 Koop Mast freebsd_committer 2015-03-03 21:46:25 UTC
(In reply to David Mackay from comment #15)

Ok that is clear. I don't know what danfe@ will say but could you add a some comments so this is clear when looking at the Makefile? The nvidia-driver Makefile is complex enough as it is :)
Comment 17 Johannes Jost Meixner freebsd_committer 2015-07-22 16:56:11 UTC
Hi there,

has anyone tested this recently?

If so, what's the result?
Comment 18 peter 2017-03-26 22:43:08 UTC
It seems that the port is still not committed to the main tree.
The support of the Optimus technology is really important for users of all modern laptops. 
Please, commit it, at least for tested versions of Nvidia drivers.
Comment 19 Thibault Payet 2017-10-28 21:10:52 UTC
With actual driver, I manage to use optimus with VirtualGL following https://wiki.freebsd.org/OptimusVideoSupport (for the xorg.conf.nv )

It is working with a little workaround: I have to rename libglx.so from /usr/local/lib/xorg/modules/extensions to something else : for example : notlibglxso , before starting a X session.

In my kld_list I have i915kms, so that when X start it runs with intel driver.
(but in that case it fails to get glx) .
After I start a X session, I start by loading nvidia-modeset, I rename notlibglxso to its original name. And then I start another server using the nvidia card: X -conf xorg.conf.nv -sharevts -noreset :8

I can launch a program with the nvidia card with virtualGL

/usr/local/VirtualGL/bin/vglrun -d ":8" program

With glxinfo I get information about my NVIDIA card so I guess it is working
Comment 20 w.schwarzenfeld freebsd_triage 2018-01-14 04:09:54 UTC
If the other can  confirm, we could close this. Please, on all feedback, thank you!
Comment 21 Daniel Zeisig 2018-08-22 03:26:38 UTC
(In reply to Thibault Payet from comment #19)

I use a similar approach like yours and I can run applications on the nvidia if I start a second X server.

However, with this approach you can't run applications on the first X server anymore which depend on libGL.so.1. This is because the Nvidia driver installation overrides this lib with the Nvidia version of it.

If I understand the idea of the proposed patch correctly, this would solve the problem. I haven't had a chance to test this though due to the patch would need to receive some updates first to work with the current Nvidia driver installation.
Comment 22 Thibault Payet 2018-09-03 22:41:10 UTC
Created attachment 196829 [details]
WIP: Not working for Linux option, just an example

This is my local version of nvidia-driver, it is the combinaison of this bug report patch, the bug #226403, and also some modification that I made to allow running OpenGL applications with the integrated graphics cards while we don't need the nvidia card, to accomplish that I haved to  move etc/libmap.d/nvidia.conf

 to a hidden directory etc/libmap.d/.nvidia/nvidia.conf so that the linker will not try to link with the nvidia library

Since the nvidia glx extension has moved to .nvidia_optimus/libglx.so,
by doing kldload nvidia-modeset, the glx library of nvidia will not be moved to extensions/libglx.so .

I use for that another module directory where I symlink the one on /usr/local/lib/xorg/modules (all except drivers and extensions).

in extensions I have libglx.so a symlink to the nvidia one
and in drivers I have a symlink of modesetting_drv.so nvidia_drv.so vesa_drv.so 

when I want to use the nvidia driver, I have to first cp etc/libmap.d/.nvidia/nvidia.conf to etc/libmap.d/nvidia.conf
kldload the nvidia-modeset

launching Xorg with nvidia config from the wiki https://wiki.freebsd.org/Graphics/OptimusVideoSupport

X -config /etc/X11/xorg.conf.nvidia -configdir /etc/X11/xorg.conf.d -modulepath $NVIDIA_MODULE -sharevts -noreset :8

where NVIDIA_MODULE is the directory previously created that does the symlink with libglx.so from nvidia

then I can launch an application on the nvidia card via VirtualGL

When I have no more need to the card, I just have to kill the server,
unload the nvidia-modeset, and then remove etc/libmap.d/nvidia.conf

and then I can launch OpenGL application using the integrated graphics cards
Comment 23 peter 2018-10-14 16:37:58 UTC
It would be nice to see the port committed even if there are some problems with Linux compatibility level. Actually new users have impression that Optimus in not supported at all, so anyone who wants to install FreeBSD on a laptop would not do it, passing to Linux. It degrades seriously the image of FreeBSD and reduces the users base.
Comment 24 Radnor 2019-01-04 14:49:25 UTC
(In reply to peter from comment #23)

Totally agree
Comment 25 Luís Carneiro 2019-01-08 15:35:39 UTC
Does any of the suggested methods work with a laptop that doesn't have an option to switch GPUs on BIOS?
Comment 26 Daniel Zeisig 2019-02-14 04:55:09 UTC
(In reply to Luís Carneiro from comment #25)

I basically use the approach described in comment #19 on my laptop. I use a Huawei Matebook X Pro which does not allow to turn on/off the graphic cards in the BIOS.

Just to add. I turn off the Nvidia card via acpi_call (from ports) if I don't need it. That helps a lot to save power.
Comment 27 Daniel Zeisig 2019-02-14 04:58:54 UTC
Is there still a plan to commit the changes to the port ? Or wll https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232645 solve all this magically ?