Bumblebee vs Optimus-switch vs Optimus-manager - A Discussion

Is the general consensus that optimus-switch is preferable? also do I need to add that launch parameter to all games i wish to use the gfx card?

Well it depends. optimus-switch and optimus-manager have become very popular but they haven't make it to the default mhwd setup scripts yet, I guess because of extra hassle it could make to Manjaro devs, and, there's already another default solution (Bumblebee) which kinda works. If @dglt is feeling pro enough he can try integrating his method to mhwd (clone, patch, pull request and so on) :grin:
But I bet he's like "it's fine as it is now" (?), and that's absolutely normal. More integration = more headache I suppose.

As for the parameter, yeah, you have to either add it to each game you want to be run on Nvidia card or edit Steam's launcher to make it launched with primusrun steam %U, which is kinda overkill. Bumblebee is trying to balance between power saving and power gaming (lmao), so running entire Steam on it makes sense only when Steam is set not to autorun but is launched manually each time you want to play a game.

Thanks again! I look forward to spending some more time learning about the OS, maybe eventually I can contribute something useful! haha

depends on your usage. if gaming or other gpu intensive tasks are not a priority then bumblebee is a perfect fit (if it actually works, it fails more often than it doesnt).

with bumblebee yes. with prime, optimus-switch, optimus-manager you dont need it.

you know my opinion on fumblebee already, a "user friendly" distro should not use by default something that most of the time leaves the user with a black screen and then have to go dig through hundreds of "black screen" threads to find the right parameters (no one size fits all either) and then how to properly edit the right line to add the parameters. and now a recent issue has been happening more often where the new user cant get nonfree drivers to boot so they then choose the free nouveau drivers and the system ends up powering down before ever reaching a desktop.

even that new render offload feature is a better default than fumblebee even if im not a fan of it. no external monitor support, gpu cant be powered down. but the system at least boots.

mhwd integration is above my skill level but i would gladly work with anyone able and willing to do it.

3 Likes

oh, and it's also a long dead project
https://www.bumblebee-project.org/

The Bumblebee Project proudly presents version 3.2.1 of Bumblebee, a project aiming to support NVIDIA Optimus technology under Linux.

News

Bumblebee 3.2.1 has been released on 26 April 2013. (release notes)
This version fixes the main issue of Bumblebee 3.2.
Previous release notes available here.

Project

If you thought that Bumblebee was dead, it's still alive and kicking! See http://wiki.bumblebee-project.org/FAQ

2013 called and they want their nightmare back. :face_with_hand_over_mouth:

1 Like

It's hard to tell if black screen is caused by Bumblebee itself. All cases I know are: a. Nvidia driver installed, wrong xorg.conf => black screen; b. Intel+nouveau combo on recent GPUs => random issues when nouveau.noaccel=1 isn't set; c. Nvidia wired to HDMI => black external display. Neither of these is caused by Bumblebee, frankly. It is a matter of detailed settings based on hardware detection. However, I am not that into support threads to be sure and maybe I am cherrypicking these cases.

i think it's more due to bbswitch than bumblebee itself. with bbswitch comes the need for kernel parameters to be able to boot and why i decided against using bbswitch with optimus-switch. now im curious :thinking:. i wonder if blacklisting bbswitch by default would avoid the initial black screen issue.

I wonder why using Bumblewee on live boot at all? Intel / and driver was always enough to check a new distro and install it, why Manjaro devs did it the hard way I wonder. Btw can you try nouveau.noaccel=1 on Intel-only mode, what effect may it have? On my MX150 it prevents freezing/lockups during reboot/halt.

Yeah you are right about bbswich, sometimes it really causes issues.

i'll have to test this next time someone has the nouveau issue where commands like mhwd, inxi, lspci all cause the command to hang and/or cause a lockup.

i just tested this with a fresh manjaro usb i made a few days ago, booting the nonfree option with no added parameters results in black screen but if i add bbswitch.blacklist=1 it boots right up. could it really be that simple to just include bbswitch blacklisted by default on the iso. most of those acpi_osi parameters that are needed most of the time are due to bbswitch causing problems.

at least then the new user is able to get to a desktop and get it installed. i see no reason why bbswitch should be needed on a live desktop. i'll have to test this on some other optimus laptops and see if the behavior is the same.

If that works, I would love to see that implemented, at least until there is a better option. Booting up to a blank screen is very intimidating for people. Installing optimus-switch was a great learning lesson, but would have been easier had I at least been able to login each time.

1 Like

if others on optimus laptops could test that theory it would be great. installing with a working desktop OOTB for everyone is a much better option then :point_down:

"hey new user, test your luck and see if our long outdated bumblebee setup from 2013 deems your hardware acceptable" :face_with_hand_over_mouth:

What does the Live USB use as settings? I was always able to boot on live USB, but got the blank screen after install.

I won't have my optimus computer for several weeks, but can test when I get it back.

1 Like

i could boot the free drivers without added parameters. but trying to boot the nonfree drivers without acpi_osi parameters always meant black screen and still does. if bbswitch.blacklist=1 allows for easier initial boot it's hardly a solution but it at least gets the new user to a desktop environment.

making something other than fumblebee the default would be a much better way IMO, even if it's the render offload setup which is pretty much on par with the uselessness of fumblebee. if i was skilled enough i would attempt adding prime or optimus-switch to mhwd and submit a pull request but thats above my level of knowledge atm. :disappointed:

1 Like

I wasn't able to boot with either. Both got me a black screen. If I added acpi_osi="Windows 2008" or whatever it was, I would be able to boot sometimes. But it wasn't consistent.

Bumblebee never worked with the two optimus laptops I had so far. :joy:

So, I am not a fan. Not even bbswitch works in my optimus laptops.

Well .. at least that faq page was updated in 2016
(but you are right .. no code changes to git project since 2013)

But honestly you shouldnt be too hard on them. "Nightmare" is just optimus in general. At the time there was virtually no solution until bumblebee showed up. There might arguably be better solutions today. But dont forget the context :wink:

your right, and though i may lay on the dislike for it pretty thick sometimes i actually do admire the work that had to of gone into it. if you take away the performance issues, the black screen, lockups, and no vulkan support (vkrun i guess can now do this?) then it would undoubtedly be the best solution to have performance on-demand only when needed.

OK here we go.
Manjaro install drive MJRO1810 has this in /boot/grub/mhwd.cfg:

 for d in free nonfree; do
    menuentry "${d}" "${d}" {
        if [ "${2}" = "free" ]; then
            def_drv="${2}"
            drv="driver=${def_drv} nouveau.modeset=1 i915.modeset=1 radeon.modeset=1"
        else
            def_drv="${2}"
            drv="driver=${def_drv} nouveau.modeset=0 i915.modeset=1 radeon.modeset=0"
        fi
        menu_reload
    }
done

And similar options everywhere in different configs.
According to freedesktop, noaccel option disables kernel/abi16 acceleration, I don't know what it means but I know that setting it to 1 prevents hard lockups and a bunch of errors on Nvidia GPUs at least from 1xxx series (like MX 150 or GT 1060). This has been true for already 3 years. My suggestion is, if this option is harmless for all other GPUs (older and newer, like GT 750 or RTX 2070), it should be included to the default array of options when nouveau modeset is set to 1, e.g.:

 for d in free nonfree; do
    menuentry "${d}" "${d}" {
        if [ "${2}" = "free" ]; then
            def_drv="${2}"
            drv="driver=${def_drv} nouveau.modeset=1 nouveau.noaccel=1 i915.modeset=1 radeon.modeset=1"
        else
            def_drv="${2}"
            drv="driver=${def_drv} nouveau.modeset=0 i915.modeset=1 radeon.modeset=0"
        fi
        menu_reload
    }
done

Due to no access to any GPU other than my own MX150, I cannot test laptops' and desktops' behavior, but if someone can check it, boot process and overall Manjaro experience can be improved at least on Optimus laptops.

UPD:
I have checked on old laptop Asus N53jf, which has integrated Intel graphics and Nvidia GT 425M. No issues with noaccel set to 1 when using free drivers. So it must be safe to apply this setting to free driver option in live boot menu.
BTW, no black screen when booting with non-free driver on this machine. What I noticed is that 1810 starts with no bumblebeed service active, live user is not in bumblebee group, so one have to use sudo optirun-like commands.
But that's all PCs I have access to.

2 Likes

Well, I used optimus-manager with bbswitch to power off the nvidia gpu. I had no problems that I noticed (suspend/hibernation worked), but AFAIR I never tried to poll the nvidia gpu from an intel session (using VLC or lspci). Now, out of curiosity, I set optimus-switch up. No problem, it works.

As an aside, the git pages for bbswitch are really old and I wonder whether newer hardware would work on it. Also, I do note that my computer temp seems a lot lower on intel with optimus-switch compared to the same with optimus-manager(with the nvidia gpu set to power off through bbswitch). Although I need to investigate that more closely.

On my hardware I see no difference between bbswitch, acpi_call or native power management in terms of temperature and battery life. But only bbswitch can prevent loading nvidia module on resume from suspend/hibernation in Intel-only mode.

Forum kindly sponsored by