• Locked Locked
  • Replies 8 replies
  • Subscribers 136 subscribers
  • Views 6444 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

glShaderBinary problem

dhammike wickramanayake
  • Note: This was originally posted on 4th September 2012 at http://forums.arm.com

    Hi Dhammike,

    Sorry to hear that you are facing problems with binary shaders. We would like to reproduce this issue to better understand the cause of the crash. In the meantime, have you had any success with using binary shaders in another app(not the native-media sample) for instance?

    We will keep you posted on any information we can find.

    Cheers
    Karthik
  • Note: This was originally posted on 4th September 2012 at http://forums.arm.com

    Hi Karthik,
    Thank you for the reply. Yes, I tried with other samples which did not involve surface textures and they were working fine.  I don't know whether this problem is related to GLSurfaceView? I noticed these errors are thrown when trying to destroy the EGLcontext. As I mentioned before when I am not using the binaries applications works fine.

    Dhammike


    Hi Dhammike,

    Sorry to hear that you are facing problems with binary shaders. We would like to reproduce this issue to better understand the cause of the crash. In the meantime, have you had any success with using binary shaders in another app(not the native-media sample) for instance?

    We will keep you posted on any information we can find.

    Cheers
    Karthik
  • Note: This was originally posted on 20th September 2012 at http://forums.arm.com

    Hi dhammike,

    Just thought I'd break the silence and let you know we have been and are still looking into this problem. We haven't forgotten! We hope to have an answer for you soon.

    Thanks
    Chris
  • Note: This was originally posted on 3rd October 2012 at http://forums.arm.com

    Hi dhammike,

    I've forwarded this issue to the driver team for them to investigate further, but I'll update you now on the current status:

    The issue does not present itself when shaders are compiled from source (glShaderSource + glCompileShader) but does present itself when shader binaries are loaded (glShaderBinary). This appears (investigation ongoing) to be caused in this case by the use of the variable type "samplerExternalOES", exposed by the extension "GL_OES_EGL_image_external" in the fragment shader.

    For a possible workaround, I attempted to use "program binaries" instead of shader binaries. Essentially, this replaces the glShaderBinary + glLinkProgram steps, with one call to glProgramBinaryOES. This relies on an extension, GL_OES_get_program_binary, which is unfortunately not supported in the version of the Mali drivers currently present in Samsung devices (tested on SGS3 4.0.4+4.1.1). The hope was that this would avoid the issue by using a slightly different path, but still granting you the ability to use binaries to protect your intellectual property.

    The driver team are looking into this (it may already be solved in later versions), but for devices using version r2p4 of the Mali drivers unfortunately I can only offer the following suggestions:
    • Compiling shaders from source at runtime. This method will always require an ASCII string to be passed to the driver containing the source code for your shaders, and so is vulnerable to interception at the API level. You can however take measures to ensure it's not as simple as opening the APK in winzip and finding the source file, for example you could obfuscate the string, and/or contain the string within the binary itself.
    • Consider investigating different implementations of the shaders using different extensions which may not cause this error, or indeed no extensions at all.
    I will keep you updated via this thread of any relevant findings as a result of the ongoing investigation into this issue. I unfortunately cannot guarantee if/when a resolution will be found. Thank you for your patience!

    Chris
  • Note: This was originally posted on 30th October 2012 at http://forums.arm.com

    Hi Chris,
    Thank you very much for the reply and suggestions. Compiling shaders from source at runtime is not desirable since our proprietary information is in the shaders. This issue has become the biggest hurdle in deploying our product into the Mali based handsets.

    Could you please let me know any Samsung device with driver version later to r2p4?

    Thank you,

    Dhammike



    Hi dhammike,

    I've forwarded this issue to the driver team for them to investigate further, but I'll update you now on the current status:

    The issue does not present itself when shaders are compiled from source (glShaderSource + glCompileShader) but does present itself when shader binaries are loaded (glShaderBinary). This appears (investigation ongoing) to be caused in this case by the use of the variable type "samplerExternalOES", exposed by the extension "GL_OES_EGL_image_external" in the fragment shader.

    For a possible workaround, I attempted to use "program binaries" instead of shader binaries. Essentially, this replaces the glShaderBinary + glLinkProgram steps, with one call to glProgramBinaryOES. This relies on an extension, GL_OES_get_program_binary, which is unfortunately not supported in the version of the Mali drivers currently present in Samsung devices (tested on SGS3 4.0.4+4.1.1). The hope was that this would avoid the issue by using a slightly different path, but still granting you the ability to use binaries to protect your intellectual property.

    The driver team are looking into this (it may already be solved in later versions), but for devices using version r2p4 of the Mali drivers unfortunately I can only offer the following suggestions:
    • Compiling shaders from source at runtime. This method will always require an ASCII string to be passed to the driver containing the source code for your shaders, and so is vulnerable to interception at the API level. You can however take measures to ensure it's not as simple as opening the APK in winzip and finding the source file, for example you could obfuscate the string, and/or contain the string within the binary itself.
    • Consider investigating different implementations of the shaders using different extensions which may not cause this error, or indeed no extensions at all.
    I will keep you updated via this thread of any relevant findings as a result of the ongoing investigation into this issue. I unfortunately cannot guarantee if/when a resolution will be found. Thank you for your patience!

    Chris

  • Has this issue been resolved? I am using a latest galaxy S6 and I have problems using glShaderBinary. Although I am usingGL_OES_EGL_image_external I am not sure if that is the source of the issue.

    Thanks,

  • in reply to Aria

    Hi phyxle,

    Since the original question asked was ported from the old forum to this website, there is some missing information from the original request.

    If you are having a problem, please explain in more detail the issue you are facing, as well as information about the target device such as the version of Android on your S6.

    If you have a reproducer you can provide, this will help speed things up.

    Please also do realise the issues associated with using shader/program binaries, and that there is no guarantee that one binary from one device will work on another device, even if the GPU is labelled as the same.

    This is because the Silicon Partners/OEMs can make changes to the GPU, adding their differentiating features for example, which cause binaries to not necessarily work across other implementations.

    Kind Regards,

    Michael McGeagh