[arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk

[Archange]

Le 12/01/2021 à 19:15, Emil Velikov a écrit :
> 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.

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