Godot: Slow performance on Linux-based systems (hardware/driver dependent)

[CheeryLee]

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]

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]

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

[Geequlim]

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]

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]

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]

@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]

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

[reduz]

@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]

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

[reduz]

@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]

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

[slapin]

@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 [email protected]
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]

@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]

@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]

@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]

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]

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

[Geequlim]

@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]

@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]

@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]

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]

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

[CheeryLee]

@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]

@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]

@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]

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 <
[email protected]> 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]

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

[CheeryLee]

@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]

@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 [email protected]
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]

@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]

@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]

@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 [email protected]
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]

@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]

@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]

@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]

@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]

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

• An issue that affects only open source drivers on Linux
• An issue that affects apparently only Godot, out of the applications the reporter(s) tested

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]

@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 :

• his config consume up to 100 Watts ; mine 15 Watts
• his OS is Linux ; mine Windows 8.1 64bits

Old hardware does not mean outdated.

[retrotails]

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]

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]

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]

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 [e-mail] 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]

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]

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 [e-mail] 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]

@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]

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 [e-mail]
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]

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]

@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]

@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]

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.

[ghost]

Tested directional light demo from #8009. Performance is around 850 fps http://i.imgur.com/CPePSCn.png
glxinfo output:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 / 4.8.0-41-generic, LLVM 3.8.1)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 12.0.6
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 12.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 12.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

For comparison, Calinou with GTX1080 gets around 1500 fps

[Gibbz]

Just tested mesa git 17.1 and have not noticed any performance improvement. My project still is about 6-10 fps, while on another machine, running mesa 17.0 gets 60fps.
Both on AMD gpu's.

[27thLiz]

The bottleneck that caused this seems to be resolved with the new renderer.
With godot 2.1 the Astrid game is barely playable on my HD7870 with mesa drivers.
On the master branch everything is fine, fps are as expected.

[Gibbz]

The issue still exists on godot 3.0 for me.

[eon-s]

There are new "rendering" options you can lower or turn off to get better performance, these are project settings but affects the editor, it should have its own "editor" settings for lower quality while editing...

[Gibbz]

Im thinking at this stage it may be a draw call issue?
With my high resolution terrain on screen its fine at almost 60fps. Soon as i add a few simple cube meshes to the same scene performance drops down to about 4-10fps....

[reduz]

On Godot 3.0 and AMD mesa, performance was really bad. With propertary AMD
it was great, as well as NVidia.

Unfortunately all we can do is ask the MESA devs to fix the performance
problems on their side.

On Apr 23, 2017 8:40 AM, "Gibbz" [e-mail] wrote:

Im thinking at this stage it may be a draw call issue?
With my high resolution terrain on screen its fine at almost 60fps. Soon as
i add a few simple cube meshes to the same scene performance drops down to
about 4-10fps....

—
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-296423259,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z25z5BNHxD-55kbfO1exvg1sDMC__ks5ryvJcgaJpZM4Ilm80
.

[eon-s]

The demos that run slow here on 2.x are Kinematic and Platformer (on 2 AMD cards, super old and not so old), the only relation I see is the Gridmap...

Removing the Gridmap everything returns to normal.

[Gibbz]

Can i ask anyone else with this issue:
Do you have 1 cpu core maxing out at 100% and the remaining cores sit at 2-4%?
Im wondering if the cpu is choking causing the frame rate to drop...

[retrotails]

@Gibbz I'm back on stable mesa drivers so I still have the issue, and no its pretty even across cores.
https://i.imgur.com/NOGytap.png

[TritiatedWater]

I used to have this issue on Manjaro untill i updated mesa to 17.1.
I'm using the open source amdgpu with my rx 480.

[camrodgers]

I'm on mesa 17.1 and AMDGPU, the issue is fixed for me as well in Godot 2.

[eon-s]

With Mesa 17.1 the issue with GridMap is gone too.

[akien-mga]

Kudos to the Mesa devs then :)

I propose to close this issue, and have people still experiencing issues with recent drivers open new ones. There are likely several sources of performance bottlenecks based on the hardware/driver/platform, so having everything in the same issue is not really helpful.