search

Bumblebee-Project / Bumblebee

Bumblebee daemon and client rewritten in C
http://www.bumblebee-project.org/
GNU General Public License v3.0
1.29k stars 144 forks source link

Fix build with GCC 10, change manpage section of bumblebeed, set ENABLE_PRIMUS_LAYER for primus-vk support #1071

Closed bluca closed 3 years ago

bluca commented 3 years ago

Patches forwarded from Debian

amonakov commented 3 years ago

I am happy with these, except for the third commit which adds implicit primus-vk enabling: can we ask the opinion of the author of primus-vk on this?

bluca commented 3 years ago

I am happy with these, except for the third commit which adds implicit primus-vk enabling: can we ask the opinion of the author of primus-vk on this?

This change is a result of collaboration with the author, so I think we are ok (eg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892646 )

@felixdoerre any objections? We are shipping bumblebee in Debian/Ubuntu with this

ArchangeGabriel commented 3 years ago

@felixdoerre ^

Those changes are fine, I think they are some other that could be integrated (https://github.com/archlinux/svntogit-community/blob/packages/bumblebee/trunk/0007-bb_mutebblogger.patch, https://github.com/archlinux/svntogit-community/blob/packages/bumblebee/trunk/0008-libglvnd.patch).

More generally I’m wondering whether we should add a new “transport” like this. On Arch they are open requests to change Bumblebee that way and completely ditch primus/primus_vk, only keeping Bumblebee for the power management part (since it requires a Turing+ and CoffeeLake+ system to work with proprietary drivers).

bluca commented 3 years ago

@felixdoerre ^

Those changes are fine, I think they are some other that could be integrated (https://github.com/archlinux/svntogit-community/blob/packages/bumblebee/trunk/0007-bb_mutebblogger.patch, https://github.com/archlinux/svntogit-community/blob/packages/bumblebee/trunk/0008-libglvnd.patch).

Will double-check thanks, I think we have something akin to the former already, and I thought the latter wasn't needed anymore, but not 100% sure.

More generally I’m wondering whether we should add a new “transport” like this. On Arch they are open requests to change Bumblebee that way and completely ditch primus/primus_vk, only keeping Bumblebee for the power management part (since it requires a Turing+ and CoffeeLake+ system to work with proprietary drivers).

It would be really great and I gave that some thought in the past, but I think glx/xorg side is not ready for it? As far as I can understand, the way offloading is implemented means the driver needs to be permanently loaded, and the xserver cannot drop the "reference". Not even wayland+xwayland-on-demand worked last time I tried. I think I had spotted some work-in-progress to allow that to happen, but I don't have a source right now. I might be completely wrong though, as I haven't really spent much time on it, just some quick experiments.

ArchangeGabriel commented 3 years ago

@bluca Hum, now that you say that I’m having doubts too. I’ll check with the person that started this discussion on Arch and report. Anyway this is not completely related to this PR, so we can still handle this later.

ArchangeGabriel commented 3 years ago

So I can confirm that for PRIME offloading the driver has to be loaded before X, and that subsequent attempts to unbind it do not work. At this point this means they are still no good solution for PM + performances for pre-Turing or pre-Coffee Lake systems.