Nvidia drivers update #5070
Nvidia drivers update #5070
Conversation
Also add myself as maintainer for it.
|
Is there a particular reason to have both short-lived and long-lived branch? |
| @@ -8264,6 +8264,8 @@ let | |||
|
|
|||
| nvidia_x11 = callPackage ../os-specific/linux/nvidia-x11 { }; | |||
|
|
|||
| nvidia_x11_recent = callPackage ../os-specific/linux/nvidia-x11/shortLivedBranch.nix { }; | |||
There was a problem hiding this comment.
Please don't use camelCase in file names.
There was a problem hiding this comment.
Alright. What do you think a good name would be (not just the way to write it, but the actual name as well)?
|
The "long lived" version is actually more recent than the "short lived" one at the moment. |
|
@vcunat Yes. In particular, my graphics card is only supported by the short lived branch. |
|
343.22 was released 2014.9.18, 340.58 on 2014.11.5. |
|
@edolstra OK, thanks. I wrongly assumed that when they say "lasted" they mean it. Fixed now. |
|
Maybe it makes more sense to use the short lived version by default. Don't know how stable it is... |
eduarrrd
force-pushed
the
nvidia-drivers-update
branch
from
54310cc
to
211c78a
Compare
|
@edolstra Since it works for me on two devices I figured to take your suggestion and make it the default. Hopefully people will complain if it breaks. |
|
On the release branches it might (intuitively) be better to default to long-lived one. On unstable/master I would take the more bleeding-edge of these two, although I'm unsure if it's always the short-lived or the newest. I fail to find any kind of policy about what is the difference between the two branches, but I expect both to be production-quality; note that they also ship beta (currently 346.16). I still don't see users really need the choice. I don't remember anyone complaining the need to switch to another branch, and I don't much like maintaining two almost-identical files (unless it's useful for something). |
|
It all comes down to this: If possible, the users hardware should be supported. Example: GTX980(M). Compare 340.xx, LTS, https://devtalk.nvidia.com/default/topic/786980 So, which of those should we support? Should the user be forced to use the vesa driver (nouveau isn't up to speed yet) because their device is too new? On the other hand, should someone whose requirements are perfectly met and whose experience can only become worse be forced to upgrade to potentially less stable driver? |
|
Hmm, from the release announcements it seems that support for new HW is the only really significant difference (at least in current releases); and ATM the long-lived branch has more of the newer GPUs in the list, presumably just because the release is newer. For a policy on master/unstable I therefore suggest to always use the newest stable release (regardless of long/short). For release branches the long-lived branch seems a better option, as it should be less buggy. Personally, I wouldn't give choice until we have some person that wants to use the choice (i.e. I would keep just one attribute and *.nix file). Reasons: release branches are likely to be unsuitable for very new HW due to other older packages, too. On the other hand, on master/unstable the packages are expected to be newest "stable" from upstream. |
|
I'm not sure where you're getting this from. Look at the announcements one more time: Format: Driver branch, branch name, month of release of "newly added drivers" (example chip I looked up release date of) I see the argument for going with what I called "stable" and dropping what Nvidia calls "long-lived branch release". However, as I said, that leaves people with newer hardware out. Concrete example: if we go with "stable" now and don't offer beta as an option, someone who has a laptop with a 980M chip will be forced to use the VESA driver. "Newest stable release (regardless of long/short)" is a terrible policy. That's the equivalent of saying saying "You're still running kernel 3.17.3? Well, 3.10.61 came out TODAY, and since both are stable, looks like we're gonna 'upgrade' you to the newest release!" This all is assuming you meant newest == "most recent" != "highest version number". Else, please disregard this paragraph. What is the actual method of distinguishing between release and unstable? I.e. how do adjust the nix expressions to apply only in a certain branch? |
|
Ah, I slightly misread the diff of support between current short and long. Next to the download there's a tab with a list of supported HW (the release announcement only contains incremental changes). The diff I got is https://gist.github.com/vcunat/a2d5a510308403571fc1 (unfortunately gists don't have a good highlight of similar lines). The long-lived branch does claim a few additional models, such as 810M, GT 710 and GT 705, presumably because it's a more recent release, but the short-lived one claims models from the 900 Series, including that 980M (I overlooked that before, I'm sorry). In light of this, it makes sense that higher version numbers should add support for newer HW (and maybe drop support for older HW), so I would probably choose highest stable version for master. As for beta, we tend to avoid pre-release stuff in master/unstable. ATM the HW support is probably very similar to short-lived, only some features are missing (and probably some bugs, too).
We just commit different things into different branches. I would also make a comment next to the version number to explain what versions are chosen and why. |
|
You need both the short and long lived branches, 340.xx is technically a legacy driver for devices that have not yet been deemed legacy. 343.xx and above have dropped support for a number of cards so not having both branches will cause more issues. I have been working on repackageing the nvidia drivers to handle all supportable branches (173.xx, 304.xx, 340.xx, 343.xx+). Currently some binaries are not even installed that are packaged with certain versions of the nvidia driver that I am working on adding and getting working correctly, however it will take a while for me to finish this. Short lived should become the default because it is the branch to support all current and future devices, long lived a legacy branch that only receives bug fixes, nvidia just doesn't call it legacy. Unless you refactor the builder script to be generic and handle multiple versions, you need separate builders for both branches because future changes will at some point cause breakage. I would for simplicity name the 340.xx branch 'legacy340' instead of 'long-lived-branch', it will only cause more confusion having different naming schemes. |
Yes, legacy branches are a slightly different matter. The current long-lived branch is also becoming another new legacy branch (as announced in https://devtalk.nvidia.com/default/topic/766018/unix-graphics-announcements-and-news/). AFAIK that's just a temporary situation, and nvidia always provided "short" and "long" branches in addition to the "legacy" ones. I don't expect us wanting to change the builders for legacy branches, so the policy of just copying the directory is probably better than trying to keep one builder that can handle all versions. |
|
Pushed long-lived update and new legacy alias. Adding the STS branch remains, but I would leave that after branching off release-14.11, which is certainly supposed to happen this week. |
|
Any chance of getting the new drivers in master soon (at or above |
|
Yes, I forgot. Thanks for pinging the issue. I might look at it tomorrow. Will you provide a link to your updates? |
|
@vcunat: I'd love to, but I've been using NixOS for <1 week so my update is mostly a hack. I just wanted to alert you guys of the issue -- thanks for taking a look! |
|
I believe all issues discussed here have been resolved; reopen/ping otherwise. Now we have 343.* (latest stable) as the default on master, and 14.12 stays on 340.* (latest long-lived). @eduarrrd: I can add you as a maintainer to versions that you want, although it doesn't change anything in practice (the package is unfree, so Hydra does not build it and thus sends no e-mails about it). Happy Christmas! |
Update current long lived branch + create packages for short lived branch.