This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Issue with half float vertex attribute/varying with OpenGL ES on Mali-T628

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.


Parents
  • Hi tksuoran,

    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.

    Kind Regards,

    Michael McGeagh

Reply
  • Hi tksuoran,

    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.

    Kind Regards,

    Michael McGeagh

Children