When I pass half float vertex attribute directly (unmodified) to a varying, I get incorrect values in the fragment shader.
This works:
vTexCoord = vec2(1.00001 * TextureCoordinate0.x, 1.0001 * TextureCoordinate0.y);
This does not work:
vTexCoord = vec2(TextureCoordinate0.x, TextureCoordinate0.y);
To me this seems like half float needs to be converted by the vertex shader before interpolation, but shader compiler does not do this when attribute is passed unmodified to the varying in the vertex shader. Also, the very first draw call looks like it comes out correct, but all subsequent frames come out incorrectly.
This happens on SM-T900 with GL renderer reported as Mali-T628.
Where should I report this kind of suspected driver bugs? Is there database of known bugs?
I can work around this { if (gl_renderer.substr(0, 9) == "Mali-T628") halfFloatVertexAttribute = false; } but this it is unfortunate that GL renderer string has no driver version information.
Hi tksuoran,
Thank you for raising this with us.
I would like additional information if possible, to help us figure out the cause of this.
What Android OS version are you running?
Could you also run the following adb linux command to determine the Mali driver version?
adb pull /vendor/lib/egl/libGLES_mali.so ; strings libGLES_mali.so | grep 'r[0-9]p[0-9]-'
It should report something similar to 'r5p0-02rel0' for example
In addition, if you could provide a reproducer app, then this would help us with our testing to reproduce your issue.
Kind Regards,
Michael McGeagh
Device information: Android version: 4.4.2, Kernel version: 3.4.39-2534013, Model number: SM-T900
Mali driver version: 1.4 Midgard-"r3p0-eac-wk30"
I will figure out if I can make an .apk available for you.
I have a reproducer apk, how can I pass it to you?
If it is small enough, and assuming it contains your own code only, you can attach it to this post.
If you launch the Advanced Editor, you have the ability to Attach files to your post (bottom right corner).
If you prefer it to be kept private, you can create a new discussion and attach it there, but only invite myself to that discussion (Specific Members), which will make it private.
If there is an attached license with it, we will have to first review this.
If it is larger than the allowed attachment limit, then feel free to chose a hosting service you prefer, for example Dropbox, and send the link across.
We have successfully reproduced it using the stock image for that device. It appears that this was a bug in the driver that is found in that stock image (r3p0), however has since been fixed since r4p0. (April 2014)
As we are not in control of Samsung's OTA process, we cannot comment on if/when an update may go out for this device (and others that are using r3p0 driver) to resolve this issue.
We can only suggest that in your application, if you detect the device is running older than r4p0 drivers, then to fallback to a workaround, which as you have already figured out, is to stop it from being a passthrough (e.g. multiply by 1.0000000001)
I apologise that I cannot give you a better answer. If you require the fix to be rolled out, you would need to contact Samsung and try convince them.
Thanks!
Do you have recommended method to detect driver version from application code (linux & android)? Could you please add driver version number to GL_RENDERER string in the future? This would greatly help to select which workarounds are needed.
We have realised that is a problem and have already added version information into GL_RENDERER already, but cannot say when this change will make it to devices already out in the world as we do not control the OTA updates.
Thanks again for your assistance, and I hope we were of help.