Very slow shader compilation (Galaxy S3 mini)

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.

Thanks!

Kak

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.

Thanks!

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,

Chris

Hi Chris,

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.

Thanks!

Kak

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,

Chris

Hi Chris,

only one more question, is it know the time or version in which this issue was fixed?

Thanks!

Kak

Hi katcat,

Seems to be fixed in r3p2-01rel3, which is present in SGS3 running 4.3.

Thanks,

Chris

Thanks a lot, I'll try to work from there

Hi Chris,

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!

Kak

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.

Hope this helps,

Chris