Added option to enable high precision float in GLES2 #33646

NeoSpark314 · 2019-11-15T19:57:11Z

An additional project setting under rendering/shading with the name
gles2_high_float_precision.mobile is introduced that enables #define USE_HIGHP_PRECISION
in GLES2 shader on Android when it is supported by the shader compiler.
This fixes #33633 and #32813 and also GodotVR/godot_oculus_mobile#60
and GodotVR/godot_oculus_mobile#68 on devices that support the highp (high precision) modifier.

@clayjohn suggested on discord to introduce a project setting to solve this problem.

Two open questions from my side are

Is it possible to show project settings only if the GLES2 backend is selected? If it is possible would this be desired for this option?
At the moment it is only active for Android. I don't know if this is needed for iOS or if it would work there.

Calinou · 2019-11-15T20:46:35Z

Is it possible to show project settings only if the GLES2 backend is selected? If it is possible would this be desired for this option?

We recommend always defining the option and prefixing its name with gles2, so that it's always present in the generated documentation:

godot/main/main.cpp

Lines 962 to 963 in 98caeb6

    
           // Assigning here even though it's GLES2-specific, to be sure that it appears in docs 
        
           GLOBAL_DEF("rendering/quality/2d/gles2_use_nvidia_rect_flicker_workaround", false);

lawnjelly · 2019-11-15T21:48:09Z

I agree with making this optional, however assuming it is turned on, If we consider 3 possibilities:

Hardware that supports highp in fragment shaders at full speed
Hardware that supports highp in fragment shaders at low speed
Hardware that doesn't support highp (reverts to mediump)

This PR will help in situation (1) however it can potentially make situation (2) worse, and leaves situation (3) unfixed. As is this would be a case to authors of 'beware, use at your own risk', but it would be nice to have some kind of scalable solution, to what is admittedly a difficult problem.

It would be nice to be able to detect situations (2) and (3), and apply a different shader (or a different path within the shader).

Could it be possible to detect situation (3) outside the shader itself? Perhaps by attempting to compile a test fragment shader containing highp, or using the define itself to cause compilation failure and testing for this compilation failure (assuming OpenGL doesn't just crash!)? This could potentially be used to swap to a different shader.

For situation (2) it might be possible to have an in game settings to swap between 2 alternative shaders?

A real life example shader is a fancy water shader - you might use a highp fragment shader on hardware that supports it well, but fallback to a simpler shader on hardware that doesn't, so those people can still play the game.

In addition there is the performance question of whether highp should be used throughout a fragment shader (I don't know whether this PR applies it throughout or just to varyings / variables that have been marked as highp in the godot shader source).

The problem of scalable shaders is also generally applicable, to enable users to scale their game experience according to their hardware, I don't know if we have any in built solution for this as yet but it may be worth thinking about within this framework. Having the option of 2 (or more) tiers of shaders to choose from would make the games far more scalable, if this isn't already available, and could be used to address this problem without making the games unplayable for a large number of players.

NeoSpark314 · 2019-11-16T07:18:19Z

@lawnjelly Detecting the support can be done outside via glGetShaderPrecisionFormat(GL_FRAGMENT_SHADER, GL_HIGH_FLOAT, range, &precision);
If highp is unsupported this will return [0,0] for range and 0 for precision.

Regarding the question of where the change introduces highp computation in the fragment shader: as far as I understand it this will apply to all variables/uniforms/varyings that have no precision qualifier applied (and as you said: this should only be used on high-end devices).

Regarding a scalable shader pipeline: this sounds like a monumental task with a lot of trade-offs depending on how you define the capabilities of the low-end hardware vs. mid-range and high-end. Especially since a user would then have to be very aware of how the system behaves on different hardware in a very detailed way to author the content properly and not rely on sth. that might disappear for some players of the game (but arguably this is already the case at the moment).

There are already some options in the existing shader that go into this direction (phong vs. ggx, lit vs. unlit) so maybe providing some query functions for the hardware capabilities to GDScript would allow (advanced) users to build system to manually select the right shader; also supporting the opengl precision keywords in the godot shader language could help there if someone wants to go deep into performance optimization.

NeoSpark314 · 2019-11-16T14:28:21Z

I updated the PR with GLOBAL_DEF("rendering/quality/shading/gles2_high_float_precision.mobile", false); in the main.cpp as @Calinou suggested.

clayjohn · 2020-02-07T17:17:54Z

doc/classes/ProjectSettings.xml

@@ -821,6 +821,9 @@
 		</member>
 		<member name="rendering/quality/shading/force_lambert_over_burley.mobile" type="bool" setter="" getter="" default="true">
 		</member>
+		<member name="rendering/quality/shading/gles2_high_float_precision.mobile" type="bool" setter="" getter="" default="false">
+			If [code]true[/code] and available on the target device high floating point precision for all shader computations in GLES2 is enabled.


Change to ->
"If [code]true[/code] and available on the target device, enables high floating point precision for all shader computations in GLES2.
[b]Warning:[/b] High floating point precision can be extremely slow on older devices and is often not available at all. Use with caution."

clayjohn · 2020-02-07T17:18:56Z

main/main.cpp

@@ -961,6 +961,7 @@ Error Main::setup(const char *execpath, int argc, char *argv[], bool p_second_ph

 	// Assigning here even though it's GLES2-specific, to be sure that it appears in docs
 	GLOBAL_DEF("rendering/quality/2d/gles2_use_nvidia_rect_flicker_workaround", false);
+	GLOBAL_DEF("rendering/quality/shading/gles2_high_float_precision.mobile", false);


This should only be in VisualServer.cpp

Indeed, you can add it after:

servers/visual_server.cpp 2446: GLOBAL_DEF("rendering/gles2/compatibility/disable_half_float", false);

It could be renamed to "rendering/gles2/compatibility/enable_high_float" I guess to match the other gles2/compatibility setting?

Actually this one should be removed now that it has been put in VisualServer. It should only be defined once.

clayjohn · 2020-02-07T17:19:19Z

servers/visual_server.cpp

@@ -2401,6 +2401,7 @@ VisualServer::VisualServer() {
 	GLOBAL_DEF("rendering/quality/shading/force_lambert_over_burley.mobile", true);
 	GLOBAL_DEF("rendering/quality/shading/force_blinn_over_ggx", false);
 	GLOBAL_DEF("rendering/quality/shading/force_blinn_over_ggx.mobile", true);
+	GLOBAL_DEF("rendering/quality/shading/gles2_high_float_precision.mobile", false);


Should have both the normal and the .mobile variant here.

It's a bit of a weird situation though as the non-.mobile variant (or .Android if we go this route) wouldn't do anything currently.

m4gr3d · 2020-05-25T17:22:00Z

@clayjohn @NeoSpark314 Any updates on this PR?

clayjohn · 2020-05-25T17:23:30Z

@m4gr3d I'm good with it. It just needs reduz's approval to get merged. Would be a good candidate for a PR review meeting.

aaronfranke · 2020-07-01T06:00:21Z

@NeoSpark314 When you get a chance, this PR needs to be rebased on the latest master branch.

m4gr3d · 2020-07-01T06:02:21Z

@aaronfranke @NeoSpark314 Actually I think this PR should be rebased against the 3.2 branch since gles2 is removed from the master branch.

lawnjelly · 2020-07-04T08:03:57Z

Also note that since the PR was originally made there is now a project setting group rendering/gles2/ which might be a better place for the setting (although it would be fine to leave it till it gets discussed in a PR meeting).

akien-mga · 2020-07-20T08:23:24Z

@NeoSpark314 Could you rebase this on 3.2? You can change the base branch for the PR by editing the title (yes, very obvious :)) and then force push a version rebased on 3.2 to update the PR.

NeoSpark314 · 2020-07-20T20:44:02Z

@akien-mga done; rebased this PR on top of 3.2 and changed the target branch to 3.2

akien-mga · 2020-07-21T12:03:42Z

Here's an example of a user that needed this feature for an Oculus Quest project too: https://twitter.com/acegiak/status/1285535845806510080 (she compiled Godot with this PR to solve it).

@reduz is OK with the changes 👍

There are some outstanding nitpicks from @clayjohn though which would be good to address.

Should there also be some additional documentation about the caveats mentioned by @lawnjelly?

akien-mga · 2020-07-21T12:09:16Z

drivers/gles2/shader_gles2.cpp

@@ -180,6 +181,14 @@ ShaderGLES2::Version *ShaderGLES2::get_current_version() {
 	strings.push_back("#define USE_HIGHP_PRECISION\n");
 #endif

+#ifdef ANDROID_ENABLED


Should it really be Android-specific? If so, instead of exposing it as a .mobile override, it could be an .Android override (see platform/android/export/export.cpp::get_platform_features).

I don't have experience with iOS and don't know if the shader compiler would support it. I made it android specific now by moving it to .Android

The #ifdef can be removed.

NeoSpark314 · 2020-07-29T08:02:19Z

@akien-mga I updated the documentation as suggested by @clayjohn, moved the setting to rendering/gles2/compatibility/enable_high_float.Android in VisualServer.cpp and removed it from main.cpp. Let me know if there is something missing or need to be changed.

clayjohn

Changes look good to me.

Just double check with @akien that the #ifdef ANDROID_ENABLED is still needed now that you are using .Android

An additional project setting under rendering/gles2/compatibility with the name enable_high_float.Android is introduced that enables #define USE_HIGHP_PRECISION in GLES2 shader on Android when it is supported by the shader compiler. This fixes godotengine#33633 and godotengine#32813 and also GodotVR/godot_oculus_mobile#60 and GodotVR/godot_oculus_mobile#68 on devices that support the highp (high precision) modifier.

NeoSpark314 · 2020-07-30T03:47:02Z

@akien-mga the #ifdef is removed now

akien-mga · 2020-07-30T05:52:45Z

Thanks!

NeoSpark314 requested review from reduz and a team as code owners November 15, 2019 19:57

bruvzg added enhancement platform:android topic:rendering labels Nov 15, 2019

Chaosus added this to the 4.0 milestone Nov 16, 2019

NeoSpark314 force-pushed the gles2_highp branch from 3f24a67 to b8cdcea Compare November 16, 2019 14:26

clayjohn added the cherrypick:3.x Considered for cherry-picking into a future 3.x release label Feb 5, 2020

clayjohn reviewed Feb 7, 2020

View reviewed changes

clayjohn mentioned this pull request May 1, 2020

SchlickGGX subtractive on Android with GLES2 #38374

Closed

clayjohn mentioned this pull request Jul 3, 2020

Textures not rendering properly or on Android with GLES2 and ETC1 VRAM compression #39915

Closed

aaronfranke added the for pr meeting label Jul 4, 2020

NeoSpark314 changed the base branch from master to 3.2 July 20, 2020 17:55

NeoSpark314 force-pushed the gles2_highp branch from b8cdcea to 3b19896 Compare July 20, 2020 18:10

akien-mga reviewed Jul 21, 2020

View reviewed changes

NeoSpark314 force-pushed the gles2_highp branch from 3b19896 to 381d9e5 Compare July 29, 2020 07:58

clayjohn approved these changes Jul 29, 2020

View reviewed changes

NeoSpark314 force-pushed the gles2_highp branch from 381d9e5 to efe6b50 Compare July 30, 2020 03:44

akien-mga approved these changes Jul 30, 2020

View reviewed changes

akien-mga merged commit 19802f7 into godotengine:3.2 Jul 30, 2020

This was referenced Jul 30, 2020

Offsetting UV in the fragment shader is stretching textures on Android GLES2 #32813

Closed

GLES2 shading issue #33633

Closed

akien-mga removed the cherrypick:3.x Considered for cherry-picking into a future 3.x release label Jul 31, 2020

akien-mga modified the milestones: 4.0, 3.2 Jul 31, 2020

clayjohn mentioned this pull request Aug 7, 2020

GLES2 [visual] shader shows pixelated texture on Android #41107

Closed

Firepal mentioned this pull request Oct 10, 2020

Quality of visual shaders deteriorates when using Time input GodotVR/godot_oculus_mobile#60

Closed

Calinou mentioned this pull request Nov 13, 2020

UV offsetting in mobile makes that texture hangs and blocky after few minutes #43505

Closed

Calinou removed the for pr meeting label Nov 21, 2021

timothyqiu mentioned this pull request Mar 29, 2022

Strip feature tag manually when extracting property paths #59667

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added option to enable high precision float in GLES2 #33646

Added option to enable high precision float in GLES2 #33646

NeoSpark314 commented Nov 15, 2019

Calinou commented Nov 15, 2019 •

edited

Loading

lawnjelly commented Nov 15, 2019

NeoSpark314 commented Nov 16, 2019

NeoSpark314 commented Nov 16, 2019

clayjohn Feb 7, 2020

clayjohn Feb 7, 2020

akien-mga Jul 21, 2020

akien-mga Jul 21, 2020

clayjohn Feb 7, 2020

akien-mga Jul 21, 2020

m4gr3d commented May 25, 2020

clayjohn commented May 25, 2020

aaronfranke commented Jul 1, 2020

m4gr3d commented Jul 1, 2020

lawnjelly commented Jul 4, 2020 •

edited

Loading

akien-mga commented Jul 20, 2020

NeoSpark314 commented Jul 20, 2020

akien-mga commented Jul 21, 2020

akien-mga Jul 21, 2020 •

edited

Loading

NeoSpark314 Jul 29, 2020

akien-mga Jul 29, 2020

NeoSpark314 commented Jul 29, 2020

clayjohn left a comment

NeoSpark314 commented Jul 30, 2020

akien-mga commented Jul 30, 2020

Added option to enable high precision float in GLES2 #33646

Added option to enable high precision float in GLES2 #33646

Conversation

NeoSpark314 commented Nov 15, 2019

Calinou commented Nov 15, 2019 • edited Loading

lawnjelly commented Nov 15, 2019

NeoSpark314 commented Nov 16, 2019

NeoSpark314 commented Nov 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m4gr3d commented May 25, 2020

clayjohn commented May 25, 2020

aaronfranke commented Jul 1, 2020

m4gr3d commented Jul 1, 2020

lawnjelly commented Jul 4, 2020 • edited Loading

akien-mga commented Jul 20, 2020

NeoSpark314 commented Jul 20, 2020

akien-mga commented Jul 21, 2020

akien-mga Jul 21, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NeoSpark314 commented Jul 29, 2020

clayjohn left a comment

Choose a reason for hiding this comment

NeoSpark314 commented Jul 30, 2020

akien-mga commented Jul 30, 2020

Calinou commented Nov 15, 2019 •

edited

Loading

lawnjelly commented Jul 4, 2020 •

edited

Loading

akien-mga Jul 21, 2020 •

edited

Loading