[arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
Emil Velikov
emil.l.velikov at gmail.com
Tue Jan 12 18:15:29 UTC 2021
On Tue, 12 Jan 2021 at 17:53, Archange <archange at archlinux.org> wrote:
>
> Le 12/01/2021 à 18:33, Emil Velikov a écrit :
> > On Tue, 12 Jan 2021 at 15:07, Archange <archange at 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 at 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.
> > 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?
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.
-Emil
More information about the arch-general
mailing list