[DO NOT MERGE] Hybrid GPU and Vsync functionality for gamemoderun

[stephanlachnit]

Adds the option to run a game with a secondary gpu and force vsync, if the game is started with gamemoderun.

Closes #20

[stephanlachnit]

I already tested the code by setting the values in the bash script manually (that's why there are force-pushes, I totaly destroyed my commit history twice), and it works as intended, though I didn't test nvidia-xrun or prime.

[mdiluz]

I like the execution so far - what's the plan to hook up the config settings into script?

While this doesn't add much other than avoiding needing to use the full vblank_mode=1 optirun gamemoderun %command% in your steam launch options, maybe it's still such a handy feature that it's worth it just on it's own merit.

[stephanlachnit]

The idea is using D-BUS, since it's running anyway. I've never worked with D-BUS before and still trying to figure out how to use it properly. I also don't quite understand how to use the config struct. If want to use for example config_get_vsync_mode(), I need to give a config, but I don't know where to get it.

[stephanlachnit]

I've added some basic D-BUS functionality, which means that the bash script is able to get a string from the program. If the D-BUS is offline, the script works fine to, it just doesn't set anything.

However now here comes the part, where I've given up. I tried to set the vsync_mode by getting it from context.config.vsync_mode, but no matter what I try, it fails. It's either a "incomplete struct" or "no struct" error and I have no clue why that's the case. Maybe someone can help with this?

[mdiluz]

dbus_messaging.c doesn't know about the actual contents of the context, so you'd need to implement a call in gamemode.c that then calls your config_get_ functions.

[stephanlachnit]

Ok nice thanks. I think I got everything working now, works fine for me so far, I tested it with glxgears, glxinfo and supertuxkart.
The script picks the correct setting and gamemode get's injected in both the app and in my case optirun.

[stephanlachnit]

I checked the clang format, the difference in daemon_config.c can be ignored because all other functions in that file are formatted like that, and for dbus_messaging.c, I don't understand why there should be a newline but if I can change it as suggested if you wish.

[mdiluz]

All PRs will need to pass the clang format check - you can run it locally to set it correctly.

I think the debate in #20 still stands, that this is perhaps a feature that's a little outside of scope, but I do still like it.

I think it'd be preferable if it didn't add the complexity of dbus messages into the mix - not only does that add a failure point, it also means that a change to the settings would currently require a reload of the daemon (ideally at some point gamemode will watch its config files for changes and restart of needed, a separate issue). It also increases the public API surface just for what's really an internal feature.

Perhaps if there was a gamoded - c OPTION kind of interface to fetch these, we'd be reducing the complexity of the implementation, making it a little easier to maintain and less likely to go wrong in weird ways. If it was implemented like that I'd probably change my mind. What do you think @aejsmith?

[mdiluz]

Changes requested to simplify PR.

[mdiluz]

Given exec_cmd usually matches the GPU mode config, why not have these two match as well? It'd remove a big chunk of complexity

[stephanlachnit]

I think thats a good idea. I used the method to avoid Errors if the D-BUS won't work, but if we use a call in main.c, we can simply output the complete exec_cmd and get rid of all the code.

[mdiluz]

exec is used in the script to ensure the whole process is replaced. For consistency it seems like we should still always call exec, but with the additional arguments as wrappers:

exec "$hybrid_gpu_launcher" "$@"

[stephanlachnit]

I think thats a good idea. We can simply use a command in main.c to output all env vars like vblank_mode or DRI_PRIME, and then export all of them line by line and use another one to output additional launch commands. Sadly it dosn't look like it's possible to set env vars in the launch command via the script, at least the ways I tried.

[mdiluz]

Since these aren't related to gpu_device and the nvidia settings, it'd be better to keep them separate and away from the here be dragons warning, as these are pretty safe.

[stephanlachnit]

I think the own section you proposed is the best place.

[mdiluz]

The same ordering issue config example exists here - it'd be best to move them to distinguish them. Perhaps in a whole new config section [gamemoderun]

[stephanlachnit]

Agree with that.

[mdiluz]

This seems like a whoops :)

[stephanlachnit]

I originally started passing the option with an additional command, but at the time I didn't know how to get the config and thought that wouldn't work. I agree that an option is way better than D-BUS.
As I already commented, I think we need two options, one for env vars and one for launch commands.

I would love to start working on this right now, but I have to learn for my exams so I probably won't do anything the next week or so.

[stephanlachnit]

So here is my idea for the bash script:

#!/bin/bash

# Load additional execute commands
exec_cmd="$(gamemoded -g)"
echo "gamemoderun: launch command $exec_cmd"

# Load environment variables
gamemoded -e | \
while read i
do
  export "$i"
  echo "gamemoderun: set env var $i"
done

# Execute
"$exec_cmd" "$@"

I wouldn't use exec "$exec_cmd" because it fails if exec_cmd="exec". We could also use gamemoded -e to get the path for LD_PRELOAD, which makes the script simpler. Overall this change would make it much easier to extend or change the functionality of gamemoderun.

[mdiluz]

I think at this stage it might even be possible to move the whole lot onto main.c so it's just gamemoded -e "$@", that might be worse though, and I already like the simplicity! Nice ideas.

[stephanlachnit]

So I already did a little concept of how this could work, and I found some problems. I created a new branch in my repo for that, if you want to check it out, but I doens't work atm.

To begin with, we need to init the config before we check the args. While this doesn't seem to bad, this will always output where config file was found, which either requires silence this completely, which is no viable solution, or a option to log everything to a buffer, which will only be printed if we don't call gamemoded -e, which I don't think is that nice either.
We could also end up just deleting the first line, but this only works if there are no errors in the config file - so still not a perfect solution.
I think a option would be just to take the last line, which should work fine but I didn't have the time to test that yet. If there are errors, we can simply set exec_cmd="exec"

On the other hand I found some improvements to the bash script. You can set env vars and then execute something with env var=value command.

So we can output the desired command in one single line, tough we should import LD_PRELOAD as the last env var to avoid injecting gamemode to later env commands. This would reduce the bash script to

#!/bin/bash

exec_cmd="$(gamemoded -e)" # at least in a perfect world
echo "gamemoderun: launch with $exec_cmd"
$exec_cmd "$@"

Another way to avoid potential problems with the output would be to call the game just with a system call in main.c, so we wouldn't have anything to avoid potential error message, but I don't know if this would potentially effect performance, especially if we want to print the ouput.

[mdiluz]

To be honest, if the log message from loading the config is an issue, we should probably just move it out to be explicit when the full daemon is running, or simply to stderr. Sounds like that would solve your issue as well as help any other automation jobs users would want to do.

[stephanlachnit]

So I'm now mostly finished (repo). There's just the logging of the config message. I don't know how to output it later or output it to stderr, so help there is appreciated.
Besides this, I've tested the code and it work's just fine.

I think maybe a LOG_TO_BUFFER and a LOG_PRINT_BUFFER function to store logs and print them later sounds like a good solution.

[stephanlachnit]

Moved to #131