Bug 232645 - x11/nvidia-driver: Update to 410.78 (New GPU support), Create x11/nvidia-driver-390
Summary: x11/nvidia-driver: Update to 410.78 (New GPU support), Create x11/nvidia-driv...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Alexey Dokuchaev
URL: http://us.download.nvidia.com/XFree86...
Keywords: needs-patch, needs-qa
: 236768 241307 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-24 17:11 UTC by O. Hartmann
Modified: 2019-11-06 02:13 UTC (History)
21 users (show)

See Also:
bugzilla: maintainer-feedback? (danfe)
iwtcex: maintainer-feedback?


Attachments
410.93 update (8.15 KB, patch)
2019-01-30 14:53 UTC, Alex S
no flags Details | Diff
[new port] graphics/libglvnd-1.1.1 (5.20 KB, patch)
2019-04-18 18:46 UTC, Austin Shafer
no flags Details | Diff
418.56 update (10.67 KB, patch)
2019-04-20 18:55 UTC, Alex S
no flags Details | Diff
430.14 update (10.67 KB, patch)
2019-05-18 06:45 UTC, Alex S
no flags Details | Diff
430.26 update (10.71 KB, patch)
2019-06-14 02:16 UTC, Alex S
no flags Details | Diff
430.26 update (with 390.87 to 390.116) (11.97 KB, patch)
2019-06-16 06:10 UTC, Tomoaki AOKI
no flags Details | Diff
430.40 update (10.71 KB, patch)
2019-08-03 05:07 UTC, Alex S
no flags Details | Diff
430.40 update (with 390.87 to 390.129) (11.97 KB, patch)
2019-08-04 14:11 UTC, Tomoaki AOKI
no flags Details | Diff
430.40 update v2 (11.28 KB, patch)
2019-08-14 09:51 UTC, Alex S
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2018-10-24 17:11:13 UTC
nVidia has provided a new driver for the new RTX 20XX line of GPUs. Are there any chances to get those drivers online soon?

Thanks in advance,
oh
Comment 1 Tomoaki AOKI 2018-11-10 00:47:31 UTC
One important notice.

Starting from version 396 (Short Lived Branch), support for a bunch of old GPUs are dropped and 390.* became legacy GPU version. :-( [1]

So with updating MASTER nvidia-driver, new legacy port nvidia-driver-390 SHALL be created at the same time (or earlier).


See the list between terms

 "The 390.xx driver supports the following set of GPUs:"

and

 "The 367.xx driver supports the following set of GPUs:"

on [2] and [3] for detailed affected GPUs.


[1] https://www.nvidia.com/object/unix.html

[2] http://us.download.nvidia.com/XFree86/FreeBSD-x86_64/410.73/README/supportedchips.html

[3] http://us.download.nvidia.com/XFree86/FreeBSD-x86_64/396.54/README/supportedchips.html


Also, users of GRID K340, GRID K1 and GRID K2 needs nvidia-driver-367,
but there's no legacy branch upstream.
Comment 2 Alex S 2019-01-30 14:53:01 UTC
Created attachment 201533 [details]
410.93 update

Note that this patch includes glvnd libs, although it would be much better to package them separately from nvidia-driver. How should we proceed?
Comment 3 Alexey Dokuchaev freebsd_committer 2019-01-30 14:59:28 UTC
(In reply to Alex S from comment #2)
> How should we proceed?
I'm currently working on the update, given a chance to test it on RXT 2080, weighting different approaches; these new 410 series had indeed brought many disruptions to the driver.  Recent Linux-related updates had further complicated the logic, so I'm also considering offloading Linux-related bits to a separate port before updating the driver itself.  Sorry for the delay. :-(
Comment 4 Alex S 2019-01-30 16:36:25 UTC
I should probably cc dumbbell regarding glvnd (per https://devtalk.nvidia.com/default/topic/1035923/freebsd/do-freebsd-drivers-have-libglvnd-support-/).


(In reply to Alexey Dokuchaev from comment #3)

By the way, I'm also interested in your opinion on my (rather crude) glibc shim: https://forums.freebsd.org/threads/unreal-engine-4-20-4-21.66785/#post-397179. Currently, it is pretty much the only way get Vulkan (and 32-bit OpenGL with 410+ driver) working. I'm not quite sure what should I do with that thing.
Comment 5 Charlie Li 2019-02-23 05:55:48 UTC
libglvnd is indeed supported on FreeBSD:
https://github.com/NVIDIA/libglvnd/releases/tag/v1.1.0

Thinking about creating a port of this as a test.
Comment 6 Austin Shafer 2019-04-18 18:46:56 UTC
Created attachment 203770 [details]
[new port] graphics/libglvnd-1.1.1

Hi all,

The most recent version of the nvidia driver is now 418.56 and I'd love to see the port catch up. I know that the libglvnd changes have complicated supporting the 410* drivers, so I took a crack at creating a new port for it:

QA Performed:
portlint -a  : "looks fine."
poudriere (amd64, i386) : OK
libglvnd tests (make check) : OK 
    (all passing, but needed to modify tests/testglxmcthreads.sh to use libpthread.so instead of libpthread.so.0. Will file an issue with libglvnd to fix this)

QUESTIONS:
libEGL/libGL/libGLES libs were changed to lib*-GLVND.so to prevent conflicts with mesa-libs. I assume this is fine since the nvidia-driver port does a similar thing. Should they be changed to lib*-NVIDIA.so to keep consistent with nvidia-driver?

I also have myself as maintainer in the patch. I'm happy to maintain it if no one else wants to.

I hope this is useful and I'm more than happy to take a shot at fixing up nvidia-driver if you would like me to. Please let me know if there is anything I need to change.
Comment 7 Alex S 2019-04-18 19:24:08 UTC
> libEGL/libGL/libGLES libs were changed to lib*-GLVND.so to prevent conflicts with mesa-libs. I assume this is fine since the nvidia-driver port does a similar thing.

Looks like I didn't explain myself clearly. The whole point of libglvnd is to provide seamless switching between Mesa and Nvidia OpenGL implementations, which is mostly useful for Optimus laptops. That, however, requires compiling Mesa with whatever necessary settings which would presumably make Mesa depend on libglvnd by default (I don't use Mesa drivers, so no idea) and that is the bit that necessitates a separate libglvnd port.
Comment 8 Austin Shafer 2019-04-18 20:18:45 UTC
(In reply to Alex S from comment #7)

Ah that makes more sense. I'm not very knowledgable on mesa either, last I heard libglvnd support wasn't stable. I had misunderstood and thought the intention was to just replace the libs currently installed by nvidia-driver with the libglvnd ones. It would pretty much defeat the purpose of libglvnd but would let us update nvidia-driver without changing mesa to use libglvnd.
Comment 9 Schaich, Alonso 2019-04-20 13:29:56 UTC
Hi

The driver with the initial patch (410.93 update) fails to provide opengl over here.

Xorg.log contains these:

> [  1265.696] (EE) NVIDIA: Failed to load module "glxserver_nvidia" (module does not exist, 0)
> [  1265.696] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
> [  1265.696] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X
> [  1265.696] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If
> [  1265.696] (EE) NVIDIA(0):     you continue to encounter problems, Please try
> [  1265.696] (EE) NVIDIA(0):     reinstalling the NVIDIA driver.
Comment 10 Alex S 2019-04-20 18:55:39 UTC
Created attachment 203837 [details]
418.56 update

(In reply to Schaich, Alonso from comment #9)

> The driver with the initial patch (410.93 update) fails to provide opengl
Fixed.
Comment 11 amvandemore 2019-05-10 01:37:56 UTC
This patch set works for me with a 2070. 

[    25.411] (II) NVIDIA GLX Module  418.56  Fri Mar 15 12:31:45 CDT 2019
[    26.303] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0
[    26.303] (--) NVIDIA(0):     DFP-0
[    26.303] (--) NVIDIA(0):     DFP-1
[    26.303] (--) NVIDIA(0):     DFP-2
[    26.303] (--) NVIDIA(0):     DFP-3 (boot)
[    26.303] (--) NVIDIA(0):     DFP-4
[    26.303] (--) NVIDIA(0):     DFP-5
[    26.304] (II) NVIDIA(0): NVIDIA GPU GeForce RTX 2070 (TU106-B) at PCI:1:0:0 (GPU-0)
[    26.304] (--) NVIDIA(0): Memory: 8388608 kBytes
[    26.304] (--) NVIDIA(0): VideoBIOS: 90.06.2d.00.c9
[    26.304] (II) NVIDIA(0): Detected PCI Express Link width: 16X
Comment 12 Alex S 2019-05-18 06:45:18 UTC
Created attachment 204442 [details]
430.14 update
Comment 13 amvandemore 2019-06-13 21:35:43 UTC
Updated patch doesn't apply for me.  Manually applying also resulted in failure.
Comment 14 Alex S 2019-06-14 01:47:03 UTC
(In reply to amvandemore from comment #13)

That's a really unflattering choice of words. There have been changes to port in the meantime, so yes, the patch doesn't apply after revision 503722.
Comment 15 Alex S 2019-06-14 02:16:38 UTC
Created attachment 205050 [details]
430.26 update
Comment 16 Tomoaki AOKI 2019-06-16 06:10:29 UTC
Created attachment 205098 [details]
430.26 update (with 390.87 to 390.116)

390 branch is now 390.116 until Feb.22.
Updated related parts.
As it runs fine without updating ports (just setting DISTVERSION=390.116 -DNO_CHECKSUM) for me, only updated version and distinfo.
stable/12, amd64.

I cannot test 430.26 as I don't have devices supported.
Legacy 390 branch is the latest for me. :-(
Comment 17 Alex S 2019-06-25 16:24:25 UTC
(In reply to Alexey Dokuchaev from comment #3)

> weighting different approaches

So, have you decided anything?
Comment 18 Alex S 2019-06-25 17:12:45 UTC
(In reply to Alex S from comment #17)

For the record, I don't remember adding maintainer-feedback flag, empty or otherwise.
Comment 19 Alexey Dokuchaev freebsd_committer 2019-06-25 18:15:56 UTC
Sorry, I got distracted by the big OCaml update which took longer than originally anticipated.  I'll switch my attention to nVidia driver ports(s) later this week.
Comment 20 Schaich, Alonso 2019-06-28 19:29:30 UTC
*** Bug 236768 has been marked as a duplicate of this bug. ***
Comment 21 robs0419 2019-06-29 20:26:06 UTC
Hello.


I am getting EQ overflow errors in my Xorg log. These correspond to my system freezing-up (or at least my mouse and keyboard stop working). The mouse and keyboard work for about 10 seconds before this happens.


    I'm Running FreeBSD 12.0 with generic kernel (also tried custom, without option VESA). I have switched off my on-board graphics in my AsRock AB350 bios. My primary display is on an nVidia 1660Ti with HDMI.

    The 430 driver was installed from a patched version of nvidia-driver in the /usr/ports tree. The patch was taken from this bug report page: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232645

    I'm running nvidia_modeset and nvidia kernel modules (specified in /boot/loader.conf) and dbus and hald (specified in rc.conf). Also, I am using the xorg.conf generated automatically by nvidia-xconfig (430). I'm using vga textmode (in loader.conf) but it doesn't make any difference with/without.


Can someone offer advice on how to resolve this, please? I would be grateful.


Thanks,


Rob.


Various configs / logs can be viewed in this reddit post (where a forum member recommended posting my request for help here):

https://www.reddit.com/r/freebsd/comments/c6ay1n/eq_overflow_freebsd_120_nvidia_430_driver_ryzen/
Comment 22 Alex S 2019-06-29 20:42:25 UTC
(In reply to robs0419 from comment #21)

Would you mind posting that on https://forums.freebsd.org/?
Comment 24 robs0419 2019-06-29 20:57:34 UTC
(In reply to robs0419 from comment #23)

Awaiting approval to be shown publicly...
Comment 25 Pouya Eghbali 2019-07-23 07:38:20 UTC
I confirm 430.26 update patches work for me (GTX850M), however 430.34 is already out. I'm working on an optimus port and I need these updates to be merged before I can make any PR.
Comment 26 Alex S 2019-07-25 18:05:12 UTC
(In reply to Alexey Dokuchaev from comment #19)

Alexey, if you keep being distracted, would you at least then consider reviewing and possibly merging attached patch before your planned Linux bits refactor?
Comment 27 Theron Tarigo freebsd_committer 2019-08-01 16:20:24 UTC
What is needed for this to move forward?
Comment 28 Nick Wolff 2019-08-03 01:36:21 UTC
Is the 430.26 update the latest and is that patch ready to go in. If alexy is to busy this is past the two week window for maintainer timeout with no real large objections or issues with what people want to or how they want to do it.

This has been open for 9 months over. So even if more works is needed as long as it doesn't hurt anyone I propose we submit the 432.26/390.116 patch.
Comment 29 Schaich, Alonso 2019-08-03 04:24:22 UTC
Hi niko

The 430.26 is *not* the latest driver any more. nVidia released two further versions for the 430 series and one for the 390 one.

The patch also doesn't apply to the current ports: applying it to an old ports checkout and copy-pasting the resulted x11/nvidia-driver into a new ports checkout results in a usable driver though.

The 430.26 drivers work over here with my quadro k2000 and p620 cards. They massively improve KDE usability over the ports version of the driver even on the 5 year old k2000, as the move to wayland we did last year exposed lots of regressions to nvidia users, most of which are handled by the 400 series updates. We also have FreeBSD-12 now which is not (officially) supported by the ports version of the driver.

... And because noone else mentioned it before: the attached driver ports also address CVE‑2018‑6260, see https://nvidia.custhelp.com/app/answers/detail/a_id/4772 for details.
Comment 30 Alex S 2019-08-03 05:07:15 UTC
Created attachment 206228 [details]
430.40 update
Comment 31 Alex S 2019-08-03 05:13:03 UTC
(In reply to Schaich, Alonso from comment #29)

> The 430.26 is *not* the latest driver any more.
> nVidia released two further versions for the 430 series
> and one for the 390 one.
I don't see the point in updating the patch for every minor driver version, hashes aren't the interesting part there.

> The patch also doesn't apply to the current ports
Oh, but it does. At least with git.
Comment 32 Nick Wolff 2019-08-03 13:10:52 UTC
Thanks Alex for the quick patch to update. I'm trying to ping some other port committers to get this in as a maintainer timeout. If I have time I might also try to add the latest version of 390 to your patch like Tomoaki AOKI did above or if you have time to do this also great.
Comment 33 Alexey Dokuchaev freebsd_committer 2019-08-03 17:48:02 UTC
There are several things needed to be done here before actually bumping the version.  I've accumulated some technical debt here, admittedly, but would appreciate if you guys could give me several more days to finally start moving this forward, thank you.
Comment 34 Tomoaki AOKI 2019-08-04 14:11:49 UTC
Created attachment 206272 [details]
430.40 update (with 390.87 to 390.129)

Updade 390 bits for 430.40 update patch to latest 390.129.
Not tested 430.40 bits as I currently don't have hardwares to try with.
Comment 35 Alex S 2019-08-14 09:51:06 UTC
Created attachment 206516 [details]
430.40 update v2

Forgot about libnvidia-cbl.so.
Comment 36 Alex S 2019-08-30 22:25:00 UTC
Ok, where are we now?
Comment 37 Gleb Smirnoff freebsd_committer 2019-10-17 14:25:01 UTC
See also bug 241307. I should have added patch here, but for some reason this bug didn't pop up with search "nvidia-driver update".
Comment 38 Ben Woods freebsd_committer 2019-10-17 23:18:24 UTC
Hi danfe@,
How are you going with this work?
I have been running something similar to this attached patch for a month or so now, and since it cuts a new nvidia-driver-390 port it really has very little risk in my mind (people can fall back to the 390 pkg if the newest does not work for them).
Would you like me to finalise / polish it this weekend and commit the update?
Regards,
Ben
Comment 39 Matthieu Volat 2019-10-24 07:39:16 UTC
Hi, just 2c to comment I have been running this driver without any direct issue... Except that it has to be noted that since there's not equivalent 32bit driver, we can't get any 32bit opengl compat right now.

Maybe there should be also a warning regarding that? The ideal would be for nvidia to provide 32bit libraries in this driver now, but I'm under the impression they don't really care nowadays (like with vulkan support in freebsd...).

Thanks for continuing to update this driver!
Comment 40 Ben Woods freebsd_committer 2019-10-24 10:51:15 UTC
Hi danfe,

Sorry to hassle you, but could you please give me an indication on whether you have time to progress this nvidia-driver port update?

If you would like, I could test and commit the update? Or do you have something in the works that just needs a bit more time?

Regards,
Ben
Comment 41 Alexey Dokuchaev freebsd_committer 2019-10-24 10:56:53 UTC
I'm working on it right now.  The first part is to move Linux libraries to a separate port (the main reason behind the delay), which is ready and I plan to commit it later tonight once I'm confident things won't break.
Comment 42 Ben Woods freebsd_committer 2019-10-24 11:10:16 UTC
Great news - thanks in advance for your efforts :)
Comment 43 Alex S 2019-10-24 13:56:16 UTC
(In reply to Matthieu Volat from comment #39)

> Maybe there should be also a warning regarding that?
Not really, the current 390.x package doesn't install any 32-bit drivers either.

> The ideal would be for nvidia to provide 32bit libraries in this driver now,
> but I'm under the impression they don't really care nowadays
> (like with vulkan support in freebsd...).
They don't care because you don't care to complain to them. Also, please Ctrl + F for "Vulkan" on this page.
Comment 44 Matthieu Volat 2019-10-24 14:08:33 UTC
(In reply to Alex S from comment #43)

> Not really, the current 390.x package doesn't install any 32-bit drivers either.

Yet they were available and mentionned in packages like i386-wine


> They don't care because you don't care to complain to them. Also, please Ctrl + F for "Vulkan" on this page.

I did care enough to formaly complain to their customer service which directed me to their support forums, and here is the thread that followed: https://devtalk.nvidia.com/default/topic/1042108/vulkan/vulkan-support-missing-from-freebsd-driver/

And regarding your "search" comment suggesting a solution, I would hardly call hijacking gnu-linux libraries with those stubs companions libs a definitive solution worthy of being packaged alongside the official driver...
Comment 45 Alex S 2019-10-24 14:28:43 UTC
(In reply to Matthieu Volat from comment #44)

> Yet they were available and mentioned in packages like i386-wine
Now, please ask yourself why they aren't available in nvidia-driver instead. Or, more specifically, why  one maintainer is working around another maintainer.

> hijacking gnu-linux libraries
That was uncalled for. "Hijacking" isn't any different from whatever Wine is doing, which is incidentally the only serious Vulkan consumer. It's hacks all the way down.

No GNU code is used in the process either.

> with those stubs companions libs a definitive solution
> worthy of being packaged alongside the official driver...
Nobody suggested that.
Comment 46 Theron Tarigo freebsd_committer 2019-10-25 20:12:40 UTC
(In reply to Matthieu Volat from comment #44)
> I would hardly call hijacking gnu-linux libraries with those stubs companions libs a definitive solution worthy of being packaged alongside the official driver...

If using Nvidia's code outside of what they intended (call it hijacking if you will) is enabling people to use FreeBSD where it would otherwise not meet their requirements, then that is good for the Project.  When something goes wrong, the users can complain to Nvidia even though it is an unsupported configuration, which lets Nvidia know that there is the demand.
Comment 47 Alex S 2019-10-28 16:48:21 UTC
Just a heads-up, with GTX 1660 S launch tomorrow, there should be a corresponding driver update either to 430 or 440 branch in a few days. It makes more sense to update to 440 now, even if 440.26 is beta release.
Comment 48 Theron Tarigo freebsd_committer 2019-10-28 16:56:39 UTC
(In reply to Alex S from comment #47)
> It makes more sense to update to 440 now, even if 440.26 is beta release.
If it's beta, shouldn't that be a slave port, nvidia-driver-next?  The master port can change as needed to support the structuring of files in the beta as long as the resulting non-beta nvidia-driver package remains unchanged.
Comment 49 Theron Tarigo freebsd_committer 2019-10-28 16:57:53 UTC
(In reply to Alex S from comment #47)
Why do we need it if 430 is sufficient?
Comment 50 Alex S 2019-10-28 17:00:27 UTC
(In reply to Theron Tarigo from comment #48)

> shouldn't that be a slave port, nvidia-driver-next?

It's a beta of "long-lived branch release". There will be a non-beta release in a month at worst. Might be even tomorrow.

> Why do we need it if 430 is sufficient?

We are supposed to track long-lived branch, so why not?
Comment 51 Alexey Dokuchaev freebsd_committer 2019-10-28 17:26:34 UTC
(In reply to Theron Tarigo from comment #48)

> If it's beta, shouldn't that be a slave port, nvidia-driver-next?
"Beta/Next" slave ports were considered in the past, but given their inherent volatility, this idea was dropped.

Instead, the port is constructed in such a way that users should be able to build any version they like with "make DISTVERSION=... -DNO_CHECKSUM".  That's the reason behind careful maintaining of those NVVERSION checks.
Comment 52 commit-hook freebsd_committer 2019-10-29 13:45:53 UTC
A commit references this bug:

Author: danfe
Date: Tue Oct 29 13:44:58 UTC 2019
New revision: 515978
URL: https://svnweb.freebsd.org/changeset/ports/515978

Log:
  - Update NVidia mainline driver to version 410.104, the latest in
    the 410.xx series and the last without full Wayland support
  - Move 390.xx to corresponding legacy slave port and update to the
    latest version 390.129

  PR:	232645

Changes:
  head/x11/Makefile
  head/x11/nvidia-driver/Makefile
  head/x11/nvidia-driver/Makefile.common
  head/x11/nvidia-driver/distinfo
  head/x11/nvidia-driver/pkg-plist
  head/x11/nvidia-driver-390/
  head/x11/nvidia-driver-390/Makefile
Comment 53 Alexey Dokuchaev freebsd_committer 2019-10-29 17:14:44 UTC
So what's going on so far: in ports r515584, all the Linuxish libraries and programs were moved to their own ports, untangled from the NVidia driver itself.  While the LINUX option was kept (because it affects the build), RUN_DEPENDS on `x11/linux-nvidia-libs' is not being enforced because presumably a bit of slack is fine when versions mismatch slightly.

In ports r515978, the mainline driver was updated to 410.104.  This is an intermediate step and a base for the upcoming commits.  Please check it out and report of any problems or issues.

I still need to review `graphics/libglvnd' port submission to see if it's warranted.
Comment 54 Charlie Li 2019-10-29 18:20:38 UTC
(In reply to Alexey Dokuchaev from comment #53)
> I still need to review `graphics/libglvnd' port submission to see if it's warranted.

This port is needed for Nvidia Optimus to work.
Comment 55 P Singh 2019-10-29 18:42:04 UTC
Not sure if this is a bug or a misconfiguration on my part, but...  

After `startx` /var/log/messages has:  

Oct 29 14:21:53 eddie kernel: ACPI Error: Field [TBF3] at bit offset/length 356352/32768 exceeds size of target Buffer (368640 bits) (20181003/dsopcode-355)
Oct 29 14:21:53 eddie kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEG.VID.GETB, AE_AML_BUFFER_LIMIT (20181003/psparse-677)
Oct 29 14:21:53 eddie kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.PEG.VID._ROM, AE_AML_BUFFER_LIMIT (20181003/psparse-677)

Environment information:

`freebsd-version -kru`:
12.0-RELEASE-p10
12.0-RELEASE-p10
12.0-RELEASE-p11

Installed package: nvidia-driver-410.104
Package options: ACPI_PM LINUX

I tried it both with and without ACPI_PM, but got the same thing.  I use Poudriere to build, so I wondered if the kernel sources within the jail(s) would be an issue.  I updated the jail & checked the kernel source tree, and it appeared ok.

I tried both ways, with nvidia & nvidia-modeset kmods, and still got the same thing.

Let me know if more information is needed.  Thank you!
Comment 56 P Singh 2019-10-29 19:00:10 UTC
(In reply to P Singh from comment #55)

Nevermind, it might be an issue on my end.  I realized that those ACPI error messages are probably more like warnings.  I was starting KDE with "exec ck-launch-session startkde" in my ~/.xinitrc.  I decided to try twm instead, and it started up fine.  
  
If I run into any issues with the driver, I'll be sure to post here :)
Comment 57 Alex S 2019-10-29 19:45:33 UTC
(In reply to Alexey Dokuchaev from comment #53)

> While the LINUX option was kept (because it affects the build),
> RUN_DEPENDS on `x11/linux-nvidia-libs' is not being enforced because
In my opinion, that dependency should be other way around.

> presumably a bit of slack is fine when versions mismatch slightly.
Just how much slack is fine? I've never seen OpenGL to work with mismatched kernel/userspace drivers, there is supposedly a version check somewhere.
Comment 58 Alex S 2019-10-29 20:00:26 UTC
(In reply to Charlie Li from comment #54)

> This port is needed for Nvidia Optimus to work.
Optimus (PRIME Render Offload) won't work anytime soon. Right now, libglvnd port is needed simply so _Mesa_ can depend on it. That should be quite a bit better than the current libmap.d/nvidia.conf solution.
Comment 59 Theron Tarigo freebsd_committer 2019-10-29 20:02:34 UTC
(In reply to Charlie Li from comment #54)
> > I still need to review `graphics/libglvnd' port submission to see if it's warranted.
> This port is needed for Nvidia Optimus to work.
This is incorrect.  VirtualGL as a technology predates GLVND and is already packaged and working for FreeBSD, and solves the problem that GLVND doesn't address: displaying Nvidia-rendered frames on the integrated GPU.  "Primus" would also work; someone says it would need to be ported to FreeBSD, but I think that's just because it requires a GNU toolchain.  As for real PRIME offloading, that requires more than just GLVND libraries, and is not currently known to be usable on FreeBSD until Nvidia chooses to provide this support.

GLVND does solve some interesting "problems" - I'm not trying to spread FUD on it.  I just want to clear the misconception that it is a sticking point for progress with Optimus support.

As someone running FreeBSD on systems with various combinations of Intel, AMD, and Nvidia GPU (sometimes all three) I do _NOT_ want Mesa GL depending on GLVND unless there is a very good reason for that (which I will accept once the Mesa project officially adopts GLVND.  Is there some movement in that direction?)
Comment 60 Charlie Li 2019-10-29 20:12:40 UTC
(In reply to Theron Tarigo from comment #59)
VirtualGL/primus was very buggy on my machines, even back when I still used Linux. Some programs required a delicate LD_PRELOAD in addition to launching with virtualgl/primus in order to have the Nvidia drive things. Thus I am only focusing (my) discussion on PRIME offloading. And even using PRIME offloading requires that program(s) use Nvidia's libGL.so; mesa's will not activate the Nvidia card. Hence why glvnd is brought up now, as it was much uglier pre-glvnd.
Comment 61 Alex S 2019-10-29 20:26:19 UTC
(In reply to Theron Tarigo from comment #59)

> which I will accept once the Mesa project officially adopts GLVND.
> Is there some movement in that direction?
What are you talking about? It's a supported configuration: https://bugs.freedesktop.org/show_bug.cgi?id=92877. If you mean that Mesa (the project) should maintain libglvnd itself, that isn't going to happen.
Comment 62 Theron Tarigo freebsd_committer 2019-10-29 21:06:59 UTC
(In reply to Charlie Li from comment #60)
> VirtualGL/primus was very buggy on my machines, even back when I still used Linux. 
It works in many cases and is better than having nothing at all while we wait indefinitely for Nvidia or some third-party to make progress on PRIME.

> Some programs required a delicate LD_PRELOAD in addition to launching with virtualgl/primus in order to have the Nvidia drive things.
Bug to be filed as of when it becomes a concern.

> Thus I am only focusing (my) discussion on PRIME offloading. And even using PRIME offloading requires that program(s) use Nvidia's libGL.so; mesa's will not activate the Nvidia card. Hence why glvnd is brought up now, as it was much uglier pre-glvnd.
All options currently on the table, even PRIME on Linux, require environment variable fiddling.  Those environment changes can also handle the libGL switchover, which is how VirtualGL normally works when the app is not so bugged that preload hacks are required.

>Thus I am only focusing (my) discussion on PRIME offloading.
Waiting patiently may work for you but some of us ([1],[2]) want to have something in ports that works for most but not all apps, even if it must be based on older technologies.  We've already proven it can work as a FreeBSD port, and in that arrangement, libGLVND is merely an implementation detail of nvidia-driver, not an integral component of VirtualGL-mediated access to the GPU.

I have absolutely no objections to splitting libglvnd off into a separate port from nvidia-driver, I just want to reiterate that this isn't blocking progress on "optimus support" achieved through VirtualGL.

[1] https://forums.freebsd.org/threads/nvidia-optimus-driver-for-freebsd.71504
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192617
Comment 63 commit-hook freebsd_committer 2019-10-31 08:51:37 UTC
A commit references this bug:

Author: danfe
Date: Thu Oct 31 08:51:07 UTC 2019
New revision: 516138
URL: https://svnweb.freebsd.org/changeset/ports/516138

Log:
  Update NVidia driver to the latest long lived branch version 430.50.

  PR:	232645, 241307

Changes:
  head/x11/nvidia-driver/Makefile
  head/x11/nvidia-driver/distinfo
  head/x11/nvidia-driver/pkg-plist
Comment 64 Alexey Dokuchaev freebsd_committer 2019-11-03 13:24:39 UTC
*** Bug 241307 has been marked as a duplicate of this bug. ***
Comment 65 Alex S 2019-11-06 02:13:44 UTC
danfe, can you please include libnvidia-glvkspirv.so (shader compiler), libnvidia-rtcore.so, libnvidia-cbl.so (ray tracing extension for Vulkan) in 
linux-nvidia-libs? Those definitely should work under Linuxulator just fine.


(In reply to Alex S from comment #43)

> They don't care because you don't care to complain to them.
Case in point: https://devtalk.nvidia.com/default/topic/1065886/freebsd-solaris/request-include-32-bit-libraries-with-64-bit-drivers/.