godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
88.8k stars 20.14k forks source link

Slow performance on Linux-based systems (hardware/driver dependent) #4799

Closed CheeryLee closed 7 years ago

CheeryLee commented 8 years ago

Hello! My hardware: Intel Pentium E2200, 4 Gb RAM, ATI HD 4650. I use Arch Linux (but it doesn't matter, because I get the same performance on all Linux-based systems) with opensource videodriver on my PC. With each Godot versions I get 10-15 FPS in Truck Town sample. In an empty scene everything is better, but it is far from ideal. Work becomes impossible.

On Windows 8.1 with proprietary driver everything works fine. By the way, I can't install proprietary driver on Arch, because AMD canceled the support of my card since 2013.

Maybe there is a way to solve the problem?

akien-mga commented 8 years ago

Maybe there is a way to solve the problem?

Not really, drivers are beyond our reach. If the open source Linux driver for your GPU has a bad performance, there's not much we can do :/

CheeryLee commented 8 years ago

This problem is only in Godot. Other engines like OGRE, Irrlicht or Urho3D are working fine.

Geequlim commented 8 years ago

I also using godot with Arch Linux on my laptop (i5 6200U, Intel HD520) but it is not too slow. I got more than 800 FPS in my FlappyBird game before I set it to 60 in project settings.

Calinou commented 8 years ago

Godot 3.0's OpenGL ES 3.0 renderer will have better performance, but won't support older GPUs like your HD 4650 (which isn't really a gaming GPU by the way). The OpenGL ES 2.0 renderer will probably stay available for a small while due to this.

Geequlim commented 8 years ago

I tested the Truck Town demo with my intel grapic(Intel HD520) GPU and Nvidia(GT940M) the fps seems strange.

  1. The 2D scene get 600+ fps with intel card but only 100fps on Nvidia card.
  2. The 3D scene get 80fps with intel card and 100fps on Nacidia card.

The result on intel card:

https://drive.google.com/open?id=0B0AolAabr5edTFo1cURwcDJEU2c https://drive.google.com/open?id=0B0AolAabr5edRWVya1FYRnFWTVU

The result on Nvidia card:

https://drive.google.com/open?id=0B0AolAabr5edMTBDb2Q4WWtsMTQ https://drive.google.com/open?id=0B0AolAabr5edN3lNV000dENFTzg

Maybe something wrong with my machine, so don't care about this.

slapin commented 8 years ago

@Geequlim nothing is wrong with your machine, this is how things are. My results with GTX660 are even slightly worse. The most annoying thing is occasional frame drop for simple scenes. The average framerate is high enough (about 120-150fps if no vsync locked) but it tends to do a lot of frame drops, thus quality suffers. In vsync-locked mode the frame rate occasionally drops to 20fps. To measure this you just need to get fps value and remember lowest and highest. The annoying thing is that these values are too different on simple scenes. Sometimes the frame drops are visually noticeable. Amazingly, 3D renderer really sucks comparing to Urho3D. The later runs complex scene with many ragdolls, physics effects, etc. at quicker rate than Godot runs static scene. And 3D physics/3D animation nearly kills it. Also, the promise of GLES3.0 renderer doesn't have to do with the rest of performance, as in my tests I run both on GLES2.0/OpenGL3.2 hardware for testing, so nobody can use OpenGL4 (GLES3) features. Which means there is some fundamental issue with rendering pipeline, not related to used API, so people who are interested in support of GLES2 pipeline might step in and check their thing. Especially ones with access to GPU profilers. As for physics - I added Bullet external library support for test, but it gave no (much) improvement. I think this is architectural issue, as same Bullet performs much better in other engines. Do not have much time to investigate more in this area, though.

Calinou commented 8 years ago

@Geequlim: use primusrun rather than optirun, in most cases, it gives higher performance.

reduz commented 8 years ago

@slapin Go complain to Urho3D that they have horrible tools, so they improve them and you can use it instead of Godot :) It feels unfair that you only complain to us..

Geequlim commented 8 years ago

@Calinou Yes I did use primusrun. Editor always crash if run with optirun.

reduz commented 8 years ago

@Geequlim Godot renderer is designed mostly for mobile, which is why performance is bound to the limitations of the GLES2 API. After 2.1 is out in a month or two, we'll start working on a new renderer which uses PC hardware in a more optimal way

Geequlim commented 8 years ago

@reduz I'm happy to hear that. And hope for it :)

slapin commented 8 years ago

@reduz probably because I still use Godot as I still not lost all hope. Hope you don't insist.

On Wed, May 25, 2016 at 4:28 PM, Juan Linietsky notifications@github.com wrote:

@slapin https://github.com/slapin Go complain to Urho3D that they have horrible tools, so they improve them and you can use it instead of Godot :) It feels unfair that you only complain to us..

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4799#issuecomment-221575711

akien-mga commented 8 years ago

@Geequlim I'm a bit surprised by the round 100 FPS limitation on two different scenes with your Nvidia GPU though. Are you sure it's not primusrun that caps FPS? Normally it's configured to cap at 60 FPS, but maybe you configured it otherwise? You could try to run Godot with vblank_mode=0 primusrun godot

reduz commented 8 years ago

@slapin I can understand your excitement and really value your loyalty, but you will have to wait for a few months or even half a year until Godot provides what you need. I hope you can understand that

Geequlim commented 8 years ago

@akien-mga No I didn't configured the fps caps manually. The same result with vblank_mode=0 primusrun godot.x11.tools.64 I just tested.

akien-mga commented 8 years ago

Thanks for checking. It's quite peculiar that you get a worse performance with Nvidia than with Intel on 2D... Bumblebee is a pile of hacks so there should be some overhead, but that much is surprising.

CheeryLee commented 8 years ago

@reduz Err... as much as it may sound strange, but the development does on PC, not on mobile devices.

Geequlim commented 8 years ago

@CheeryLee Godot is gonna be better day by day please give some time for it. Contributors are trying best to make it better aren't we?

CheeryLee commented 8 years ago

@Geequlim Sure, Godot is really gonna be better, but the problem with rendering completely depresses. :( There is no desire to use the engine for me.

reduz commented 8 years ago

@CheeryLee Well, you use Linux, so a certain level of technical expertise is to be expected In this case, I'm inclined to think that it may be a driver related issue, and the fact this hardware is old may not help.

We really have our hands full with other, more important, issues, so how about you talk to the developers of the open source Radeon driver to see if they can take a look at it and find the bottleneck?

@Calinou Radeon 46xx is a DirectX 10 class CPU, should support OpenGL ES 3.0 fine.

reduz commented 8 years ago

Also, there are plenty of reports of people having issues that only happen with Arch Linux, I'm inclined to think something is wrong with that distribution. Did you try the opensource driver somewhere else?

bojidar-bg commented 8 years ago

@reduz ~ The main problem with arch is GCC 6, check https://github.com/godotengine/godot/issues/4623

CheeryLee commented 8 years ago

@Calinou Yep, my 4650 has fully OpenGL ES 3.0 support.

@reduz As I already wrote, I have tried many Linux distributions from Ubuntu to Arch Linux. This problem is on all. For example, OGRE with OpenGL ES driver works fine.

Calinou commented 8 years ago

@reduz ~ The main problem with arch is GCC 6, check #4623

There is a workaround for this, you can compile Godot using Clang. It works well for me. Use this SCons build line to compile Godot from source:

scons platform=x11 colored=yes use_llvm=yes

More information about compiling for Linux.

reduz commented 8 years ago

@CheeryLee I'm not denying there is a problem that happens only with Godot, but this is clearly a driver bug. Please understand that:

1) None of the developers have this hardware 2) This needs to be solved by the driver developers

As such, I'm asking you to file an issue with them (or contacting them), as well as keeping track when they fix it if the fix actually works. There really isn't much we can do from our side.

slapin commented 8 years ago

Well, using email to reply to github comments does have its limitations, Alexander, the render issues should not frustrate you, you can still have lots of fun!

https://www.youtube.com/watch?v=j99vFXPXHHA

Also, the locked frame rate is close to 60 for this demo with drops to 30 which is still mamageable (nvidia gtx660). But whatever, you can do a lot with this if you have some imagination. I think if we had enough people who want to work on 3D improvement for Godot we could work on fork and eventually things will improve. @reduz prefers slow pace there measuring time in years, not seconds. Many people do not have this much time, but that is up to him to decide.

On Thu, May 26, 2016 at 8:32 PM, Alexander Pluzhnikov < notifications@github.com> wrote:

@Geequlim https://github.com/Geequlim Sure, Godot is really gonna be better, but the problem with rendering completely depresses. :( There is no desire to use the engine for me.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4799#issuecomment-221939775

reduz commented 8 years ago

@slapin We are currently discussing a driver bug here, please don't butt in with your childish rants

CheeryLee commented 8 years ago

@reduz OK, I understand you. So let's go to the other side: how about writing OpenGL (not ES) part for Godot? Where can I get more info about engine architecture?

slapin commented 8 years ago

@reduz I think you messed me with someone else, I did not rant there, I proposed a little thing. I also mentioned that I and a few people do have problems with nvidia and nvidia blob, so it is neither arch-related nor AMD-related or intel thing. I try to be helpful here regardless of your opinion, like it or not. If you don't like what I do I think you can use administrative resource of course, but otherwise I hope you will not try to offend me anymore - that looks stupid and counter-productive.

On Thu, May 26, 2016 at 9:38 PM, Juan Linietsky notifications@github.com wrote:

@slapin https://github.com/slapin We are currently discussing a driver bug here, please don't butt in with your childish rants

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4799#issuecomment-221957495

reduz commented 8 years ago

@CheeryLee Godot does use OpenGL on Linux. when we mention that it uses OpenGL ES, we just mean that it uses only the portions of the API that are compatible with the ES version. It's still regular everyday OpenGL, and it's clearly to me that this is a driver problem on Linux

reduz commented 8 years ago

@slapin If it works well on Windows and fails on Linux, it is clearly a driver issue. In fact, on Ubuntu with both AMD and NVidia blob, I never had any issues. Even most people on Irc told you the same many times.

You somehow expect me to do magic and fix a problem I can't reproduce. How about instead of complaining and playing as a poor victim who can't finish his game due to slow performance, you go and talk to the driver developers so they help you find out what the bottleneck is?

Complaining and playing the victim will seriously not get you anywhere, you simply ridicule yourself by doing this. If you want this issue solved, go and talk to the Mesa developers.

slapin commented 8 years ago

@reduz I don't use mesa-based drivers currently and have very heavy games playing at max settings (SR2,3,4, Metro, etc. all stuff from Steam), the only problem is with Godot. https://gist.github.com/6cc0a148c5e2c520157dd2df9f736e4b

And no, not laptop, stationary PC, CPU is i7 2600K, 16GB RAM.

On Thu, May 26, 2016 at 10:05 PM, Juan Linietsky notifications@github.com wrote:

@slapin https://github.com/slapin If it works well on Windows and fails on Linux, it is clearly a driver issue. In fact, on Ubuntu with both AMD and NVidia blob, I never had any issues. Even most people on Irc told you the same many times.

You somehow expect me to do magic and fix a problem I can't reproduce. How about instead of complaining and playing as a poor victim who can't finish his game due to slow performance, you go and talk to the driver developers so they help you find out what the bottleneck is?

Complaining and playing the victim will seriously not get you anywhere, you simply ridicule yourself by doing this. If you want this issue solved, go and talk to the Mesa developers.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4799#issuecomment-221964412

reduz commented 8 years ago

@slapin The issue here is that Godot is hitting a driver bug or bottleneck on some configurations. The fact that other software does not exhibit this behavior does not imply a problem with Godot.

If you want this situation to change in the short term, complain to whoever wrote the driver. Further insistence from your part on this issue will be ignored.

reduz commented 8 years ago

@slapin If you have a Windows machine or partition, you could experiment with opengl debuggers to see where the bottlenecks may be. Please understand that I don't have any hardware with problems so I can't do this myself

reduz commented 8 years ago

@McFarts I have a really old laptop AMD gpu with worse hardware and Godot runs fine with the propriertary drivers on Ubuntu, so I don't think it's a hardware issue

CheeryLee commented 8 years ago

@McFarts Don't make conclusions based under one program. I have this hardware for 6.5 years and can say that it exactly what I need. If one of the dozens of programs is not working properly, then the conclusion is obvious -- it is not a hardware issue as Juan said. Just a bug in GPU driver as I understand.

akien-mga commented 8 years ago

To be more specific regarding what @reduz has stated already: the symptoms we have here seem to indicate:

The combination of those two facts means that Godot likely uses GL features that those drivers don't support properly. It can either be a plain driver bug, or that Godot uses GL features that are only properly supported by proprietary drivers by chance, and that we should adapt our renderer to be more forgiving for open source drivers. In both cases, we need help from developers of the open source drivers to help us go forward, especially if our renderer expert @reduz does not have any hardware to reproduce the issue.

SuperUserNameMan commented 8 years ago

@McFarts : actually the single core and dual core power of his Pentium E2200 is almost the same than with the more recent AMD A6-6310 APU that i'm using on my laptop and on which Godot works pretty well. Same for his GPU. His ATI HD 4650 has the same score than my Radeon R4.

The main differences are :

Old hardware does not mean outdated.

retrotails commented 8 years ago

This might be related, this happens to me with both open source and hybrid drivers (no fully closed drivers for the RX 480, only AMDGPU and AMDGPU-PRO) https://i.imgur.com/UOeG2iL.png My modern desktop does significantly worse than Intel HD 3000 graphics, getting 10 FPS in a scene with nothing but a bunch of test cubes and a single light source with shadows. It does seem like driver overhead, as my significantly faster xeon is apparently spending 6x as much time to render frames as my laptop (as you can see, the "glDrawElements" on the top bar and the highlighted text) I'm really curious what's causing it, because it makes game development nearly impossible (my actual game is getting 5FPS in the editor and I'm only just starting) meanwhile I have no issues running any complex games or demos, just Godot. And literally everything in Godot seems to have a huge effect, shadows cut the framerate in 1/4, just rendering a few objects reduces performance to a slog. For reference, this is also on Archlinux, while in Windows its usable, it's still an order of magnitude slower than my 970 was, which is a very comparable card. Other linux distros I've tested perform the same as Arch.

Gibbz commented 7 years ago

Yes i have the same issue on godot 2.1 and also latest from github as of today. 3D is chugging hard (about 15fps) on a AMD 7970 using mesa open source driver on ubuntu 16.04.

If this is a mesa driver bug, how is the best way to report it? Edit: Added a bug report here: https://bugs.freedesktop.org/show_bug.cgi?id=99319

Please add your info to the bug report, hopefully someone will look into it...

Gibbz commented 7 years ago

Ive also thrown up a demo showing the situation with some stuff from my current project. There is a build here: https://drive.google.com/open?id=0B_nQZvJoqbFmRUtYT3pnUm14Szg It will load straight into a map, press "p" to bring up there performance dialog.

On my various amd card in the house i get between 2-12 fps. On my integrated intel I get about 50-60fps. So there is definitely some issue here with the amd cards.

reduz commented 7 years ago

MESA drivers in general suck, and I don't think there is much that can be done to improve the situation. Shaders run fast, but a low number of draw calls is enough to bring performance to a halt. This is not really a Godot problem. Once Godot 3 is out, we should make some benchmarks and ask the MESA guys to fix their drivers..

On Fri, Feb 17, 2017 at 9:56 PM, Gibbz notifications@github.com wrote:

Ive also thrown up a demo showing the situation with some stuff from my current project. There is a build here: https://drive.google.com/open?id=0B_nQZvJoqbFmRUtYT3pnUm14Szg It will load straight into a map, press "p" to bring up there performance dialog.

On my various amd card in the house i get between 2-12 fps. On my integrated intel I get about 50-60fps. So there is definitely some issue here with the amd cards.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/4799#issuecomment-280806705, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z28WfGSvw51NcZdI8kjJ5J2Fu4nM9ks5rdkHCgaJpZM4Ilm80 .

camrodgers commented 7 years ago

I posted to confirm that I have this problem too in the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=99319#c6

MESA drivers in general suck, and I don't think there is much that can be done to improve the situation.

Godot devs, the MESA driver has been making very fast progress lately. AMD cards now perform really well in a lot of games. I've seen games like TF2 go from unplayable and crash-prone to perfectly smooth in just a few months with my RX 460. I think at least one of you should consider getting a cheap AMD card for testing purposes. It's the only gaming GPU brand with official open source drivers. You probably would have caught this bug months ago and it would be fixed right now in MESA 17.

slapin commented 7 years ago

Lets not put all problems on Mesa and drivers. Lets see how 3.0 will perform on proprietary ones.

On Sat, Feb 25, 2017 at 6:22 AM, i9i7 notifications@github.com wrote:

I posted to confirm that I have this problem too in the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=99319#c6

MESA drivers in general suck, and I don't think there is much that can be done to improve the situation. Godot devs, the MESA driver has been making very fast progress lately. AMD cards now perform really well in a lot of games. I've seen games like TF2 go from unplayable and crash-prone to perfectly smooth in just a few months with my RX 460. I think at least one of you should consider getting a cheap AMD card for testing purposes. It's the only gaming GPU brand with official open source drivers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/4799#issuecomment-282456129, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAX0y661RnX-ifFdqG_rOmdxOX1Shxqks5rf55ZgaJpZM4Ilm80 .

bojidar-bg commented 7 years ago

@slapin ~ @reduz said a few times already that since he can't reproduce the issue, he can't fix it. That's why he suggested more than once using some OpenGL Debugger or Profiler to find the bottleneck.

Here are a few links I found using ddg for "OpenGL Profiller" (and related queries):

  1. gDEBugger
  2. SO question about FOSS profiler for linux
  3. BuGLe (Looks more like a debugger, but might offer profiling)
  4. vogl (Not sure what this does exactly)
slapin commented 7 years ago

Well, I decided to wait and see the future, so I'm not really helpful at he moment. I currently use different OSS engine of my projects, so I do not have too much motivation to work on this issue, but I hope somebody will.

On Sat, Feb 25, 2017 at 1:33 PM, Bojidar Marinov notifications@github.com wrote:

@slapin https://github.com/slapin ~ @reduz https://github.com/reduz said a few times already that since he can't reproduce the issue, he can't fix it. That's why he suggested more than once using some OpenGL Debugger or Profiler to find the bottleneck.

Here are a few links I found using ddg for "OpenGL Profiller" (and related queries):

  1. gDEBugger https://www.opengl.org/sdk/tools/gDEBugger/
  2. SO question about FOSS profiler for linux http://stackoverflow.com/questions/3235864/open-source-opengl-profiler-for-linux
  3. BuGLe https://www.opengl.org/sdk/tools/BuGLe/ (Looks more like a debugger, but might offer profiling)
  4. vogl https://github.com/ValveSoftware/vogl (Not sure what this does exactly)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/4799#issuecomment-282475467, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAX01aEbwUo1wn3QD55udkklbYb5q8Eks5rgANkgaJpZM4Ilm80 .

retrotails commented 7 years ago

As someone mentioned on that freedesktop.org link above, it's fixed in mesa git. Not sure if it'll make it to the next major release but I'm on the git branch now, and the platformer demo went from 3fps to 250fps. I'm still curious what godot does different that mesa didn't like, maybe if we find the mesa commit that fixed it we'll know. But what's important is, it's on the way to being fixed and not a godot issue.

akien-mga commented 7 years ago

@retrotails To be sure, did you try to build the last major release with the same arguments? If you were testing with your distro's mesa release, the low performance might be related to some of their compilation flags.

retrotails commented 7 years ago

@akien-mga Just compiled the git release of mesa with the same arguments as my distro (arch) hopefully that's good enough because that's what's easiest. Still performs well.

ghost commented 7 years ago

AMD rx 470 guy here. On 2.1 in 2D platfromer there are little drops to 53 fps and 3D averages on 2 fps. Open source radeon driver, kubuntu 16.10 x64. Really weird considering I run Cities: Skylines and Civ 6 on max settings with 60 fps

If there are 3.0 demos somewhere I can try those.

P.S. and if someone gives me instructions on how to get debug from opengl I can provide logs.