Le 12/01/2021 à 19:15, Emil Velikov a écrit :
On Tue, 12 Jan 2021 at 17:53, Archange <archange@archlinux.org> wrote:
Le 12/01/2021 à 18:33, Emil Velikov a écrit :
On Tue, 12 Jan 2021 at 15:07, Archange <archange@archlinux.org> wrote:
Le 04/12/2020 à 14:06, Emil Velikov via arch-general a écrit :
On Fri, 4 Dec 2020 at 12:55, Lone_Wolf <lone_wolf@klaas-de-kat.nl> wrote:
On 04-12-2020 13:50, Giancarlo Razzolini via arch-general wrote: > Em dezembro 4, 2020 9:27 Emil Velikov via arch-general escreveu: >> I would love to hear the input from the respective maintainers and the >> overall Arch developer base as a whole. >> > As the maintainer for both bumblebee and prime-run, I don't see the > need for deprecation, yet. > Bumblebee still has some uses and also, the it has the appeal of > keeping the card completely powered > off, something that doesn't happen with prime render offload. > > Having said that, I do think bumblebee/primus/primus_vk days are > numbered. > > Regards, > Giancarlo Razzolini For clarity :
Does this affect people without an nvidia card ?
Are users with an nvidia card that only use nouveau kernel module affected ?
There should be no user visible changes with my proposal - both GL and VK should work as normal. The power management side of things is completely unchanged. Regarding that last statement I’m not sure. Can you confirm that you can unload the nvidia modules in this configuration (using PRIME offloading with the proprietary driver through nvidia-prime)?
Should work fine, although cannot try it at the moment on my Intel/Nvidia box. DId you try it and you're seeing issues or there's something in particular which causes doubt? I have no laptop at hand to try, but I can ask a friend to check, maybe tomorrow. I seem to remember that for the proprietary driver to work with PRIME, it had to be loaded before Xorg and could not be unloaded afterwards, which would prevent Bumblebee/bbswitch PM to work.
If so we are definitively willing to integrate this in Bumblebee upstream, so that people with <Turing or <CoffeLake platform can still enjoy power management while finally getting the full power from their card.
With all respect to the Bumblebee project and it's developers, I think the project is dead. Kind of yes, mostly because we all lost interest in this (no affected laptops anymore) and time to work on it (as it moved to low priority).
Last time I looked X supported "hotplugged" GPUs, so unloading the driver (userspace and kernel) should be doable.
OK, will try to check tomorrow with a friend that has an Optimus laptop.
I love the upstream-first mentality, but with 7 local patches in Arch and the last (merged) MR upstream from 2018 I'm not too hopeful. Well, look again, we just merged all patch Debian was caring on top of the develop branch, while most Arch patches have been part of the develop branch for years. I was suppose to handle the release of 4.0 for years, but that never happened. However with the recent pushes around Optimus, it might be worth to have a look at it and finally release that, maybe with a new transport way better than primus or virtualgl (that should have been gone for years…).
Indeed the develop branch has 2 build warning fixes and the manpages are moved. Cannot see many of the local Arch patches merged though?
They are not local Arch patches, they are old commit already in the develop branch (from ~2014 or 2015 IIRC). The exception is the GLVND one that is an upstream PR but not merged (Luca is not sure whether that’s still required). In fact they are ~60 unreleased commits upstream that were supposed to be part of a 4.0 release long ago, most of which have been used downstream (Debian, Arch…) for a long time now.
AFAICT regardless of the transport, I presume that GLVND performance will be superior. So I would urge you to report (or even fix) any of the GLVND/PRIME issues that you see.
By transport, I mean use of PRIME offloading vs primus calls interception or VirtualGL transport. Bruno/Archange