Hello Mali dev forums,
We recently had a bug pop up in our user reviews regarding mangled graphics on the Galaxy Note 10.1 2014 edition which runs the Mali-T628 GPU and decided to investigate.
After much debugging and poking around, we tracked it down to this one simple fragment shader:
uniform lowp sampler2D sampler;
varying lowp vec4 blendColor;
varying mediump vec2 texCoord;
void main()
{
lowp vec4 texColor = texture2D(sampler, texCoord);
gl_FragColor = 2.0 * blendColor * texColor;
}
Which when used, would cause the output in the BAD image attached. We found that reducing the precision of texCoord from mediump to lowp, the problem went away as in the GOOD image attached.
This particular application shipped around the time the Nexus 10 came to market and is known to have worked fine on the T604 GPU. I do suspect that the fragment shader is not alone in causing this issue since the linkage with the vertex shader could also have effects, however that side of things is relatively simple (I've attached a sample vertex shader).
One thing that makes me hesitate to point at the shader compiler as a culprit is the following odd behaviour. The BAD scene actually renders correctly for 1 frame before getting into a state where the UVs are mangled.
Though we do have a workaround to the issue, I still wanted to bring this up as using lowp UVs isn't typical but only happens to work well with our texture set. Also worry that this bug could spread in various driver branches. Any possibilities that this would be Samsung specific, or do they use ARM reference drivers.
Many thanks,
Stephane
Hello Stephane,
Could you please paste the vertex shader that is used with this fragment shader?
That would help us take a look at what the driver produces for this code.
Thanks
Johan
Hi Johan,
A vertex shader, model_rigid.vsh was attached to the original message. It seems the new forum may have zipped the attachment.
Thanks!
Thanks for the report,
You have found the right workaround, preferring lowp and highp over mediump, and using the same precision in the vertex and fragment shader.
Regards
Thanks for confirming the workaround Johan. You have sufficient information on your end to resolve the issue? mediump is generally our preferred precision level for UVs especially when tiling, which thankfully wasn't the case with this application. I'd be curious as to the root cause of the issue as we have another application with much more complex shaders that doesn't exhibit this artifact but is using medium UVs in a similar fashion.
Best,
Hello Staphane, First of all thank you for letting us know about the issue. I was assigned to fix it but I couldn't reproduce the corruption. We believe that the recent version of your game hides the issue despite the fact that we altered your shaders and set the texture coordinates to mediump. If I am not asking for much, have you tested the faulty case on a Nexus 10 or is it failing only on Galaxy Note 10.1 2014? Also, is there a way to provide us with a simple case for us to reproduce the issue?
Hi Panos,
As far as our user interactions mention, the issue was not present on the Nexus 10. It was reported on devices equipped with the T628 + Exynos Octa (GS Note 3 and Note 10.1 2014) only. We however do not own a Nexus 10 currently, however, our we shipped The Bard's Tale alongside the launch of the Nexus 10 and worked directly with Google resolving issues with it (none of which were related to this particular corruption). The current build on Google Play, version 1.4.1 includes fixes for this issue, however, I can provide a 1.4 APK if there's a private email or FTP site to use. [...] albanrampon 27/11/13: removed link to APK of paid-for software [...]
Let me know how you with to proceed.
Apologies for the link. Given the time difference, it seemed like a quick way to get you setup on an older build of our application. Please let me know which of the other manners we proposed to provide it works for you.
Hi Stephane,
Please can you attach a reproducer apk directly here?
To do this, you need to go into 'Use advanced editor' then select 'Attach' in the bottom right corner.
Kind Regards,
Michael McGeagh
Hi Michael,
A version of the APK that predates the fix which is currently live is attached.
Many thanks!
Hi,
I have just found the same issue on the T604 on a Nexus 10 (Android 4.2.2) in our engine. We have used the same workaround, specifying highp for texc and color in both the vertex and fragment shaders.
Specifying lowp did not fix the problem and interestingly we only saw this issue when we reduced the complexity of the fragment shader. Originally we were testing for alpha 0 and discarding fragments and this did not show the issue.
Below is the shader which causes the issues.
Vertex shader
uniform mat4 World;
uniform mat4 View;
uniform mat4 Projection;
uniform vec4 Tint;
attribute vec3 Pos;
attribute vec2 TexCoord;
attribute vec4 Color;
varying vec2 texc;
varying vec4 color;
void main(void)
gl_Position = vec4(Pos.xyz, 1.0) * World * View * Projection;
texc = TexCoord;
color = Color * Tint;
Fragment shader
#ifdef GL_ES
precision mediump float;
#endif
uniform sampler2D DiffuseMap;
gl_FragColor = color * texture2D(DiffuseMap, texc.st);
Cheers,
Richard.
Hi Richard,
Assuming the T604 and T628 are based on the same driver core, I somewhat expected the issue to creep into the Nexus 10 distro. I can also confirm your observation that the simplicity of the shader affected the issue as many of our more complex fragment shaders were mostly unaffected.
rockettree Thanks for reporting - I'll hand this over to our development team - having a second test case is always useful to make sure we have really fixed it
> Specifying lowp did not fix the problem
Mali treats lowp the same as mediump (both are fp16), so if mediump fails I would expect lowp to fail the same way.
> I somewhat expected the issue to creep into the Nexus 10 distro.
Yeah, unfortunately the latency in the driver deployment pipeline means bugs in one product sometimes crop up again later in another one if that vendor takes a little longer to push out a driver update. The original bug reported by stepjac has been fixed for a while in our driver tree - so just waiting for this one to get pulled downstream ...
Pete