• Locked Locked
  • Replies 5 replies
  • Subscribers 136 subscribers
  • Views 5533 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Bug in driver (Android SGS 2 I9100)

Laurent Mallet
Note: This was originally posted on 3rd June 2011 at http://forums.arm.com

Hello,

I'm an Android dev and have bought the SGS 2 I9100 (GPU Mali 400). I have developed a tool called
GPUBench and tested on this device and found a bug which cause many artefact.

In shader, sin & cos are valid (or correct) between -6.14 and 6.14; when angle is important, result are
false.

I have created and apk which show the problem:
And there is code source:
How fix driver on Android ? Is it the work of ARM or Samsung ?

Thanks

twitter: ellis2323
mail: laurent.mallet at_ gmail.com
Parents
  • Note: This was originally posted on 3rd June 2011 at http://forums.arm.com

    Hi Laurent,

    Thank you for your forum post. I've downloaded your sample code and run it on a device. After examining your code I can see that the problems are indeed occurring in your fragment shader. However, I do not believe the issue is with the atan(), sin() and cos() functions but rather an issue of precision.

    In your fragment shader you are requesting high precision floating point ("precision highp float;") and again repeating (unnecessarily) the "highp" option on some of your vectors. The OpenGL ES Shading Language specification states that for fragment shaders, high precision is optional and requires a minimum of 16bit precision; applications must be written with this in mind. To check whether high precision is supported in the fragment shader you should check for the OES_fragment_precision_high extension in glGetString(GL_EXTENSIONS). I also noticed that in your Java code you are incrementing your time value (which is passed to the shader) indefinitely without sanity checks "" this will cause any system to "˜break' eventually regardless of the precision used. Floating point gives dynamic range rather than precision "" the best way to get what you want is to normalize your input.

    Special care needs to be taken when writing applications for OpenGL ES 2.0 devices; they do not have the high level of precision of desktop OpenGL.

    Can I ask what you are trying to achieve? Maybe we could help you find a better solution.

    Best regards,

    Doug

Reply
  • Note: This was originally posted on 3rd June 2011 at http://forums.arm.com

    Hi Laurent,

    Thank you for your forum post. I've downloaded your sample code and run it on a device. After examining your code I can see that the problems are indeed occurring in your fragment shader. However, I do not believe the issue is with the atan(), sin() and cos() functions but rather an issue of precision.

    In your fragment shader you are requesting high precision floating point ("precision highp float;") and again repeating (unnecessarily) the "highp" option on some of your vectors. The OpenGL ES Shading Language specification states that for fragment shaders, high precision is optional and requires a minimum of 16bit precision; applications must be written with this in mind. To check whether high precision is supported in the fragment shader you should check for the OES_fragment_precision_high extension in glGetString(GL_EXTENSIONS). I also noticed that in your Java code you are incrementing your time value (which is passed to the shader) indefinitely without sanity checks "" this will cause any system to "˜break' eventually regardless of the precision used. Floating point gives dynamic range rather than precision "" the best way to get what you want is to normalize your input.

    Special care needs to be taken when writing applications for OpenGL ES 2.0 devices; they do not have the high level of precision of desktop OpenGL.

    Can I ask what you are trying to achieve? Maybe we could help you find a better solution.

    Best regards,

    Doug

Children
No data