Hello.
We are experiencing an issue on the Adreno 740 where some vertex data appears to be corrupted, causing some models to flicker between rendering correctly or slightly incorrectly.
For example, in one instance of the problem, the per-vertex skin data appears to be corrupted, causing some parts of the character skinned model to flicker between the expected animation pose and the T-pose.
While debugging the issue with RenderDoc we noticed that the problem appears and disappears as we move through the draw calls, perhaps indicating that it may be related to some undefined behaviour or some synchronisation issue.
We also noticed that breaking the render pass after drawing the problematic models seems to fix the issue.
Another workaround we found is to slightly tweak the problematic vertex shader.
For example, the aforementioned issue with the character skinned model seems appears to be resolved if we replace a multiplication with an equivalent for loop:
#if ENABLE_WORKAROUND
vec4 r0 = vec4(0);
for (int i = 0; i < 256; ++i)
{
r0 += v2.zyxw;
}
#else
vec4 r0 = vec4(256.0) * v2.zyxw;
#endif
void VertexShader() { [...] // r0 is a vec4 set to some value #if ENABLE_WORKAROUND switch (int(v2.x)) { case 0: r0 = vec4(0.5, 1, 0, 0); break; case 1: r0 = vec4(0.5, 1, 0, 0); break; } gl_Position = mix(r0, gl_Position, 1); #endif }
These lines ultimately do nothing as they resolve to `gl_Position = gl_Position;` (although the glsl compiler doesn't seem to optimise them out), and are the result of us adding some debug code that fixed the problems and then pruning as much code as possible until the bug reproduces again, we couldn't get the code down any further without re-introducing the bug, although this is most likely not the only change that could solve the problems.
The workarounds we found seem a bit fragile, as they may not work on all devices and stop working on the next driver update.
Do you have any idea what could be causing the problem and how we should deal with it?
Thanks.
It sounds like there is some synchronization problem, and adding extra loops or ALU operations in the vertex shader somhow avoids the problem. Is the "per-vertex skin data" written by the GPU and later consumed by the GPU -- in this case you may need a barrier for the read-after write hazard. Is this problem using the Vulkan API? It's certainly possible this is application problem, or a driver/compiler issue. If you can share a small sample (either APK binary or source code?) that reproduces the issue, then we could investigate further.
Thanks jleger.
Answering your questions:
* No, the vertex skin data is loaded directly into the GPU from the CPU with no intermediate steps/processing.
* Yes, we are using Vulkan.
At the following link, I have attached the glsl and asm code of an affected vertex shader.
https://drive.google.com/file/d/1SsjiRaFiP6GEYqfxr6G0WBZE82Bz45Nu/view?u...
This is not the vertex shader for the skinned models mentioned above, but it is a vertex shader for billboard models, and I only chose this one because it's simpler, but still shows the same visual artifact and the same workaround applies .
VS0.txt contains both glsl and asm of the original shader, while VS1.txt contains both glsl and asm of the shader with the workaround applied (note the section at the end of the main function and how the difference in the asm code matches those of the glsl code).
A couple of things I didn't mention in the first post:
* The problem appears to be related to screen space (or perhaps tile space), i.e. only some pixels of the affected models are rendered incorrectly and you can clearly see a dividing line between the correct and incorrect rendering as you move the camera.
* Built-in variables like gl_VertexIndex also appear to be corrupted along with the user-defined vertex attribute.