search

batocera-linux / batocera.linux

batocera.linux
https://batocera.org
Other
1.99k stars 513 forks source link

[V40] Steam cannot utilize GPU #12267

Closed taleteller closed 2 months ago

taleteller commented 2 months ago

Batocera build version

40

Your architecture

X86_64

Your Graphic Processor Unit(s) (GPU)

Nvidia GTX-1060

Issue description

This is basically the followup to #10948 - as expected (and feared) the flaky solution of running steam as root user was never revised and implemented in release V40. Actually its worse because the patched V40-dev version I used before had issues with Big Picture but at least ran games utilizing the GPU. Since this is a complex issue, lets sum up what we learned in the previous ticket.

The origin

Some months ago the flatpak Version of steam started to require a sane DBus environment. Before these days steam and its games ran as user "batocera" inside the flatpak sandbox. We noticed because Steam was giving us a famous "Steamwebhelper is not working" window. This happened on all versions of batocera.

The underlying issue

Batocera does not offer a sane DBus environment in its architecture due to non-standard directories. For example the users "root" and "batocera" share the same home folder. The DBus client service resides in /var/run/dbus-1/ instead of something like /var/run/user/1000/dbus-1 making it impossible to have dedicated clients for "root" AND "batocera" user.

The 'solution' and its problems

After a lot of experiments a solution got made to simply run Steam as the user root. This is not supported, and there even is a client warning not to do it, the 'solution' patches out. Some red flags and issues this brings up:

However, even if we ignore all red flags, being unable to utilize the GPU makes Steam basically unusable in the current version.

The correct way

It is required to solve the underlying issue of non-standard architecture. The users root and batocera should not share a home folder. Same goes for the /var/run/user/{PID}/ scheme to allow concurrent DBus sessions. This would not only solve problems with Steam but other flatpaks in requirement of a working DBus.

Detailed reproduction steps

Try to use steam

Details of any attempts to fix this yourself

No response

Details of any modifications you have made to Batocera.

Moonlight from batocera.pro because the shipped version works not well. Steam from batocera.pro most likely soon ...

Logs and data

batocera-support-20240813193810.tar.gz

dmanlfc commented 2 months ago

I look forward to your PR to resolve the problem for the flaky solution.

taleteller commented 2 months ago

@dmanlfc I am no dev of this project, i am just reporting an issue. Not being able to use GPU with Steam is an critical issue and its not my fault that known problems were ignored for months.

dmanlfc commented 2 months ago

You don't have to be a dev on the project to submit a PR. You're obviously very knowledgeable about how things should work. Being open source means that anyone can contribute. Please by all means submit a fix.

Things to note:

  1. Batocera doesn't use Systemd - Flatpak and Systemd are intertwined, which is continues to make things more difficult.
  2. Systemd helps provide the user sessions for Dbus. Again we don't have this.
  3. Batocera uses Buildroot which is focused on embedded systems and by default runs as root without user profiles.
  4. We're following Buildroot's dbus implementation without Systemd which served its purpose just fine until Steam wanted to spawn a bunch of advertising in their app and therefore multiple processes after v39 was baked.

Therefore what you would need to do is probably architect a new way for how Batocera is going to work in future with user profiles, systemd, complimentary dbus changes, a bunch of new dependency packages (yes modern flatpak versions bring in a bunch of new dependencies not relevant to Batocera but are required, well just because. So much for a small containerisation solution).

Regarding your issue, Steam cannot utilize GPU. It obviously does work with the GPU, otherwise you wouldn't have anything rendered in the first place. Your commentary here doesn't make sense - Many games and programs (including Steam) cannot utilize OpenGL or Vulkan for dedicated GPUs. They fall back to Mesa, giving you abysmal low performance if working at all. Mesa is the driver used for GPU's.

So I guess what you're trying to say (including criticising the free project and the current workaround) is, your problem is actually that the current implementation for your system doesn't appear to be taking advantage of your Nvidia GPU (your discrete graphics card) and therefore it's using the integrated intel (assumed) GPU.

taleteller commented 2 months ago

@dmanlfc I have no joy in any finger pointing blame game. I also don't have any insight into the deeper architecture of this project and therefore I do not desire to submit a PR. Got it?

We both know that running desktop code as root is bad practice. We both know that the root fix was implemented in good faith but sadly showed widespread problems in the prematurely closed ticket already. We also both know that a Steam implementation that falls back to software rendering is not useful.

Therefore you can either keep up the finger pointing game or acknowledge the existence of an issue that should be resolved with competence and deep knowledge of the code base.

joinski1 commented 2 months ago

@taleteller The only one pointing the finger at others here is you.

I do not desire to submit a PR

But apparently you're asking someone else to do it?

You do realize that Batocera is basically a hobby project, and that everyone who works on it does so voluntarily in their free time without pay? The way you are behaving/writing here (simply criticizing what you think is bad/wrong/not working properly and demanding that someone fix it) is therefore rather presumptuous and disrespectful.

dmanlfc has explained in detail where the difficulties/hurdles lie in implementing what you want to achieve.

So either you help, or you have to be patient until someone else (who is capable + willing to invest the appropriate amount of time) is motivated enough to make it happen.

taleteller commented 2 months ago

@joinski1 I don't get your point, I am patient. I have not asked anyone to solve anything soon. In fact I have watched the old ticket patiently for months and announced to open a fresh ticket when the v40 does not resolve the problem. This was in response to dev explaining posting in a old ticket wont do anything. V40 did not address the issue, so here we are. Of course I do not submit a PR, because I am not qualified.

I am also not disrespectful or demanding at all. All I did was stating some plain facts and collected what the old ticket dug up. If the dev team decides supporting Steam is too much of a hurdle, that's OK for me. Then state that and remove the platform. If you want to keep it, acknowledge the issue to be present.

dmanlfc commented 2 months ago

@dmanlfc I have no joy in any finger pointing blame game. I also don't have any insight into the deeper architecture of this project and therefore I do not desire to submit a PR. Got it?

We both know that running desktop code as root is bad practice. We both know that the root fix was implemented in good faith but sadly showed widespread problems in the prematurely closed ticket already. We also both know that a Steam implementation that falls back to software rendering is not useful.

Therefore you can either keep up the finger pointing game or acknowledge the existence of an issue that should be resolved with competence and deep knowledge of the code base.

It is clear you don't understand architecture of the project because then you would know that what is required to fix the problem isn't trivial. However, still you clearly suggest you know the fix and how we should go about things.

My suggestion, delete this thread, sleep on it & have a think about how you should be asking for support from a free and open source project. Then provide a nice issue report with clear details of the problem you're facing using the stock v40 x86_64 build with no mods.

And here's a hint. It doesn't involve saying we do bad things, we go about things the wrong way & it doesn't say words in it like flaky and have an underlying attitude to the tone of the request and that is affects everyone as it clearly does not.

Be sure to articulate the problem in detail so I'm not still guessing as to your situation. The latest dialog does give me some hint and further insight about what your problem may be but you failed to confirm my previous speculation as to your situation. Finally provide a support file pertaining to Steam having been run via ES as the current one does not provide these details and is therefore unhelpful.

taleteller commented 2 months ago

@dmanlfc I know that fixing the problem is not trivial, I never said so, I never expected it to be solved anytime soon. In fact I pointed out a underlying architectural issue, and you pretty much confirmed it with pointing to systemd.

I am sorry if you feel attacked by words like "flaky", but sadly that my - and other peoples - experience with the solution that went into v40. As I used it for the past months, it was issues like system freezes when exiting a game about 3 of 4 times, sometimes solvable by killing via gamepad, sometimes only by hard reboot or soft reboot via console. Nothing unbearable, but no offense intend "flaky".

I am also sorry if you feel attacked to do "bad work", this was not my intention as well and i never said so. However you can hardly deny that #10948 brought up plenty of issues after closing, without any acknowledgment that the solution had issues and should be revised. Maybe its just communication, but from outside it looks like the issue got ignored.

The following got captured having "Valve Corporation" aka Steam started via Ports, running "Dark Souls Remastered", stuck at the loading screen. It worked prior the v40 Update. batocera-support-20240815133018.tar.gz

In tests with other games as well CPU is on all cores at 100% showing <0.1fps, therefore running in software rendering mode. Feel free to ask for more, as I am glad to help. /edit: typo

dmanlfc commented 2 months ago

As per the wiki, run Steam games via the Steam System in ES, not Ports. Also, I DO NOT support the OS being modified with overlays, custom scripts & pro add-ons which sometimes break the intent of the OS we provide. Therefore in future and as previously outlined provide a support file from stock Batocera 40.

taleteller commented 2 months ago

It makes no difference if I start steam via ports or a game via ES - in both cases its clearly software rendering.

I might do a fresh install to an usb stick for debug purposes if you are done attacking me. Thus I don't know how that helps since we both agree the issue is lying deeper in the architecture.

dmanlfc commented 2 months ago

Installed a fresh v40 on a system with a Nvidia GTX 1650. Installed Steam - OK Launched Steam - OK System information in steam shows the Nvidia GPU is being used - OK Install the game Star Fighter - OK Starts Start Fighter - OK FPS in Star Fighter - ~550fps in menu & ~160fps in game. CPU utilisation ~35%

taleteller commented 2 months ago

I cannot reproduce it on different hardware as well. On the productive system i get 'Driver: llvmpipe LLVM 17.0.6 4.5 Compatibility Profile Mesa 24.1.1' from Steam info. However I cannot dismantle the productive system to replace the SSD in short term and have to go for a business trip. I will close the ticket and open a new one with more information later.