Godot: Scenes with 3D nodes do not start on Android with Adreno 3xx and 5xx GPUs

Created on 10 Nov 2017  路  49Comments  路  Source: godotengine/godot

Bugsquad edit:

Adreno GPU drivers have broken OpenGL ES 3.0 support, and there's not much we can do about it without crippling Godot's renderer for correct driver implementations from other GPU vendors.

The fix will come in Godot 3.1 with the new OpenGL ES 2.0 renderer, which should run fine on Adreno GPUs and will be enforced when such GPUs are detected (at least until we get test reports that Adreno eventually fixed their bogus drivers for OpenGL ES 3.0).

In the meantime, a potential workaround is documented in https://github.com/godotengine/godot/issues/12816#issuecomment-355991771


Operating system or device, Godot version, GPU Model and driver (if graphics related):
Google Nexus 5 (Android 6.0.1), Godot Engine v3.0.alpha.build2, Qualcomm Adreno 330 (OpenGL ES 3.0).

Additional info:
Godot Engine build and export templates were downloaded from here.

Issue description:

If scene contains some 3D-related nodes (e.g. MeshInstance with primitive mesh), then application freezes at Godot Engine splash screen.

adb logcat:

11-10 20:26:17.927 775 1392 I ActivityManager: START u0 {act=android.intent.action.MAIN flg=0x10000000 cmp=org.godotengine.nexus53dtest/org.godotengine.godot.Godot} from uid 2000 on display 0
11-10 20:26:17.950 29098 29098 D AndroidRuntime: Shutting down VM
11-10 20:26:17.978 775 4033 I ActivityManager: Start proc 29127:org.godotengine.nexus53dtest/u0a253 for activity org.godotengine.nexus53dtest/org.godotengine.godot.Godot
11-10 20:26:17.986 29127 29127 I art : Late-enabling -Xcheck:jni
11-10 20:26:18.029 775 1204 I ActivityManager: Config changes=480 {1.0 255mcc6mnc en_US ldltr sw360dp w592dp h336dp 480dpi nrml land finger -keyb/v/h -nav/h s.148}
11-10 20:26:18.038 775 874 I InputReader: Reconfiguring input devices. changes=0x00000004
11-10 20:26:18.038 775 874 I InputReader: Device reconfigured: id=4, name='touch_dev', size 1080x1920, orientation 1, mode 1, display id 0
11-10 20:26:18.082 1389 1389 W Binder_6: type=1400 audit(0.0:432303): avc: denied { ioctl } for path="socket:[1511054]" dev="sockfs" ino=1511054 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.082 1389 1389 W Binder_6: type=1400 audit(0.0:432304): avc: denied { ioctl } for path="socket:[1511054]" dev="sockfs" ino=1511054 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.090 29127 29127 D GODOT : * GODOT ACTIVITY CREATED HERE
11-10 20:26:18.129 29127 29127 D GODOT : command_line is null? yes
11-10 20:26:18.122 4046 4046 W Binder_10: type=1400 audit(0.0:432305): avc: denied { ioctl } for path="socket:[1516672]" dev="sockfs" ino=1516672 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.122 4046 4046 W Binder_10: type=1400 audit(0.0:432306): avc: denied { ioctl } for path="socket:[1516672]" dev="sockfs" ino=1516672 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.293 29127 29127 I godot : *INIT EVENT! - 0xb4d96a80
11-10 20:26:18.293 29127 29127 I godot : *
****
HELLO FROM JNI!!!!!!!!
11-10 20:26:18.293 29127 29127 I godot :
*CLASS FOUND!!!
11-10 20:26:18.293 29127 29127 I godot : STEP2, 0x1004fe
11-10 20:26:18.293 29127 29127 I godot : STEP3 -1334633752
11-10 20:26:18.293 29127 29127 I godot : STEP4, 0x10001d
11-10 20:26:18.293 29127 29127 I godot : STEP4.5, 0x100502
11-10 20:26:18.294 29127 29127 I godot : STEP7
11-10 20:26:18.294 29127 29127 I godot : STEP8
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _dir_open ok!!
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _dir_next ok!!
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _dir_close ok!!
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _dir_is_dir ok!!
11-10 20:26:18.294 29127 29127 I godot : starting to attempt get methods
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _init_audio ok!!
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _write_buffer ok!!
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _quit ok!!
11-10 20:26:18.294 29127 29127 I godot :
*GOT METHOD _pause ok!!
11-10 20:26:18.294 29127 29127 I godot : test construction 5
11-10 20:26:18.294 29127 29127 I godot : running from dir /
11-10 20:26:18.309 29127 29158 I godot : SETUP
11-10 20:26:18.309 29127 29158 I godot : CMDLINE LEN 0 - APK EXPANSION 0
11-10 20:26:18.312 1391 1391 W Binder_8: type=1400 audit(0.0:432307): avc: denied { ioctl } for path="socket:[1516313]" dev="sockfs" ino=1516313 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.312 1391 1391 W Binder_8: type=1400 audit(0.0:432308): avc: denied { ioctl } for path="socket:[1516313]" dev="sockfs" ino=1516313 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.312 495 495 W Binder_4: type=1400 audit(0.0:432309): avc: denied { ioctl } for path="socket:[1517582]" dev="sockfs" ino=1517582 ioctlcmd=7704 scontext=u:r:surfaceflinger:s0 tcontext=u:r:surfaceflinger:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.312 495 495 W Binder_4: type=1400 audit(0.0:432310): avc: denied { ioctl } for path="socket:[1517582]" dev="sockfs" ino=1517582 ioctlcmd=7704 scontext=u:r:surfaceflinger:s0 tcontext=u:r:surfaceflinger:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.331 29127 29159 D OpenGLRenderer: Use EGL_SWAP_BEHAVIOR_PRESERVED: true
11-10 20:26:18.322 224 224 W Binder_1: type=1400 audit(0.0:432311): avc: denied { ioctl } for path="socket:[1511059]" dev="sockfs" ino=1511059 ioctlcmd=7704 scontext=u:r:surfaceflinger:s0 tcontext=u:r:surfaceflinger:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.322 224 224 W Binder_1: type=1400 audit(0.0:432312): avc: denied { ioctl } for path="socket:[1511059]" dev="sockfs" ino=1511059 ioctlcmd=7704 scontext=u:r:surfaceflinger:s0 tcontext=u:r:surfaceflinger:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.362 4038 4038 W Binder_D: type=1400 audit(0.0:432313): avc: denied { ioctl } for path="socket:[1516315]" dev="sockfs" ino=1516315 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.362 4038 4038 W Binder_D: type=1400 audit(0.0:432314): avc: denied { ioctl } for path="socket:[1516315]" dev="sockfs" ino=1516315 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.372 29127 29158 I godot : *
SETUP OK
11-10 20:26:18.372 2535 16326 I Icing : Indexing 318F571EA918ABF0F442A78012795AC8B9B9264C from com.google.android.gms
11-10 20:26:18.372 29127 29158 I godot : ANDROID MODULES: Nothing to load, aborting
11-10 20:26:18.419 29127 29159 I Adreno-EGL: : QUALCOMM Build: 10/21/15, 369a2ea, I96aee987eb
11-10 20:26:18.425 29127 29159 I OpenGLRenderer: Initialized EGL, version 1.4
11-10 20:26:18.429 2535 16326 I Icing : Indexing done 318F571EA918ABF0F442A78012795AC8B9B9264C
11-10 20:26:18.452 29127 29127 D GODOT : setVirtualKeyboardHeight: 0
11-10 20:26:18.459 29127 29158 W GodotView: creating OpenGL ES 3.0 context :
11-10 20:26:18.467 29127 29127 I godot : WARNING: not found: display/driver/keep_screen_on
11-10 20:26:18.471 29127 29158 I godot : ^_^_^_^_^ newcontext 0
11-10 20:26:18.471 29127 29158 I godot : ^_^_^_^_^ resize 0, 1920, 1080
11-10 20:26:18.471 29127 29158 I godot : FIRST_STEP
11-10 20:26:18.494 29127 29158 I godot : OpenGL ES 3.0 Renderer: Adreno (TM) 330
11-10 20:26:18.574 29127 29158 I godot : GLES3: max ubo light: 409
11-10 20:26:18.574 29127 29158 I godot : GLES3: max ubo reflections: 455, ubo size: 144
11-10 20:26:18.576 775 793 I ActivityManager: Displayed org.godotengine.nexus53dtest/org.godotengine.godot.Godot: +617ms
11-10 20:26:18.572 1204 1204 W Binder_4: type=1400 audit(0.0:432315): avc: denied { ioctl } for path="socket:[1517591]" dev="sockfs" ino=1517591 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.572 1204 1204 W Binder_4: type=1400 audit(0.0:432316): avc: denied { ioctl } for path="socket:[1517591]" dev="sockfs" ino=1517591 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.572 786 786 W Binder_2: type=1400 audit(0.0:432317): avc: denied { ioctl } for path="socket:[1517590]" dev="sockfs" ino=1517590 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.572 786 786 W Binder_2: type=1400 audit(0.0:432318): avc: denied { ioctl } for path="socket:[1517590]" dev="sockfs" ino=1517590 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=0
11-10 20:26:18.591 29127 29127 D GODOT : setVirtualKeyboardHeight: 0
11-10 20:26:18.603 775 793 I WindowManager: Screen frozen for +597ms due to Window{7e80055 u0 org.godotengine.nexus53dtest/org.godotengine.godot.Godot}
11-10 20:26:18.609 29127 29127 D GODOT : setVirtualKeyboardHeight: 0
11-10 20:26:18.625 29127 29158 I godot : OpenSL Init OK!
11-10 20:26:18.650 29127 29158 W AudioTrack: AUDIO_OUTPUT_FLAG_FAST denied by client; transfer 1, track 44100 Hz, output 48000 Hz
11-10 20:26:18.657 202 808 D audio_hw_primary: out_set_parameters: enter: usecase(1: low-latency-playback) kvpairs: routing=2
11-10 20:26:18.668 202 808 D audio_hw_primary: select_devices: out_snd_device(2: speaker) in_snd_device(0: none)
11-10 20:26:18.668 202 808 D msm8974_platform: platform_send_audio_calibration: sending audio calibration for snd_device(2) acdb_id(15)
11-10 20:26:18.668 202 808 D audio_hw_primary: enable_snd_device: snd_device(2: speaker)
11-10 20:26:18.671 202 808 D audio_hw_primary: enable_audio_route: apply and update mixer path: low-latency-playback
11-10 20:26:18.898 29127 29158 I godot : ARVR: Registered interface: Native mobile
11-10 20:26:19.398 29127 29158 E godot : *
ERROR: Error opening file: res://icon.png
11-10 20:26:19.398 29127 29158 E godot : At: core/io/image_loader.cpp:54:load_image() - Error opening file: res://icon.png
11-10 20:26:20.609 775 793 I art : Starting a blocking GC Explicit
11-10 20:26:20.686 775 793 I art : Explicit concurrent mark sweep GC freed 31273(2MB) AllocSpace objects, 1(20KB) LOS objects, 29% free, 38MB/54MB, paused 969us total 75.884ms
11-10 20:26:22.237 3193 3193 I WearableService: Wearable Services stopping
11-10 20:26:32.275 21643 21722 I Finsky : [8432] com.google.android.finsky.l.c.a(23): Completed 0 account content syncs with 0 successful.
11-10 20:26:32.275 21643 21643 I Finsky : [1] com.google.android.finsky.services.e.a(5): Installation state replication succeeded.
11-10 20:26:39.276 212 325 I ThermalEngine: TM Id 'SKIN_THERMAL_management_1' Sensor 'xo_therm_pu2' - alarm raised 1 at 40.0 degC
11-10 20:26:39.276 212 325 I ThermalEngine: ACTION: CPU - Setting CPU[0] to 1958400
11-10 20:26:39.276 212 325 I ThermalEngine: ACTION: CPU - Setting CPU[1] to 1958400
11-10 20:26:39.276 212 325 I ThermalEngine: ACTION: CPU - Setting CPU[2] to 1958400
11-10 20:26:39.276 212 325 I ThermalEngine: ACTION: CPU - Setting CPU[3] to 1958400
11-10 20:26:39.276 212 325 I ThermalEngine: ACTION: LCD - Setting max LCD brightness to 229

Text file format:
logcat.txt

Possible references:

12117

11693

Steps to reproduce:

  1. Open project with 3D node(s) in the main scene in Godot Engine editor.
  2. Make one-click deploy.

Link to minimal example project:

nexus-5-3d-test.zip

bug confirmed android rendering

Most helpful comment

The bug reads more like "Godot doesn't support some Adreno GPUs", not "GLES3 backend doesn't support <...>". This should be fixed in 3.1 with GLES2 backend, so I think it needs to be tested and closed - otherwise people will think Godot still doesn't support mobile.

All 49 comments

Present the same error on LG G3:

Chipset | Qualcomm MSM8974AC Snapdragon 801
CPU | Quad-core 2.5 GHz Krait 400
GPU | Adreno 330
Android | 5.0

On gpaid, I got this incomplete frame:
image

the ultimate call opengl :
image

in render thread:
image

Logcat with opengl calls:
https://pastebin.com/S6Up0w7H

Maybe a driver problem?

probably something incompatible with Adreno 3xx, will need one to test.

Probably, a friend tested on an LG G2, with adreno 3xx, same problem,
I have no idea how to come up with a fix :/

The screen just freezes, no warnings, no logs, no infos, etc

I have a Xiaomi Redmi 3s Pro with Adreno 505 and have the same error.

Encountered similar behaviour on some Adreno devices - the reason was that linking scene.glsl shader (glLinkProgram call) took enormous amount of time.

After removing shader parts related to USE_FORWARD_LIGHTING and fogs, linking started to take tens of seconds instead of infinity.

Not entirely sure this is the same issue though.

Same here with Adreno 305. Some friends who own devices with Adreno gpus reported the same.
My project is pretty big and we're in middle stages of development, I'm very worried about this.

@endragor can you provide steps (or a branch)? I'm not familiar with Godot renderer backstages.

See https://github.com/endragor/godot/commit/02b12c98043afa6418e0463204e638d6f435ed0a. I haven't checked recently if those removals help though, it could be that something new was added that also causes hanging.

@endragor, does this removal of the shader solves the android crash problem?

@Alexia-AT-Digitecnology It solves freezing at the beginning which is mentioned in the OP. I didn't see mentions of crashes here, so I'm not sure which problem you are referring to.

@endragor , when you run a Godot 3d project into a cellphone with adreno chipset, it crashes. It happens to me and a lot of friends. And mali chipsets too.

@Alexia-AT-Digitecnology then it is likely a different issue - please create a new issue on GitHub and attach a sample project to it.

@endragor, it's issue #11693

There is another issue related: #12192

So this is a duplicate of #11693, which also says there is a freeze. #12192 was a configuration issue. So do you experience a crash or a freeze? If it's a crash, then it is something different from the opened issues.

Thank you, @endragor.
I reproduced this endragor/godot@02b12c9 and now it doesn't stuck on loading screen anymore, but 3D shaders are all black and performance is painful; 30fps with just one Sprite3D (20 with shaded flag on).
EDIT:
I had only built the export template after the scene.glsl modifications, I compiled the editor and everything is black there too; so it's a good thing, i guess. That means the hanging is the only issue here.

UWP also hangs if you add any mesh, I wonder if it's related. ANGLE seems to get into an infinite loop.

For the reference, we decided not to merge #14902 as it's too hacky and likely does not fix all Adreno 3xx issues. If you really need something that starts though, you can apply https://github.com/godotengine/godot/pull/14902.patch on your own branch to build Android templates.

As to a proper fix for this issue, it will boil down to waiting for a GLES2 renderer and somehow enforce GLES2 mode on Adreno 3xx.

Not sure if i got that GPU but my phone also freezes in godot screen and crashes (xiaomi mi a1)

@alex9099 Xiaomi mi a1 uses Adreno 506.
By the words from the developers, Godot should be running fine with this GPU.

@set-killer on my phone it just crashes, maybe android version? i am using the latest version that i compiled, i am not sure if the export template that is downloaded automaticly works or if i need to compile myself

If you compile the editor yourself, you also need to compile the export templates you want to use.

There were several reports of non-working or crashing 3D with Adreno 5xx GPUs too, so edited the issue title to match those.

I wanted to clarify what is the plan to correct this problem?
Since the problem is very serious! Processors Qualcomm installed in half of the devices for android. In essence, this problem makes the android platform not suitable for distributing games on the Godot engine. Earlier decisions of this problem seem to me not correct.
1 Wait for the release of version 3.1 for an extremely long time (probably about a year).
2 To solve the problem by replacing OpenGLES 3.0 with OpenGLES 2.0 for processors with a Qualcomm is a very strange way.
What do I suggest:
1 In all likelihood, several GPU developers will have to be supported.
2 Perhaps it is worth discussing this with the developers of Qualcomm. Maybe they will propose something.
Please kindly discuss the situation.

based on this announcement. https://godotengine.org/article/gles2-and-gdnative-progress-report-2

PLANNED FEBRUARY 2018

  • meet with other developers at FOSDEM and GodotCon
  • implement more shader features
  • NativeScript 1.1 extension
  • Rust binding guidance
  • load meshes
  • render meshes
  • implement basic PBR
  • directional lights

gles 2 renderer seems to be done in Feb.
maybe it might be delayed a little bit but I guess it will be done at least in Mar.
The official release date for 3.1 will be much later, but you can get gles 2 renderer before that.

  1. GLES 3 is simply less perfomant and less supported on all mobile vendors than GLES 2, so GLES 2 as a default on mobile platforms does make sense. There is also still a significant market of devices that do not support GLES 3 at all.

  2. 3.1 will be out sooner than a year from now, hopefully.

  3. We develop a mobile game and with patches #14902 #15774 Godot works fine on Adreno GPUs. But without them, yeah, either don't develop a mobile game with Godot 3.0 or be ready to apply your own workarounds in the engine code.

Well, I should correct myself: you can develop your mobile game with Godot 3.0, as almost certainly GLES2 support will be implemented sooner than you finish your game.

@endragor

Well, I should correct myself: you can develop your mobile game with Godot 3.0, as almost certainly GLES2 support will be implemented sooner than you finish your game.

Why was it necessary to do GLES3 and spend a lot of time if all the same all are offered to use GLES2? We have a bug but we say: we will not fix this bug. and so come down! use another engine or wait for GLES2.
I do not know what to say to this :(

@volzhs

implement more shader features
implement basic PBR
directional lights

And this all will work for GLES2 or not? If not, then why should we spend it all the time? If it works then is the sense from all these new things?

@endragor

GLES 3 is simply less perfomant and less supported on all mobile vendors than GLES 2, so GLES 2 as a default on mobile platforms does make sense. There is also still a significant market of devices that do not support GLES 3 at all.

I wanted to clarify where did you get the statistics that GLES3 is not so common that it would be time to eliminate problems with it? According to Wikipedia, many GPU manufacturers have long supported the GLES3. You can easily verify this:
https://en.wikipedia.org/wiki/Mali_(GPU)
https://en.wikipedia.org/wiki/Adreno
https://en.wikipedia.org/wiki/PowerVR

I wanted to clarify where did you get the statistics that GLES3 is not so common that it would be time to eliminate problems with it?

https://developer.android.com/about/dashboards/index.html#OpenGL

https://en.wikipedia.org/wiki/Adreno

And yet, here we are, with such a bad OpenGL ES 3.0 support that the engine crashes only on Adreno.

@akien-mga
63.6% of devices support GLES3. More than a half. Especially it is worth to finish the business started and not stop at the finish. Yes, Qualcomm has reworked this task, but other engines are coping with this problem. I'm sure that the Godot will do it.

Those problems in Godot come specifically from bad implementations of GLES3 by GPUs that are still in use. You can also search for benchmarks of other engines that can target both GLES2 and GLES3 (UE4, Unity) - same scene on the same device has significantly worse performance when rendered with GLES3. Or you can build your own benchmark, if you are doubtful.

I'm not sure how you draw conclusions from Wikipedia articles - there are no stats as to how many devices are actually in use. Unity had hardware stats page that could be used to determine which hardware mobile gamers actually use right now. It's down now for some reason, but the archived version can be accessed here: https://web.archive.org/web/20170729230854/http://hwstats.unity3d.com:80/mobile/gpu.html. So according to it about 35% of devices support GLES3. Even if it was 63.6%, as you claim, releasing a GLES3 game would mean discarding 36.4% of the market, which does fall into my measure of _significant_.

@endragor
From Wikipedia, I received statistics according to the year of release of the GPU and the version of GLS that it supports. The last GPU supporting only GLES2 ends around 2010. Even from the statistics that you instilled (sort the operating system android and see the last paragraph), it is clear that the largest segment with GLES2 is:

ARM ES2.0 Utgard: 26.5%

All the other items where GLE2 is mentioned occupy a small percentage. And if you put them all together, you will end up with about 36.4% of the market with GLES2. What does the link from @akien-mga:
https://developer.android.com/about/dashboards/index.html#OpenGL

I honestly do not understand why, after the team has done such a huge piece of work to support GLES3, suddenly you all start saying that GLES3 is not a thoroughfare for drawing graphics and in the foreseeable future it will be supplemented with a targeted GLES2 renderer!
At me (and not only at me) at once there are questions:
1 Why Godot 3.0 came out with the support of GLES3 and only GLES3 if a year ago it was clear that GLES3 is not promising at the moment?
2 Why, with the support of GLES3 and leaving Godot so much with GLES3, improving the support of facilities becomes not a priority?
Someone, please answer me these 2 questions!

PS
Problems with GLES3 are also on the Radion cards, and they are also not someone who does not want to notice. Everyone pretends as if they are not.

Yeah perhaps those stats are more accurate and there are 36.4% devices not supporting GLES 3, but, as I said, that's still significant in my opinion. Plus those who claim they support GLES3 may support it partially or with many bugs in driver implementation.

GLES3 was implemented mainly as a target for higher end devices and with advanced features in mind. There are things that you can't do with GLES2 or can only do them with significant sacrifices, while they can be implemented easily in GLES3. Some of those were listed by @reduz here: https://github.com/godotengine/godot/issues/14869#issuecomment-353516796 .

Now, I myself am still not convinced whether GLES3 is really a viable platform for complex games as there is evidence that its performance is poor in some cases, and I'm yet to see a game/demo with a complex scene and decent performance.

I can't answer the question (1) as it was @reduz's decision. Even if the answer is "it was fun for him to explore modern rendering techniques that cannot be implemented with GLES2", that works for me. It's work he was doing for free at the time, and as a result we are getting a FREE engine with astonishing capabilities and ease of use. And you just have to wait for a couple of months to get a working GLES2 renderer.

The answer to (2) is that it's not a priority to improve GLES3 on mobile as GLES2 will be the standard on that platform, so there is no point in adding mobile-specific hacks that will affect other platforms. For other platforms fixing GLES3 renderer is a priority, as far as I can tell. If you are aware of Radeon-specific issues, do report them, and there are some in the backlog scheduled for 3.1.

@endragor

I can't answer the question (1) as it was @reduz's decision. Even if the answer is "it was fun for him to explore modern rendering techniques that cannot be implemented with GLES2", that works for me. It's work he was doing for free at the time, and as a result we are getting a FREE engine with astonishing capabilities and ease of use. And you just have to wait for a couple of months to get a working GLES2 renderer.

So be it. However, based on experience, I can say that a couple of months will not be enough to release Godot 3.1. When I designed Godot 3.0, I gave the most pescemal predictions from all on the forum. And they did not come true, it took more time than I expected. There is a suspicion that the same thing will happen this time. And that would make a correction to the already existing GLES3 will require less effort. And in a month you can release Godot 3.0.1
At the moment there was not a very good situation. The quality of stable version 3.0 leaves much to be desired. And if Godot wants to compete with Unity and Unrial, then the quality of the product will have to be kept at a decent level. And the development of new features is certainly great, but fixing bugs should be in the first place.

PS.
The lack of shadow on Radeon R7. No buffers are created in class "RestorizerSceneGLES3:initialize" line 4882. I raised this topic on Facebook. But there everything was dead.

CPU AMD A10 PRO-7800B R7 Compute Cores 4C+8G

image

sure, there are part phone only support gles2, not gles3. but they are old, the ram entirely small. other word, the one who uses the old phone, will not play 3D game. even can't use social app. like wechat, qq. not all the market is the qualified market. maybe it's better to do some trick to make godot-gles3 work well on adreno hardware. better including new feather ,sth like the one--tessellation.

@aron3097 You say it right, but everybody doesn't care. :)

Just for the logs, i have the same issue on Adreno 304 on a Lenovo TV-X103F (10" Lenovo Essential tablet with Qualcomm 1.3 quadcore) https://hastebin.com/calevamoqa.vbs

Is it possible to use a small whitelist for GPU's to fall back to GLES2?
Would be a good workaround for now.

I found one more, HTC Desire 530, Adreno 304

Google Pixel 2 Adreno 540

07-24 22:14:42.577 11996-11996/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'google/walleye/walleye:8.1.0/OPM4.171019.021.Q1/4820346:user/release-keys' Revision: 'MP1' ABI: 'arm64' pid: 11963, tid: 11981, name: GLThread 44831 >>> org.godotengine.test <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1820 x0 0000000000000000 x1 00000070a375d280 x2 0000000000000001 x3 000000708fd4a0c0 x4 000000708fb86400 x5 00000070a375d280 x6 0000000000000005 x7 00000070965e4758 x8 000000708deb2600 x9 00000000000fffef x10 00000070a365b1a8 x11 000000000000ffff x12 0000007091753180 x13 0000000000000000 x14 80216313580b7e9c x15 0000007091e72010 x16 0000000000000004 x17 00000070a365e600 x18 0000007091e72010 x19 00000070a365e600 x20 0000000000000001 x21 00000070a375d280 x22 0000000000000000 x23 000000709174cd00 x24 000000708def4e00 x25 00000070969661a8 x26 000000000000ffa0 x27 00000070a3748ec0 x28 0000000000000000 x29 0000007096966030 x30 00000070961c4950 sp 0000007096965fd0 pc 00000070961d70a8 pstate 0000000080000000 07-24 22:14:42.580 11996-11996/? A/DEBUG: backtrace: #00 pc 00000000001ef0a8 /vendor/lib64/egl/libGLESv2_adreno.so (EsxGfxMem::UpdateTimestamp(EsxContext const*, EsxAccessType, EsxBucketIdReference*)+36) #01 pc 00000000001dc94c /vendor/lib64/egl/libGLESv2_adreno.so (EsxCmdMgr::GfxMemReferenced(EsxGfxMem*, EsxAccessType)+52)

FWIW Issue isn't reproducible on Google Nexus 5X on the same Android Build (with the same project & export settings) which has an Adreno 418

Was reading some other troubleshooting references related to this and I noted that in many of the cases the Device Manufacturer's ended up fixing this through Webview updates before Android 7. Since Webview is tied to Chrome version now, I thought I'd try updating the Pixel 2 to Android P beta and the issue is gone.

Kicking to 3.2, where it will probably be closed due GLES3 renderer being removed.

The bug reads more like "Godot doesn't support some Adreno GPUs", not "GLES3 backend doesn't support <...>". This should be fixed in 3.1 with GLES2 backend, so I think it needs to be tested and closed - otherwise people will think Godot still doesn't support mobile.

This issue should now be fixed when using the GLES2 renderer in 3.1 (currently beta 2).
Can anyone confirm that they can run 3D projects on devices with Adreno 3xx/5xx GPUs when configured to use GLES2?

For GLES3, this sadly can't/won't be fixed.

Confirm. The lighting doesn't work but at least it doesn't crash.

Thanks, closing as "fixed" (as best as we can, i.e. by providing a different renderer).

Specific bugs with the GLES2 renderer on such hardware should be reported in new issues, if not done already.

Was this page helpful?
0 / 5 - 0 ratings