Godot: Poor performance on Intel GPUs

[ghost]

(I couldn't find an open issue for this, so I'm opening a new one. Using Arch Linux with Mesa 17.1.4, using current master.)

3D performance is quite poor with Intel GPUs. On a 4770K, even after disabling high quality VCT, I'm getting around 20FPS for 3D demos (platformer, kinematic, materials, ....). With high quality VCT present, it drops to around 5FPS.

[BrainBlasted]

Test file? I'm on Arch using mesa 17.1.4-1, Intel HD 4000. I'd like to see if I can reproduce.

[vnen]

@BrainBlasted the OP mentioned the demo projects, you can get them here: https://github.com/godotengine/godot-demo-projects

[BrainBlasted]

Ah, my bad. Didn't quite catch that.
I found similar results when working on my machine. The platformer demo worked acceptably, generally in the 30 range with HQ VCT, sometimes got near the 40s without. The platformer and materials demos both hovered in the teens to the 20s, sometimes dipping lower without HQ VCT. I opted not to test with HQ VCT due to an overheating issue with my laptop.

[ghost]

@BrainBlasted That's quite interesting, I've never seen anything beyond 25FPS on my Haswell so far. Could you give more information about your hardware? (Which CPU is it? Do you have a second GPU?)

I also have laptop with an M460 (Westmere, with Ironlake GPU) lying around; I don't expect much but I'll check the performance with that too.

[reduz]

The 3D platformer demo does not have VCT activated, so this is weird.. did
you put a GIProbe in there yourself?

On Thu, Jul 20, 2017 at 12:48 PM, Ferenc Arn [e-mail]
wrote:

@BrainBlasted https://github.com/brainblasted That's quite interesting,
I've never seen anything beyond 25FPS on my Haswell so far. Could you give
more information about your hardware? (Which CPU is it? Do you have a
second GPU?)

I also have laptop with an M460 (Westmere, with Ironlake GPU) lying
around; I don't expect much but I'll check the performance with that too.

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

[BrainBlasted]

@tagcup i7-3630qm, an Ivy Bridge CPU with Intel HD 4000, 8GB of DDR3 system RAM, from around 2013. @reduz I did not place any GIProbes, just downloaded the files from the link, imported the projects, and ran the scenes. Could be that the difference there was due to unseen differences in the testing environment.

[ghost]

@reduz Sorry for not being clear: I never tried HQ VCT with standard demos. I have a custom simple scene with a GI probe (just a simple "terrain" mesh and a few simple object plus a makehuman model, default project settings, a very simple world environment with nothing optional, such as SSAO SSSR glow DOF, enabled), which also gives me the same ~20FPS, and the FPS plummets to 5FPS if I enable the HQ VCT in that scene. It's a debug build.

I can try adding a GI probe in one of the demos, and see how it affects the FPS, but I'm guessing it's going to be roughly the same.

@BrainBlasted That's really odd. Are you using a debug or release build?

[BrainBlasted]

Using a release build.

On Thu, Jul 20, 2017, 5:16 PM Ferenc Arn [e-mail] wrote:

@reduz https://github.com/reduz Sorry for not being clear: I never
tried HQ VCT with standard demos. I have a custom simple scene with a GI
probe (just a simple "terrain" mesh and a few simple object plus a
makehuman model, default project settings, a very simple world environment
with nothing optional, such as SSAO SSSR glow DOF, enabled), which also
gives me the same ~20FPS, and the FPS plummets to 5FPS if I enable the HQ
VCT in that scene. It's a debug build.

I can try adding a GI probe in one of the demos, and see how it affects
the FPS, but I'm guessing it's going to be roughly the same.

@BrainBlasted https://github.com/brainblasted That's really odd. Are
you using a debug or release build?

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

[ghost]

OK, got some numbers. I've tested using the original materials demo using release_debug build (just compiled from current tip). It starts around 40FPS for a few frames and quickly settles down to 34FPS after 1-2 seconds the beginning.

Now, as I press the "next" button (bottom right corner of the screen) and advance through materials, the FPS starts to degrade. I'm only pressing next, and nothing like (no camera rotation or anything like that). As I reach the toon material, the FPS is around 16FPS.

Using mesa 17.1.5.

[ghost]

Performance with 3D platformer is acceptable though: it oscillates between 52-58FPS.

[ghost]

This is how the FPS degrades as I cycle through the materials using the next button in the material demo:

Material | FPS
-----|-----
white plastic | 37
mirror | 30
dark wood | 26
cheese | 24
stones | 23
brick | 21.5 (oscillates between 21 and 22)
wool | 20.5
aluminium | 19.5
marble | 19
wet sand | 18
rock | 17
ice | 16
toon | 17.5

Disabling SSAO helps a lot at the beginning, it starts at 54.5FPS but degrades to 19.5FPS at the end, but I haven't been able to find a single thing (like IOR or subsurface scattering) that is responsible for the drop in FPS.

After removing the spotlight from test_bed, FPS decays from 47.5 to 20.5, with similar decay characteristics.

[ghost]

Things that take away at least 5FPS (starting from the best possible condition without spotlights or SSAO at 60FPS) are:

• SSAO
• Spotlight per stand
• Depth map
• Refraction

Subsurface scattering takes only 1-2FPS.

[groud]

@tagcup Can you test with current master if SSAO still drops performances ?
If fixed a display issue due to cos and sin doing crazy stuff with high values. It might have positively impacted performances.

[ghost]

Yeah, still slow...

[reduz]

I wish I had any hardware like this to test.. but what you describe seems to be mainly memory bandwidth issues to me, I wonder if anything else is at play..

[ghost]

Yeah, me too :) I wish SFC could arrange test hardware for you.

I meanwhile tested this on Xeon E3-1225 v3 (also Haswell), observing similar slowdown.

I wonder if someone can test this on Windows?

[reduz]

Still.. the slowdown is strange.. that should not happen at all...

[ghost]

As you move using the next button, you get more objects in the view frustum, and the additional slow down in each step depends on the new things (new test material, spotlight, ...) added into the view frustum as you move

[DriNeo]

I can confirm this with my Intel HD4600, Linux LMDE and Mesa driver.
Kinematic character 3D runs around 20 fps on Godot 3.0 Alpha 2. On Godot 2.1.3 this demo runs at 55 fps.

I don't know if theses messages are relevant but this is the only errors displayed.

ERROR: create: Expected data size of 174760 in Image::create() At: core/image.cpp:1180. ERROR: texture_get_data: Condition ' texture->data_size == 0 && !texture->render_target ' is true. returned: Ref<Image>()

Edit: I noticed the same issue on Windows 8.1 with a freshly updated GPU.

[ghost]

At least in the 3D editor, there is a workaround to make it fast: the viewport now has an option to display it at half-resolution. The game itself is still super slow though.

[reduz]

@tagcup I am trying this in an older notebook I have (which has a low end AMD IGP) and it's considerably slower than it used to be. I have the feeling I broke something. Was rendering at some point faster with your hardware?

[ghost]

It used to be relatively faster, yeah. It went from 19FPS to something like 6-10FPS

[ghost]

Also, it used to work quite fast (probably close to 60FPS) on an old laptop with nvidia 425M, but it was below 10FPS last I checked

[reduz]

is threre any chance you could bisect that?

On Fri, Nov 17, 2017 at 2:03 PM, Ferenc Arn [e-mail]
wrote:

Also, it used to work quite fast (probably close to 60FPS) on an old
laptop with nvidia 425M, but it was below 10FPS last I checked

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

[ghost]

Sure, I can give it a try this weekend if I can finish exposing additional compression options before beta, otherwise I can do it next week

[reduz]

alright, yeah i guess compression options is more important before beta

On Fri, Nov 17, 2017 at 3:14 PM, Ferenc Arn [e-mail]
wrote:

Sure, I can give it a try this weekend if I can finish exposing additional
compression options before beta, otherwise I can do it next week

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

[ghost]

Yeah since new compression options from #12972 is going to break API so it must be done before beta

[ghost]

But if someone else would like to take a shot at bisecting this, it was probably sometime around late September or early October

[ghost]

I should be able to bisect it during thanksgiving.

However, as a note regarding this comment in new GI Probe docs

Performance requirements are higher than for lightmaps, so it may not run properly in low end integrated GPUs (may need to reduce resolution).

This almost sounds like things should work fine on IGPs in we don't add a GI Probe, but that's not the case at all.

At no point in time, I've ever seen the new renderer run properly (like, it never went beyond 20FPS in Haswell, even before the regression I'm planning to bisect), without GI Probe. Adding GI Probe makes it even worse (like 5FPS), as I mentioned earlier in this thread.

[ghost]

So what I'm trying to say is, it may be better to remove any references or performance hints to IGPs from the docs, because the performance on certain, if not all, IGPs is at the level of being unusable at the moment, regardless of any tuning.

I don't know if this long standing performance issue on Intel Haswell will ever be fixed (which existed long before the regression around late September) (I hope it will, because if the materials demo works at 20FPS on a Xeon workstation with 48 cores, it's hard to believe Godot can run on low-end devices), but I really recommend weeding out any references to IGPs at this point, because Godot would lose all trust because of the claims made about Godot's new renderer (like it will run on low-end devices smoothly etc).

[ghost]

It could even be better to pitch it as a high-end engine for 3.0, and explicitly defer low-end devices and IGPs to 3.1 in announcements.

[reduz]

I still have some time and ideas to tweak it for low end, have some hope :P

On Tue, Nov 21, 2017 at 2:44 PM, Ferenc Arn [e-mail]
wrote:

It could even be better to pitch it as a high-end engine for 3.0, and
explicitly defer low-end devices and IGPs to 3.1 in announcements.

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

[ghost]

Fingers crossed :)
I'm actually hopefully it will eventually be resolved (I'm guessing 3.1; and I know you don't have the hardware, so I can run tests etc if you need), I'm just thinking it could be possible get ahead of people's reaction when they try 3.0 on a desktop with IGP or phones and see the performance...

[akien-mga]

FWIW, I have (or had, now I'm using the discrete Nvidia GPU, haven't tried Intel since a couple of months) pretty decent performance with Intel HD 4000 on Linux with latest MESA. And we haven't had a lot of complaints about this either, so I think that @reduz's assumptions regarding performance on IGPs are not completely wrong, but there are indeed some cases like yours where performance goes nuts.

Edit: I'll retry the current beta on my Intel HD 4000 though, to see if things changed.

[groud]

In fact I also have an intel 4000 IGPU, and I have really bad performances on the material tester demo. If this can be fixed, if it's possible, that could be cool :)

[ghost]

And we haven't had a lot of complaints about this either

I have a feeling that you'll get a lot of those after the wider audience actually start using 3.0.
At that point, this won't just be "the editor is" slow, but it'll also be about people not wanting to release games with minimal hardware notices excluding certain widely used Intel GPUs.

[ghost]

And for the record, Intel 4k GPUs aren't that bad, so I don't think this is about tweaking a quality knob or anything. I have never seen a game lagging at that resolution on this hardware (like when you run materials demo, it runs in a small window), most steam games run just fine, so I'm pretty sure this is about Godot's rendering pipeline.

[akien-mga]

Fair enough - I didn't mean to question the validity of this bug, just to say that on my Intel HD 4000, performance was quite decent last time I checked (compared to other OpenGL 3.3 apps with similar graphics). But yes, there are definitely bugs that need to be fixed before the release to have a consistent and good behaviour on IGPs.

[djrm]

i tested with my i7-3667u processor and the performance is really bad, i get 15 FPS with materials demo (in editor), of course i dont expect to be able to develop a game in such hardware but still, i expected better results.

[reduz]

Haven't tried the material tester yet, but so far using GIProbe and running
on intel performance analyzer, it seems there is 30% of GPU stall.. which
seems to mean memory cant keep up. This is pretty surprising because
running in a 8 years old GTX 450, I could get better performance.

This makes me think the main issue here is slow GPU access to memory. The
strange thing is that, on my desktop when I tested on an AMD A8 integrated
GPU, performance is also considerably higher.

Maybe something else is keeping Intel slow.

On Tue, Nov 21, 2017 at 8:01 PM, Daniel Ramirez [e-mail]
wrote:

i tested with my i7-3667u processor and the performance is really bad, i
get 15 FPS with materials demo (in editor), of course i dont expect to be
able to develop a game in such hardware but still, i expected better
results.

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

[reduz]

Disabling HDR (forcing buffers to 8 bit), changing voxel cone tracing to
low quality and and disabling SSAO, Intel 520 with Sponza goes from 15 to
45fps, which is pretty usable..

I suppose in a game you could tweak these things in the settings to get the
game to run :P

With the material tester, the biggest performance hit is also the SSAO. I
think I will have to implement a half resolution SSAO option to get this to
work better on Intel.

On Tue, Nov 21, 2017 at 10:26 PM, Juan Linietsky [e-mail] wrote:

Haven't tried the material tester yet, but so far using GIProbe and
running on intel performance analyzer, it seems there is 30% of GPU stall..
which seems to mean memory cant keep up. This is pretty surprising because
running in a 8 years old GTX 450, I could get better performance.

This makes me think the main issue here is slow GPU access to memory. The
strange thing is that, on my desktop when I tested on an AMD A8 integrated
GPU, performance is also considerably higher.

Maybe something else is keeping Intel slow.

On Tue, Nov 21, 2017 at 8:01 PM, Daniel Ramirez [e-mail]
wrote:

i tested with my i7-3667u processor and the performance is really bad, i
get 15 FPS with materials demo (in editor), of course i dont expect to be
able to develop a game in such hardware but still, i expected better
results.

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

[reduz]

Also using a smaller GIProbe (64 instead of 128), or compressing it (which
looks like ass) makes the FPS top at 60.
So I guess it can be used eventually with less quality.

On Tue, Nov 21, 2017 at 11:18 PM, Juan Linietsky [e-mail] wrote:

Disabling HDR (forcing buffers to 8 bit), changing voxel cone tracing to
low quality and and disabling SSAO, Intel 520 with Sponza goes from 15 to
45fps, which is pretty usable..

I suppose in a game you could tweak these things in the settings to get
the game to run :P

With the material tester, the biggest performance hit is also the SSAO. I
think I will have to implement a half resolution SSAO option to get this to
work better on Intel.

On Tue, Nov 21, 2017 at 10:26 PM, Juan Linietsky [e-mail]
wrote:

Haven't tried the material tester yet, but so far using GIProbe and
running on intel performance analyzer, it seems there is 30% of GPU stall..
which seems to mean memory cant keep up. This is pretty surprising because
running in a 8 years old GTX 450, I could get better performance.

This makes me think the main issue here is slow GPU access to memory. The
strange thing is that, on my desktop when I tested on an AMD A8 integrated
GPU, performance is also considerably higher.

Maybe something else is keeping Intel slow.

On Tue, Nov 21, 2017 at 8:01 PM, Daniel Ramirez <[email protected]

wrote:

i tested with my i7-3667u processor and the performance is really bad, i
get 15 FPS with materials demo (in editor), of course i dont expect to be
able to develop a game in such hardware but still, i expected better
results.

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

[ghost]

45fps, which is pretty usable..

Wait, do you actually expect people to be OK selling games maxing at 45FPS on Haswell? Again, I don't think it makes sense to shift the blame to the hardware: same assets (no game logic whatsoever) work with no stalls at all on Unity here.

BTW, I have no GIProbe, I tried disabling SSAO and HDR, I'm getting 33 FPS on 4770K.

compressing it (which looks like ass)

Is GI compression working now?

[ghost]

And this is at 1080p on Unity with GI versus 1024x600 without GI on Godot.

[reduz]

There is not much that can be done about it. Unity renderer is simpler and more limited, and GI is baked with lightmaps. We will only support this in Godot 3.1.

In market terms for shipping a game, it clearly does not mean much though, and current supported specs are fine:

http://store.steampowered.com/hwsurvey/

[ghost]

Yes, for this reason, if you go back and read it again, I compared Godot without GI, at the crappiest quality it is possible at a resolution that is joke, and Godot still crawls.

Well, if you take the average for this for for those who contributed to Steam survey (not everyone does BTW), Intel is sitting around 15-20%, and you're basically brushing it off with "it clearly does not mean much though".

I don't agree, at all, and I'm glad you made it clear, because if that's going to be your attitude, I don't want to waste anymore time with Godot.

[DriNeo]

If Karrofel can be hired by Godot community, is there a chance for doing research on feasible optimization techniques?
Developers just need a little help.

[reduz]

@tagcup Allow me to explain better what the problem is because it's not too obvious.

Unlike Unity, Godot 3 on intel is slow because:

• The renderer is more complex, renders to more G-Buffers and uses 16 bits precission. You can change this by disabling HDR and setting the render mode to 3D without effects.
• Godot also uses texture arrays instead of mipmaps for sky roughness, this is slower. You can disable it in the quality settings too.
• Godot shaders are written for more modern GPUs, and does not try to optimize for non dependent texture reads. Unity is mostly a mobile engine, so it´s very optimized for this. On more modern Intel, AMD or NVidia this is also not a problem. We will only be able to optimize this in Godot 3.1 when a GLES2 backend written in the same way as 2.1 is done.

If you tweak settings in the quality, you´ll see it should be easy to improve performance, but there is a limit given how the GLES3 renderer is made. As the target market for most games is not your hardware, the new renderer was not designed for it.

There really isn't much to optimize, I already ran the shaders through AMD and Intel profilers and they are fine the way the are. The GLES2 backend will be created for better performance on mobile, and low end PC (which is not meant to have complex graphics).

[ghost]

I tried everything you said and that limit of performance is still less than 40FPS, it looks pretty bad and at 1024x600 resolution.
I also tried it on a LG G6 (which is as new as it gets) and it crawls there too.

Unity in the same hardware runs smoothly and looks nice. Of course, it's a matter of optimization.

I don't know if the upcoming GLES 2 renderer will actually solve the performance problem, or how many features it's going to take away. It doesn't sound to me it will be possible to make a game that looks and runs well on mobile or "low end desktop" (which is pre-skylake, so I wouldn't call it low end but rather call Godot high end). For this reason, I'm dropping Godot, and going back to Unity.

I only wish you were more upcoming about this from the beginning. Your devlog posts about the upcoming renderer features and how it's going to be fast on low end devices was the thing that actually got me into Godot, and now I see all of that was baseless. And I wasted a lot of time based on that. For this reason, I'm finding it hard to believe any claim or promise you're making, I simply can't until I someday see a nice scene running well on Godot on my computer and phone without crippling the features.

And I hope you'll be more forthcoming about Godot 3.0 being a high-end game engine in the release notes such that other people won't get burned too.

Anyway, I wish you all the best with Godot.

[reduz]

@tagcup Maybe it was a misunderstanding, but to me low-end is not the same as old. I tested on Intel IGP 520 and AMD A8 integrated graphics and it runs pretty well. It also works pretty well on old NVidia and AMD hardware. Your hardware is just both low-end AND old.

I don't really understand why you complain that a modern rendering engine does not run on it. The new renderer is made for running and looking great on devices that people actually uses, like I just showed you in the steam survey.

For old low end GPUs and mobile, you will have to wait until the GLES2 port is complete in Godot 3.1. It will run as well as Godot 2.1 runs since it will use the same approach. It will have all the same limitations Unity has which makes it fast, like having to use lightmapping, noisy reflections, shitty reflection probe blending, limited decals, horrible antialiasing, and you will be also limited in the post processes you can use in that hardware or mobile, just like Unity (or any other engine there).

[reduz]

@tagcup In any case, if you want me to explain to you in detail why the current design requires more specs than a renderer like the one in Unity, but has more advantages in exchange (so you understand it's not a "just a matter of optimization" as you state) I will gladly do it.

[ghost]

You're free to call an 2014 i7 or a 2015 Xeon with 18 processor, or a 2017 G6 "old AND low-end hardware", or a then your definitions are way off.

so you understand it's not a "just a matter of optimization" as you state

That what you state, I was just agreeing with what you said earlier:

We will only be able to optimize this in Godot 3.1 when a GLES2 backend written in the same way as 2.1 is done.

actually uses, like I just showed you in the steam survey.

Are we looking at the same thing? Among Intel users (which is around 15-20% of the total), majority of them don't have post-skylake hardware. This means more than 10% of the users.

This number of "old AND low-end" hardware user percentage by your standards is probably going to be close to 100% for mobile.

Ah, come on. Please stop smearing Unity. It just makes the whole situation much less believable. We both know there are hundreds of beautiful big-business 3D titles done in Unity which also work fine on mobile whereas this number is 0 with Godot. Yes, maybe it has a few shortcomings compared to Godot which you love to point out all the time, but Godot has hundreds of those compared to Unity. And it makes sense given the amount of people working on it and the amount of cash they throw at it.

Thanks, but if your answer is going to be "more specs" at the end, no thanks. It'd just be a waste of time for both of us.

[ghost]

I'm sorry if my tone sounded harsh, I'm just truly frustrated about this entire affair with Godot, denial-turned-into-blame and word-weaseling regarding performance.

There's of course nothing wrong with doing a high-end renderer (which Godot 3.0 is). Shifting the semantics on what is low-end or high-end to suit the way you've advertised the new renderer isn't helping the situation.

The reality is, there's a HUGE gap between what this hardware on my phone can achieve (Unity is an evidence of that) and what Godot can deliver; and if it's going to work well (both in terms of quality and speed) on a 2017 phone or a pre-skylake IGP, then no, this has no use for me (and probably many other people).

So however you call those hardware, I personally have no time to spend on an engine which won't work on "low-end" (by your definitions). Some people might just be OK with that, and it's fine, it just doesn't suit my needs. You're making claims about GLES2 renderer which is something that doesn't exists, what it can deliver (again, both in terms of quality and speed) on those "low-end" hardware is to be seen, but it's just a maybe and it's an some unknown point in the future. Whereas Unity for sure works perfectly on my target "low-end" hardware, today. So at the end, I'm calling in quits for practical reasons.

[Calinou]

Remember that the LG G6 features a 2880×1440 display. You probably don't want to render in this resolution, so you will probably want to use a custom downscaled viewport (half-resolution, which would be 1440×720 for your device), then linearly upscale it.

On my Samsung Galaxy S7 edge, the FPS more than doubles when running the Platformer 3D demo in 1280×720 rather than in the device's resolution, which is 2560×1440. This was done by forcing the resolution in the device's developer settings, which decreases the resolution of everything. The quality difference is nearly invisible, as 1280×720 is still pretty decent for games on a 5.5" phone.

[akien-mga]

FWIW, I have (or had, now I'm using the discrete Nvidia GPU, haven't tried Intel since a couple of months) pretty decent performance with Intel HD 4000 on Linux with latest MESA.

I just tried again and I can confirm that the performance is quite bad on 3D scenes. :|
(Also the FPS counter is messed up, but that's another issue already reported).

[reduz]

@tagcup The performance and quality of what you will be achieve with the GLES2 renderer is similar to what you can already with Godot 2.1 The main difference will be that lightmap generation will be more standard and rendering will support PBR (reflection probes), but Godot 2 with lightmaps already runs perfectly well and fullf-fps on 10 year old phone hardware or any PC desktop or laptop you throw at it.

There is no reason to believe this will not be the same in Godot 3.1, as it's a "been there, done that" scenario.

Regarding your point of view for optimization, I never said you can't make pretty games in Unity or anything else. Art quality is always the determinant factor in the end, no matter the engine but the point of making a high-end rendering engine is to bring out the best visual quality with the least amount of effort.

I wrote already a lengthy article explaining the rendering design and the techniques used. For anyone with some understanding on this, the trade offs should be more or less obvious.

To make it simple, it allows having more complex materials (almost full principled BSDF), better probe blending, simpler to set up GI (lightmaps are a hassle), better antialiasing and many other things. It's a also a design that allows us to do this with a small codebase that can be maintained with our limited resources.

The main downside is that it's a renderer that does not care so much about optimizing on non dependent texture operations (which is what newer hardware is designed for), so hardware like yours does effectively suffer due more constrained and less optimized memory access.

If this was the only renderer that would be supported, the obvious solution would be to add hacks to make it faster on some situations, but I don't see the point given a second one will be created for this purpose.

But honestly, put yourself in our shoes, Godot has been out for almost 4 years and all we did back then was support low end hardware and mobile extremely well. New renderer is not even out yet and you complain we ignore that.

If you want to feel offended and ragequit I won't try further to convince you, though if you are interested, it would be more constructive if you help us test the GLES2 renderer for 3.1 and make sure it works as best as possible for you. If you are working on a game, I don't think you will have it published before the next release anyway.

[ghost]

This really isn't a rage-quit. You can call it disillusionment-quit maybe, but it really is about practical reasons. Let me explain.

I'm working on this game with a friend who does modelling and art in our free time (we both have day time jobs totally unrelated to software development), so time is the most limited resource for us. With Godot, I found myself waiting for fixes, features, performance improvements that were essential for us, and using my time to contributing to the engine rather than spending that time on the game itself. And after 1 year, in terms of the features and performance that we need, we're still where we started.

I tested on the hardware that I have, and Unity works really really well, even at high resolutions, and looks beautiful. With Godot, it crawls at even half resolution (like 1024x600) even with everything turned off and the lowest possible setting, looking quite ugly.

Aside from the obvious performance (which is more important than anything else, simply a must, because that's going to be a mobile game), Unity's limited Disney BRDF has enough features for us (clearcoat, anisotropy, rim etc are too exotic for us anyway), lightmaps are good enough because we don't need to move them around, I won't make much use of reflections, but I do need a well working LOD system, a feature-complete (including skeletal animations) gltf or fbx importer that actually works properly, a stable directional light with nice shadows, something like mecanim. Stuff like seamless reflection probes are so low-priority compared to those.

Unity just works today, and has everything we actually need whereas Godot, that just a maybe, we need to wait for an unknown amount of time and even then we don't know what's going to happen.

Example from past: You were saying that the GLES3 renderer will work just fine everwhere telling there won't be a GLES2 renderer. After implementation got to a certain point, you tested and oops, you discovered it won't work on mobile. Who's to say when GLES2 renderer comes out you'll discover it won't work fine, let's say pre-2016 mobile, and pull the "of course it won't work, that hardware is old AND crap, get a new phone" again? Or that you'll need to cut a bunch of features? I simply don't know, because it's all in the future, and past doesn't give much confidence.

So you see that's not an impulsive response. We simply realized that "waiting for Godot" is a greater risk that we initially thought about a year ago, and we don't want to take that risk anymore (since at this point, we're still not much invested to Godot thanks to the unstability and lack-of-features-that-we-need in the master branch), and we'll use Unity for our current project.

If in the future, GLES2 turns out to be so rosy, I'll be back and use it for future projects. So this is why I wish you all the best with the Godot development.

[reduz]

@tagcup Alright. Let's hope you give 3.1 features (which should include new renderer, LOD and character animation system) a try when they are ready, would be nice to hear feedback from you.

[ghost]

Thanks, and thank you for bearing with my negative outlook. But I hope I made enough noise here to bring some attention to the issue toward a solution.
Will certainly do!

[zejji]

Just to add my 2 cents based on extensive use of Godot 3 throughout its development: we _desperately_ need the ability to use old-fashioned baked lightmaps and AO as an alternative to GI probes even for medium- to high-end systems when using the OpenGL ES3 renderer.

By way of illustration, I have a brand-new Dell XPS 15 9560 (i7 quad core, 32gb RAM, Nvidia GTX 1050) and still get around 10fps (at 1920 x 1080) when using GI probes in a game which takes place entirely within a series of small rooms that are separate scenes. This is after trying various optimization steps and playing with different settings. Surely we can't ask that users need something better than a GTX 1050 to get a lighting quality that looks remotely up-to-date?

(SSAO also performs very badly in conjunction with screen-space reflections. The latter (i.e. reflections) are an integral part of my game mechanics, so disabling SSR is not an option, which means there is currently no feasible way to get moderately realistic lighting in my game when using Godot 3. The only option I am left with is to turn off all the new effects other than SSR, which is a shame - there doesn't seem to be much point having lots of effects if you can't use them!)

[volzhs]

@zejji AFAIK, there will be baked lightmap functionality on 3.1
@reduz @akien-mga what about having ROADMAP.md?

[reduz]

@zejji I got a Dell XPS 13 with an i5 / Inel 520 and GIProbe seems to work well in there. I'm sure something must be odd, as it seems t work well for me with much lower end nvidia hardware.

In any case, you are right, I'm researching traditional lightmapping. It should be easy to implement, the difficult part is mostly finding a good uvmapper so geometry gets properly unwrapped on the second UV channel on import. I found a few implementations and will work on it as a priority after 3.0 is out (which we are pushing it to be as soon as possible)

[zejji]

@reduz @volzhs - Thanks, that's really good to hear! I look forward to seeing how the optimization process develops in due course. (I'm happy to be patient since, although our game is quite advanced in the development process, I suspect that release is realistically at least 3-6 months away.) In any case, I just wanted to say thank you for all your hard work on Godot 3 - I think it's great so far and lots of fun to use!

[zejji]

@reduz - I just thought I ought to mention that we've been working on Godot 3 alpha 2 and haven't upgraded to beta 1 yet.

I'll try upgrading tonight and let you know whether performance is still the same. (I'd held off doing this because the move to bullet physics broke my code, but I now know it should be possible to get round this problem by selecting 'Godot physics' in the Project Settings.)

[volzhs]

@zejji it would be great if you can compile and test with the latest master to see if there is some improvement comparing to alpha 2.

[vnen]

@volzhs

what about having ROADMAP.md?

Technically there's a one already, just in another repo: https://github.com/godotengine/roadmap

[zejji]

@volzhs @reduz

As promised, I did a lot of testing with a self-compiled build of the latest master... and it yielded some interesting results. Below are the fps counts I get with different settings. Vsync was enabled in all tests (as I would never realistically switch this off in real-world use - let me know if you need the tests re-running without it):

1920 x 1080, windowed, no GI Probe: ~60 fps
1920 x 1080, windowed, with GI Probe: ~30 fps

1920 x 1080, fullscreen*, no GI Probe: ~30 fps (!)
1920 x 1080, fullscreen*, with GI Probe: ~10 fps (!)

* NB: I have to disable 'Allow Hidpi' for Godot to respect the choice of 1920 x 1080 resolution (otherwise Godot ignores it and uses 3840 x 2160). The camera also looks a little too zoomed in at 1920 x 1080 fullscreen, which suggests something else funny is going on...

3840 x 2160, windowed, no GI Probe: ~30 fps
3840 x 2160, windowed, with GI Probe: ~9 fps

3840 x 2160, fullscreen, no GI Probe: ~30 fps
3840 x 2160, fullscreen, with GI Probe: ~9 fps

I've highlighted the results that I find strange. The level of performance at 1920 x 1080 fullscreen, and the fact that the camera seems zoomed in, almost suggests that Godot is rendering a much larger buffer and only showing the middle portion of it. In any case, the difference in performance from windowed mode (there shouldn't be any) suggests something fishy is going on...

[Calinou]

(as I would never realistically switch this off in real-world use - let me know if you need the tests re-running without it)

I beg to differ, as V-Sync not only slightly decreases FPS, but also (most importantly) greatly increases input lag and stuttering (when FPS is below the monitor refresh rate). Adaptive V-Sync (which isn't built into Godot yet) solves the latter problem, but not the former – "Fast" V-Sync can fix the former, but only on NVIDIA Pascal GPUs and newer.

However, do note that mobile platforms will always enforce V-Sync, and Web browsers will almost always enforce it as well.

The camera also looks a little too zoomed in at 1920 x 1080 fullscreen, which suggests something else funny is going on...

It may still be rendering in 3840×2160 (with part of the viewport being located outside of the display boundaries), even if you are forcing loDPI. This is an issue with Godot's fullscreen code with hiDPI displays on Windows, as this does not happen with any other engines I know of.

[akien-mga]

I've highlighted the results that I find strange. The level of performance at 1920 x 1080 fullscreen, and the fact that the camera seems zoomed in, almost suggests that Godot is rendering a much larger buffer and only showing the middle portion of it. In any case, the difference in performance from windowed mode (there shouldn't be any) suggests something fishy is going on...

That would be worth putting in its own bug report, as it's not directly linked to the topic of Intel GPUs performance, but should be a more global issue if fullscreen mode is broken on HiDPI.

[reduz]

the fact the performance is so much lower when windowed vs full fullscreen, even at the same resolution is strange,

[zejji]

@akien-mga @reduz

Thanks - I've created a new bug report here. Originally I hadn't noticed it was a HiDPI-related issue as I nearly always use 1920 x 1080 fullscreen as my default testing setup.

The non-fullscreen FPS tests show that it would still be very useful to have old-fashioned lightmapping available as an option (even for the OpenGL ES3 renderer) though, as the GI probes seem to have a 50-66% performance impact in all scenarios.

@Calinou

Yes, having V-sync on is more of a personal preference - I can't stand screen-tearing! I'm aware of the performance impact, so would always give the user the ability to disable v-sync as an in-game option. Adaptive v-sync would be great though :)

[akien-mga]

As bad as it is, there's not much that can be done for 3.0 at this stage, so moving to 3.1. The new GLES2 renderer will be one way to fix it, another parallel path will be optimising the GLES3 renderer further.

[abhaskumarsinha]

So, I tried to check the problem by emulation of few old Cards using Software Renderers like OCAPipe, found an interesting data.

Intel Hardware are half of NVIDIA in FPS. Platformer was 1 frame in 2 seconds in Intel and on NVIDIA it's about 1 frame in One Second. But, Unity is Opposite of that.

The Console showed some Problems I've not noted what are those.

[reduz]

I've been testing Sponza scene with hdr+lightmaps+bloom+refprobe+realtime
directional shadows on a Intel HD5000 on OSX.
I get 30fps in 1080, and 50fps on 720, which I believe it's pretty OK for
the way the current renderer works.
SSAO is a performance killer, so it needs an option to reduce it to a
quarter size when processing.

I think this issue can be closed when:

• SSAO at half-size is implemented
• GLES2 rendering backend is implemented

---

Noshyaar's edit: Github hid the last two lines.

[sdfgeoff]

@reduz:
I disagree that this can be closed.
On my i5 laptop I get 40FPS on a scene with three lights and 3 objects (~1500 polygons total, each object has a single aldebo texture). Shadows are disabled, and every setting I can think of has been turned down/off in the project settings. On the platformer demo project I get 12 FPS.

I do not expect to get top-quality graphics on an intel card, but you can still play many many games just fine at lower settings. I would expect that at the very least, you should be able to disable _everything_ that makes it run slowly.

For reference: I have been happily developing games on this system for the past couple years (using other engines), and I've never needed a more powerful GPU yet, and have rarely had performance issues.

[akien-mga]

I disagree that this can be closed.

Notice the "when" and the two conditions:

I think this issue can be closed when:

• SSAO at half-size is implemented
• GLES2 rendering backend is implemented

[reduz]

@sdfgeoff As mentioned before, for very low end devices and simple 3D, the GLES2 backend will be good enough. The GLES3 renderer has a higher base rendering cost that may make it unsuitable for them.

[JosephHalter]

Just to add another reference point, I get about 20 FPS out of the 3D Platformer demo on Godot 3.0.5 with mid 2015 MacBook Pro with AMD Radeon R9 M370X, tried on both OSX and Windows 10.

[malbach]

@JosephHalter did you change something in the 3D Platformer demo project ? Like the resolution ?
Your GPU should be ~300% better than my Intel UHD 630 (CPU: i7-8750H) and when testing the demo I had 60 FPS capped, so I removed the vsync and then it was 110-115 FPS (tested in editor, not exported).
I did this test with Godot-3.0.6-stable_win64, on Win10.

[EDIT]
For reference, I did the same test (same Godot) with the Sponza demo, and :
Fullscreen 1080p : high quality = 8 FPS / low quality = 13 FPS
Windowed 720p : high quality = 14 FPS / low quality = 23 FPS

Also tested Ultra quality and got about 5 FPS in 1080p and 10 FPS in 720p.

[JosephHalter]

@malbach didn't change anything in the demo, it's fresh from import. I didn't even change vsync but if I change it it's no more faster.

However it seems that if I reboot and open Godot the first time I run the game it's pretty fast, but if I stop it and click play again this time I get max 30 fps with the 3D Platformer demo, while the Godot editor itself takes 80% of one CPU core or so and I don't know why. Seems like my issues are possibly linked to https://github.com/godotengine/godot/issues/12366

Also my update change spinner never stops spinning, not sure if it related at all, could possibly be linked to https://github.com/godotengine/godot/issues/11030 - I'm not sure. Enabling low processor mode has no effect.

[JosephHalter]

I haven't tried it with version 3.0.6 on Windows 10 yet.

[reduz]

The GLES3 renderer won't change, and Vulkan will probably not support older Intel GPUs, so I will kick this issue to 3.2, where it will probably be closed.

[DriNeo]

I just tested the 3.1 alpha and I had a good surprise when I launched the "material tester", thanks to the GLES 2 mode. The performance gap between GLES 3 and GLES 2 modes is impressive. Output spams errors and there are still some artifacts, but I noticed 60 fps in the material tester in GLES 2 mode, despite a PBR renderer, well done guys.

[akien-mga]

There's a lot of interesting test data in this issue, but realistically I don't see it being fixable with such a broad scope. This was started as a "wow godot 3.0 performance is bad on IGPs", but many improvements have happened since then with the GLES2 renderer, fixes to GLES3, and upcoming Vulkan in 4.0.

So I'll close this, and if specific points raised here are still relevant and not tracked in other issues, they should likely be reported in new issues.