Couldn't you just prefix your game launch commands with whichever wrapper you need as well as gamemoderun, e.g. optirun gamemoderun %command%? That way you wouldn't even need to blacklist the wrapper since that wouldn't get LD_PRELOAD set for it.

I suppose the benefit of doing it this way though is that you can set the environment variable globally and not have to duplicate it through all of your Steam game launch options or anything like that.

Couldn't you just prefix your game launch commands with whichever wrapper you need as well as gamemoderun, e.g. optirun gamemoderun %command%? That way you wouldn't even need to blacklist the wrapper since that wouldn't get LD_PRELOAD set for it.

I suppose the benefit of doing it this way though is that you can set the environment variable globally and not have to duplicate it through all of your Steam game launch options or anything like that.

The main reason is the global environment variable. I know this is a bit optimistic, but imagine programs like Lutris or Steam would add support for gamemoderun, so that you could simply toggle it in the settings and don't have to edit every start command.

And even if this will never happen, writing a command one time to the blacklist and add one global environment variable is shorter than writing it to every launch command.
After all, gamemoderun is there to make life easier.

One could also use this environment variable for other things than just hyrbid gpu wrappers, for example setting a vsync mode.

Overall I think while any hybrid gpu solution (especially with nvidia) is never perfect, at the moment where we can't choose the GPU for rendering in basically any game, this is a simple solution.

I like the simplicity here - rather than going through the config or anything else, simply setting an env variable. It's not perfect, but I think the fact it's a "dumb" feature, not trying to do anything too clever, protects it from most issues I can come up with.

One note: I wonder if the wrapper backlist could be worked around by using something like this?

_LD_PRELOAD="${CONFIG_LIB_DIR}${LD_PRELOAD:+:$LD_PRELOAD}"

exec $GAMEMODERUNEXEC env LD_PRELOAD=${_LD_PRELOAD} "$@"

One note: I wonder if the wrapper backlist could be worked around by using something like this?

I also thought about that. The problem is that now the wrapper will run env, which is now starting the game instead of the wrapper. (I checked it with the debug option from optirun)
The program will still be run on the secondary gpu, at least from my testing with glxinfo, and my very basic benchmarking with glxgears implies that there isn't a performance impact.

I don't think one way is superior to the other. If you managed to set up your hybrid gpu on Linux in the first place, it shouldn't be an obstacle to set your wrapper to the blacklist if you wish to do so. I personally wouldn't do it with my current configuration of optirun, but I wouldn't mind to change the code if you think that this a cleaner solution.

env is a command line utility that won't use the GPU at all, so I don't think any of primus and friends will have any impact on it at all

env is a command line utility that won't use the GPU at all, so I don't think any of primus and friends will have any impact on it at all

I thought more about the way optirun etc works, but after a bit of research it turns out I was wrong.

I browsed the code of optirun and primusrun and they basically just activate the gpu and set some environment variables, so it really doesn't make any difference even if the PID would be different.
I did a bit testing and it looks like although optirun says that the process is env, the PID optirun reports is actually the one of the program env is starting.

So I'm going to change the code to the following:

LD_PRELOAD="${CONFIG_LIB_DIR}${LD_PRELOAD:+:$LD_PRELOAD}"

exec $GAMEMODERUNEXEC env LD_PRELOAD="${LD_PRELOAD}" "$@"

I also going to change the manpage, which I forgot about.

Thanks, I've merged this and followed it up with 50303dc to expand the documentation a bit.