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+
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?
Thanks,
Chris
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.
Kak
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.