Re: [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Le 12/01/2021 à 19:15, Emil Velikov a écrit :
On Tue, 12 Jan 2021 at 17:53, Archange <archange@xxxxxxxxxxxxx> wrote:
Le 12/01/2021 à 18:33, Emil Velikov a écrit :
On Tue, 12 Jan 2021 at 15:07, Archange <archange@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux