Bumblebeed daemon status

[han-so1omon]

System info

Microsoft Surface Book 2
Operating System: Manjaro Linux
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.8.8-arch1-1-surface
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz
Memory: 15.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

Context

I've followed your setup instructions. After the reboot step, I run sudo systemctl status bumblebeed. I get a message that I'm unsure of what it entails with respect to the system status and the usefulness of bumblebee.

...
Module 'bbswitch not found'
No switching method available. The dedicated card will always be on.
...

I saw in #28 that bbswitch is not working, but I'm also familiar with the surface control package, which allows me to turn on and off the dgpu manually.

Question

Could you please clarify the basic working process of surface dgpu + bumblebee + surface control + bbswitch with respect to the current recommended linux-surface system setup and state? Thanks!

[qzed]

At the moment, you'll have to manually turn on/off the card via the surface-control utility, and you can configure bumblebee to not try anything when running via optirun/primusrun (PMMethod=none in the bumblebee config, IIRC). With that set, it should boil down to this: Turn on the dGPU via surface-control, load the nvidia driver and then use optirun. You might need to restart the bumblebeed service after loading the nvidia driver if it complains that it can't find a GPU, IIRC it takes some time to auto-detect that if it's been started/enabled before that.

Some more details, future lookout, and "behind the scenes": The dGPU switching at this point is pretty much a hack, and might require us to patch things on multiple levels before we can have "proper" support. bbswitch does not support the setup as found on the Surface books, and probably never will (unless someone would submit a patch for it, and I'm not sure that's really worth the time as using bbswitch in 2020 itself feels more or less like a hack to me). I've experimented with a vgaswitcheroo implementation (feature/dgpu-vgasw branch), but that was a bit unstable, mainly due to the proprietary nvidia driver not supporting that interface, which requires you to add a stub pretending that it does (and nouveau doesn't seem to like that whole power stuff at all, but I haven't really tried to track any issues down there... unfortunately getting the driver into the kernel would probably require that it works with nouveau, let alone the nvidia stub which definitely won't be accepted). The idea is that with that implemented, you can configure bumblebee to use PMMethod=vga_switcheroo and all would be automatic. At this point that branch is horribly outdated though and I haven't found the time yet to bring it up to date with master and cleanup.

There is some hope on another front as it seems that nvidia is (finally?) trying to fix their prime support on Linux. I've gotten prime offloading via that to work a while back (https://wiki.archlinux.org/index.php/PRIME, requires an X11 config on xorg, requires you to start the compositor with the dGPU on, doesn't seem to work on wayland) and even managed to get acceptable temperatures when the dGPU was turned on but not in use by setting its power/control to auto. Haven't tested detaching with that yet though, and I think that's where it'll break down (i.e. crash when detaching) due to Gnome (for whatever reason) hogging the device since it's been started with the dGPU on. Fixing that would likely require us to get involved with Gnome and getting Gnome to release the device before the tablet can be detached (also I'm only speaking for Gnome here as that's what I use, stuff might be different on KDE or other DEs). Also haven't compared the power-draw with the dGPU on, at least it's not getting hot as before, so that might be an indication.

Haven't found the time yet to look into any of this much further (and also update the vgaswitcheroo branch). This is basically a low-priority issue for me at the moment as we got "something that works for the most part" (still want to improve this of course if I ever find the time for it). Also I'm not really an expert on this and I don't have a comparison on how it's supposed to work with any standard prime laptop. If someone want's to try and improve this whole mess, please be my guest.

[han-so1omon]

Thanks @qzed . So is it necessary to have bumblebee running in order to correctly hand off work requests to the dgpu? Especially since it seems that all gpu work must be run through the optirun program.

[qzed]

If you use optirun or any related way (primusrun, ...) of offloading the work, then yes. As I said in the middle part of that wall of text above, you can also try to get prime working (works without bumblebee), but I haven't really tested that.

[KUKARAF]

@qzed should you need any testing on a SB2 let me know. I started using linux on it as my DD.

[qzed]

@KUKARAF I have an SB2 myself, but thanks for the offer! I'm not using the dGPU much at the moment, so please do feel free to experiment and write up your findings. I believe some things might have changed with regards to the nvidia driver and primus since I last tested this in detail, which was over a year ago I believe.

[r-kukawski]

@qzed I am in the process of setting up the pc to use for machine learning so I will let you know how that went.

Thank you for all your hard work by the way. The surface-linux kernel is amazing. You inspired me to start learning C so i can perhaps, one day, contribute too.