Hi!
I have a game in Google Play and I'm having problems with (at least) one of the devices, the Galaxy S3 mini with a Mali-400MP.
There's a shader which takes 20 to 30 seconds to be compiled, leading to users thinking that the device just crashed. The shader is this
#ifdef GL_ES precision highp float; precision mediump int; #endif uniform - Pastebin.com (nothing specially complex, I think)
and the issue with more information is here:
Weird freeze compiling shader on Galaxy S3 Mini · Issue #2496 · mono/MonoGame · GitHub
Any ideas?
Thanks!
p.s. Can I use Mali graphics debugger with 4.1.2? Instructions to install only refer to 4.2+
Hi Katcat,
MGD should work with that version, give it a try and let us know if you have any issues, we tend to say 4.2+ because that's what we test on the most.
Thanks for the report, not the first we've had recently so good to get another reproducer . It's not clear from the github issue if you're recompiling this each time you draw with it?
Can you let me know the output of the command adb pull /system/lib/libMali.so && strings libMali.so | grep VARIANT && md5sum libMali.so ? This will let me know the driver version on the device and help me solve this. Also can I ask for the build ID of Android on your phone? For example I'm testing with I8190XXANC2.
Thanks,
Chris
Hi Chris!
good, I'll try to make the MGD work when I have some time.
I'm positive the shader is compiled only the first time it's used, and not recompiled unless needed (context lost, ...).
The result of the operation you asked is this:
mali: BUILD=RELEASE ARCH=arch_011_udd PLATFORM=ux500 TRACE=0 THREAD= GEOM=mali_gp_geometry_common CORES=MALI400 USING_MALI400=1 TARGET_CORE_REVISION=0x0100 TOPLEVEL_REPO_URL=Linux-r3p1-01rel0 REVISION=Linux-r3p1-01rel0 CHANGED_REVISION=Linux-r3p1-01rel0 REPO_URL=Linux-r3p1-01rel0 BUILD_DATE=Wed Nov 28 17:21:54 CET 2012 CHANGE_DATE=Linux-r3p1-01rel0 TARGET_TOOLCHAIN=arm-linux-gcc-vfp HOST_TOOLCHAIN=gcc TARGET_TOOLCHAIN_VERSION= HOST_TOOLCHAIN_VERSION=gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) TARGET_SYSTEM=gcc-arm-vfp-linux HOST_SYSTEM=gcc-x86_64-linux CPPFLAGS= CUSTOMER=internal VARIANT=mali400-r1p0-smp-gles11-gles20-ump-hwmem-linux-android-rgb_is_xrgb-jellybean-no_monolithic HOSTLIB=direct INSTRUMENTED=FALSE USING_MRI=FALSE MALI_TEST_API= UDD_OS=linux
aceea1b5274276ac2f85311c84e4a43e libMali.so
I had to pull the file from windows, and then move the file to a friend's remote linux, so I don't know if I missed something in the process. If there's something wrong I can send you the libMali.so file directly.
The phone's build number says JZO54K.I8190XXANA2
Kak
Thanks, that's the same as mine so I will reproduce it at my end. The case looks quite similar to glCompileShader taking a long time and the issue seems prevalent with HSSL -> GLSL converted shaders which it looks like this is?
Hi Chris,
Yes, I'm almost sure the shader is indeed converted to GLSL, as I'm using MonoGame and the few shaders I've written in, they were in HLSL and "magically" worked on android . Unfortunately I have no idea of GLSL and almost no idea of HLSL (the shaders are the built in basic shaders on MonoGame)
I'll try to investigate how the HLSL->GLSL conversion is being done. If what's causing the problem in the converted shader is discovered, maybe the converter could be adapted to avoid that problem.
Hi Kak,
I'd recommend compiling and saving the resultant program/shader binaries, so your application can load them from disk and only recompile if they're missing (first run) or fail for any reason (usually after a driver update). At least then it's not a hit on every run.
The ROM I have is from this month, but the driver included is r3p0-01rel0, which implies it is 21 months old, but they might be taking patch updates rather than releases. I don't have an S3 Mini to hand to play with, but this issue is almost certainly the same as in the other thread, and is fixed in more recent versions of the driver, so for this particular version the only workaround to long compilation times is to reduce shader length.
Hope this helps,
thanks for your answer, I don't know if I'll be able to implement any of the solutions thought...
One extra question, is there any way to detect beforehand if the shader will have this problem? (detecting driver version, in example). I prefer using less complex shaders than making the user wait 30 seconds and expose to get a bad rating, and I wouldn't like to cripple all Mali devices just for a 21 months old bug.
Depending on driver version you may be able to see the driver version in GL_RENDERER or GL_VENDOR strings, or by examining the libMali binary, which may be doable programatically.
Hth,
only one more question, is it know the time or version in which this issue was fixed?
Hi katcat,
Seems to be fixed in r3p2-01rel3, which is present in SGS3 running 4.3.
Thanks a lot, I'll try to work from there
What method do you recommend to detect if the versions is prior or later than r3p2-01rel3? Do I analize the revision string (what is the format?) or can I use the BUILD_DATE string and assume previous dates are bad and later dates are good? (what is the date for r3p2-01rel3 then?)
thanks again
Hi Kakcat,
I just checked on my SGS2 (CM10.1, 4.2.2, r3p1-01rel1, built July 2013) and the problem is present there, but unfortunately VENDOR == "ARM", RENDERER == "Mali-400 MP" and VERSION == "OpenGL ES 2.0" so that's not useful for checking version. I guess your only option is to look into programatically searching for the REVISION string in libMali.so. If you can do that, then it matches the format REVISION=Linux-r[0-9]p[0-9]-[0-9]{2}rel[0-9]. I've also passed on that it would be useful for the driver version to be queryable.