• Locked Locked
  • Replies 8 replies
  • Subscribers 136 subscribers
  • Views 6531 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
Parents
  • 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
Reply
  • 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
Children
No data