Full screen at full resolution slow for some games
- Inicie sesión ou rexístrese para enviar comentarios
I've seen this with 2 open source games (with non-free or freeware assets):
every time I set the display according to my screen resolution, it works, but it's pretty slow.
It's not even 2D stuff, and I'm running these (openxcom and openRA) on an X200.
Is it just the CPU being too weak, or is there something left to try?
I know both run well at small resolution.
openRA's FAQ suggest to spawn another x server and launch the game in it (https://github.com/OpenRA/OpenRA/wiki/FAQ).
What does that mean? I didn't know I could have 2 xservers (is this that xorg thing?).
When displaying data, no surprises here: the rendering and rendering widget curves both go through the roof. the rest is acceptable (mostly).
Yes you can have X.org server spawn twice. It's almost one year since I
tried to do so, so I don't remember how to do so. I didn't like the
outcome, so I reverted my "experiment".
My "experiment" worked well, the game indeed went to a different X.org
server instance, and I could use, say, Ctrl + Alt + F8 to go there, and
still have my desktop on Ctrl + Alt+ F7. However, spawning another X.org
server also takes away some functionalities that one would expect to
have, mainly if you're using a keyboard shortcut for some program that
is in the background of the first X.org server instance (e.g.: Mumble
with push-to-talk) and so you try using that shortcut while in the
second instance, which won't do what you would expect.
I also face similar issues, but only when recording videos of a game in
fullscreen (the game itself plays fine, but the resulting video has
dropped FPS). I worked around the problem by running all my games in
windowed mode instead, and it even feels better to do so since I can
also switch windows with combinations like Alt + Tab (while in
fullscreen, some games don't accept Alt + Tab, to the point of not even
letting the combination pass to the window manager being used).
Thanks, I'll try this. I tried, but without much success yet.
It seems I need to go to ctrl+alt+F1,
and then type some command.
Something along "x :1", or maybe with startx, I have to find the different sources again.
Isn't it possible to start a Mumble session there as well?
Windowed mode isn't satisfying because it leads to buttons to be misplaced, as if their position ws fixed in relation to the whole screen in openRA.
It's a long time since I experimented with this, and since then, I have
reverted my experiments. As such, I don't know if Mumble can be started
there along with the game in the second X.org server spawn.
I don't understand how this works yet.
Supposedly, if I can launch a game on another X server, I should be launch any other program along with it.
Anyway, I'm not there yet.
I can navigate through tty1 to 6 (7 being my normal X server).
The problem is, on tty1 (ctrl+alt+F1), I have some warning text about XKEYBOARD error report (non-fatal, I know I see some similar log every time I turn the PC off), while other tty have the login prompt that I have on start up (I have no gdm or such).
If I do ctrl+c on tty1, I get the login prompt. But then I lose my original session on tty7.
I need to confirm, but trying to login on other tty does the same, or at least messes everything up.
Are you using compiz by any chance? going back to metacity worked for me one time.
No, but turning Compton off made the "rendering widget" go down. the rendering one is still too high though.
How about Compton?
Yes, turning it off imporeved the situation a bit, but it's still too slow.
You could try to the latest kernel (hence the latest Intel drivers): https://jxself.org/linux-libre/
My current version is 3.13.0-92-generic, so I'll tr this if the second X server option isn't satisfying, thanks for the idea.
I often have problems when streaming videos where my CPU reaches high temperatures and crashes. Maybe this would solve that too. One of the videos fromthe EOMA68 crowdfunding page did just that.
EDIT: I tried the EOMA68 videos again, and no problems at all this time (though I have less programs runnig at the same time). Maybe when I use too much of my bandwidth, my CPU can't handle it. it happends 5 or 6 times, but not frequently (on a span of 1 or 2 years maybe), and it's rather random.
Also, do you have the latest xserver+etc? https://trisquel.info/en/wiki/update-linux-libre-kernel
(nevermind the misleading link title)
You mean updating that "xorg stack" thing?
That means I should update the kernel first, then this?
Yes. The order of updating these probably isn't important, And of course newer things don't _always_ work better so see for yourself.
I see, thanks for the warning as well.
I'll try to properly span another X server first, and see how this goes.
Thanks. So this stack actually updates the kernel as well.
At least in Ubuntu, I'll read the Trisquel page about this, it's probably a bit different.
You only have to replace with "wily" instead of "xenial" that is the last actualization we have in our repository.
sudo apt-get install --install-recommends linux-generic-lts-wily xserver-xorg-core-lts-wily xserver-xorg-lts-wily xserver-xorg-video-all-lts-wily xserver-xorg-input-all-lts-wily libwayland-egl1-mesa-lts-wily
I tried it. I tried the one frome Trisquel pages (not as up-to-date), and both brought improvements.
But it's still not good.
Last thing I didn't try: jxself kernel update (but there's a connection timeout right now).
Wait, I don't understand, but now it's very fluid, and even the rendering curve is below the treshold. Even Compton is on. It's great, but it would have been better if I could measure and knwo what went wrong/right so I can fix it in the future. Oh well, can't complain on this one :)
EDIT: Just out of curiosity (and also because I'm a moron), I changed the framerate limit back to it's 60 fps.
Now, no matter how many times I restart the game, it's super slow again. I'll try to restart the PC.
EDIT2: Actually a restart fixed it, or so I thought: after a few seconds of play, it went slow again, though the curves are much lower than before, but still above the threshold.
Back to figuring out that tty and X server thing...
Ok this is what I'm gonna try first: https://ubuntuforums.org/showthread.php?t=51486
If still not successful, I'll try a kernel update.
EDIT:
Ok, apart from one step of the tutorial that I didn't have to apply (something to "anybody"), it works.
The only downsides is that I had to download the assets again.
Where are they stored in that case?
The other one is that the resolution used is of the laptop's screen which is mirrored on my external screen. So the performance gain might only be an illusion.
So can I change the external screen's resolution, or only use the external screen, and not a mirrored display?
EDIT2:
Ok bad idea, I just tried to manually setup the resolution in-game, and the result is the same as when not using the second X server.
*sigh*, kernel update it is then.
Here are the steps I followed, and I'm stuck at step 5 (the update > connection timed out):
1 - sudo aptitude install apt-transport-https
2 - Then edit the /etc/apt/sources.list file on your system and add the line:
deb https://linux-libre.fsfla.org/pub/linux-libre/freesh/ freesh main
3 - wget https://jxself.org/gpg.inc
4 - sudo apt-key add gpg.inc
rm gpg.inc
5 - sudo aptitude update
6 - pae is checked, so:
sudo aptitude install linux‑libre64‑4.1
7 - cd /boot/grub
sudo ln -s grub.cfg libreboot_grub.cfg
EDIT:
From her: https://trisquel.info/en/wiki/update-linux-libre-kernel
I mixed it with the different wget command from here, it seems to work, but many things are ignored. plus no kernel or header is found when trying to install.
I'm trying this: sudo apt-get install --install-recommends {linux-generic,xserver-xorg,libgl1-mesa-glx,libegl1-mesa-drivers}-lts-utopic
I might need to reboot to see any effect I suppose. And no effect after a reboot.
jxself, I need your help on this one. It seems aptitude update does ok, but no package named linux-libre64-4.1 found.
I was reminded by jar_jar_head on IRC to ask the op if it is librebooted or not: X200 with proprietary bios has only 32MB of video ram..
Yes, it's a librebooted X200. In a way, it is reassuring : the machine might have what it takes then.
EDIT: I'll try to update Libreboot to the latest version then.
Ok, I tried the Libreoot update, unfortunately nothing improved (plus I have to figure out what to modify in the grub.cfg for automatic boot, but that's another story).
The only thing that kind of works is running the game with --render sdl.
The only issue is that since it's from the command line, it always opens in a second window that remains at half the screen size. Bottom line : I need to start the game with that option, and at full screen from the start.
Also I suppose I should ask the devs of the project.
EDIT:
Nevermind, --render sdl doesn't change a thing actually. Oh well.
I need some help on this:
I'm supposed to install mono 3.0,
but in the repo I have a hard time identifying it, or something similar.
I have libmono stuff, varying from 2.0 (even if the column version mentions 3.2.8) to 4.0.
Which one is it? Most of them are libraries.
Thank you.
Well, looks like I have very few options left. Here are the answers to my bug report https://github.com/OpenRA/OpenRA/issues/12127 , basically suggesting that my GPU is too weak, and that I should update the Kernel (still need an information from you jxself, about a connection timeout, but I'll try again first), AND Intel Mesa drivers, which are most likely non-free.
And also saying this:
OpenRA requires and utilizes OpenGL 2.0 technology what your GPU only archives through a hacked GPU driver (this is the GMA 3000-4000 series) which probably falls back to software rendering at cases.
Doubt much can be done in this regard, your issue is clearly the rendering performance (you can even see it yourself if you enable Performance Stats in Options-Debug and compare the render and tick rates).
So, X200 users and OpenRA lovers, there's still a small chance. Any libre alternative to these Mesa drivers btw ?
If the GPU supports game's OpenGL, you can run it, just lower the resolution, those Thinkpads can not to handle 3d graphics at native resolution, even with 256MiB or 352MiB.
I have all stuff needed for run external GPU, and gt740 with 2gb gddr5. But I still not tested it with thinkpad, (I have) but I not tested the external GPU for PCMCIA port.
Well, when spawning the game in a new x server (with the following command found thanks to archwiki: xinit /usr/games/openra mono --gc=sgen -- :1 vt$XDG_VTNR), I do have the laptop's native resolution also displayed on my external screen.
At first I thought it was playable, but as soon as the screen gets crowded, it's way too slow, even at the highest speed parameter. I can try an even lower resolution, but that wouldn't be as fun. I originally wanted to play at full resolution of my external screen.
I doubt the kernel update would be enough since the GPU is too weak anyway. I'm really curious about having an external GPU linked to a Thinkpad, please let me know if you made it work. That's a great idea.
Mesa is not a driver but rather an abstraction of OpenGL that sends calls to the appropriate driver if possible or does it in software otherwise. You have the driver for your GPU installed; there isn't even a proprietary driver that exists for Intel integrated GPUs and it's all integrated with Linux upstream. But your GPU cannot do everything in hardware, a physical limitation of what it can do (the hardware is designed for a particular OpenGL API and what that particular GPU supports is an older OpenGL version), so some things have to be done in software. Possibly a lot of things. This leads to poor performance because rendering OpenGL without hardware acceleration takes a lot of processing power.
In short: what you are facing is not a software problem. It's a hardware problem. The only way you can solve it is to get a newer GPU, so you might as well give up on the idea for now. The best you can do is probably to use a more recent x86 computer.
Oh well :(
Thank you for your clarifications. At least I tried all I could on this machine.
- Inicie sesión ou rexístrese para enviar comentarios