Open higuita opened 7 years ago
Where should we put this though? /etc/environment or .profile would be good choices with different considerations. Whether it can be "toggled" without a session restart would be dependent on whether the application pulls in environment vars or just gets them form the running session... it's be a shame if the feature is too application dependent. :/
Being a environment, it is always quirky to manage :)
i would say the .profile is better, one user may want this, but another may not use it.
but even better, IMHO, is to have a $HOME/.bin/radeon_gallium_hub and tell users to start the game/app with $HOME/.bin/radeon-profile-gallium game_or_app
the radeon-profile-gallium woud have something like:
#!/bin/bash
export GALLIUM_HUD=????
export GALLIUM_HUD_DUMP_DIR=/tmp/mesa/
export GALLIUM_HUD_PERIOD=5
exec "$@"
one then could add this to the steam command, edit the .desktop or simply add it manually to the .profile or .xinitrc
Actually, I am not on linux right, but Radeon Profile already supports this. Just go to the Exec (IIRC), set the game path, select GALLIUM_HUB and enter values for it and launch?
@lhorace - that would definitely work, but it'd be nice to toggle this globally, or else you may as well go edit every startup script and add the var there. I don't want to open up this panel jsut to launch every game I have, that's what Steam is for! :)
I think this needs to be global or else it's no improvement over what one can already do, but the trick is how to update any running applications...
I might try testing this later - might be as easy as writing to .profile, then launching an application, since it's very likely that a new instance of an application would parse the .profile file before running...
As for on the first point, radeon profile doesn't do anything different from Radeon Settings or RadeonPro on Windows. Except for the Global feature that Radeon Settings have, mind you, Radeon Settings doesn't support in game OSD like RadeonPro. Which I both use on occasion to launch my games. And I have Steam too :-P. I think toggling those VARS globally AFAIK have to be set before your login session starts for applications to inherit them. Unless you want to execute you game from a terminal, then the .profile idea would definitely work.
the trick is how to update any running applications...
Yeah, hehe, that would definitely be tricky :)
So look like we have 2 different issues here: 1- grab data from GALLIUM_HUB and make graphics from it in radeon-profile instead of the ingame graphs. Basically a alternative way to get the GALLIUM_HUB data and visualize it (what i was referring in my initial request) 2- manage system GALLIUM_HUB options (what you two are talking about) :) For this one, as i said, the best option is to create a external file, managed by radeon-profile and then load it in the .profie, in .xinitrc or any other place. but the problem is always changing that settings without restarting or manually load those options. We can open a feature request to mesa, to allow mesa to read environment from /etc/mesa.rc and $HOME/.config/mesa.rc every time a game/app starts
1- grab data from GALLIUM_HUB and make graphics from it in radeon-profile instead of the ingame graphs. Basically a alternative way to get the GALLIUM_HUB data and visualize it (what i was referring in my initial request)
this would be useful indeed. I would like to display some of the data on the desktop (in form of Conky) and then refer to the full app when needed. I have the daemon running and have tried to collect the data but have difficulty actualising this. any pointers or if the data can be pulled from anywhere else.
assistance is much appreciated
GALLIUM_HUD
allows one to extract much info from the running app, and usingGALLIUM_HUD_DUMP_DIR
andGALLIUM_HUD_PERIOD
, we can get that date in the refresh rate we may need. You have this variables info https://www.mesa3d.org/envvars.html and of course, the list of possible GALLIUM_HUD options viaGALLIUM_HUD=help glxinfo
With this, we could read a tons of useful info and monitor or graph then (like on a dual-head setup, one could see the graphs without messing with the other screen game output)