Hi!
We encountered with a problem on Mali-T604, Nexus 10 (Android 5.0.1, driver release should be r5p0-06rel0). The problem seen on screenshots in attachment. In scene tank hull and turret. Geometry are represented as two vertex buffers and two index buffers, both types are created as "static draw". It's drawn by two draw-calls (turret and hull). Shaders which were used in attachment. At some camera positions part of the geometry is not drawn. And it interesting that not drawn a part of the geometry are used in one draw-call. We revise Mali Debugger for any our mistakes: all buffers content is valid, all vertex attrib-pointers are correct, primitive count passes to glDrawElements is right, uniforms values looks correct, such as any other things in GL state or resources. Depth test work correctly, stencil test are switch-off.
We found only three workarounds:
1. To use 'dynamic draw' buffers
2. Declare attribute position in vertex shader with mediump precision
3. Declare vertex position in shader as vec4
Can you help us to understand what the problem? What we do wrong or may be is't driver bug? Screenshots, .apk-file, shader-source was attached.
Thank in advance for help.
Given tagging the buffer as dynamic draw fixed it, it sounds like a driver bug in the version of the driver in your Nexus 10. The static or dynamic setting for buffers should not alter the application behavior; it's just a hint to the drivers which enables them to make some decisions on whether it should expect the buffers to change or not.
The r5p0 version of the driver is reasonably old now; we have newer drivers available (the latest release is r9p0). However, not all devices will get updates; this is down to the device manufacturer.
HTH, Pete
Hi salikq,
As Pete already mentioned, there should be little to no impact to setting it as dynamic instead of static, so I hope that this is an acceptable workaround for you.
I have ran some tests on the APK you attached and can confirm I can reproduce it. I have raised it with the driver team to investigate further.
Thank you for raising this with us.
Kind Regards,
Michael McGeagh
Thank you for raising this with us. We have detected the root cause of the problem, and it should be fixed in later releases of our driver.
However as we do not control if/when our partners release updates to existing devices, you may not want to rely on waiting for the fix to reach devices already out there.
Along with the workaround already mentioned above, here is a more thorough explanation of what is happening, in the hopes it may also give you more ideas for low impact workarounds to implement in the mean time.
The source of this problem is due to how the shaders store the view-projection.
gl_Position = mul( float4( attr_position .xyz,1.0), float4x4( VP_Buffer0[0], VP_Buffer0[1], VP_Buffer0[2], VP_Buffer0[3] ) );
Our driver expects the MVP to be a Mat4, not a vec4[4], and as such does some incorrect optimisations in this case.
I hope that helps.
Thanks for your help.