Arm Community
Site
Search
User
Site
Search
User
Groups
Education Hub
Distinguished Ambassadors
Open Source Software and Platforms
Research Collaboration and Enablement
Forums
AI and ML forum
Architectures and Processors forum
Arm Development Platforms forum
Arm Development Studio forum
Arm Virtual Hardware forum
Automotive forum
Compilers and Libraries forum
Graphics, Gaming, and VR forum
High Performance Computing (HPC) forum
Infrastructure Solutions forum
Internet of Things (IoT) forum
Keil forum
Morello forum
Operating Systems forum
SoC Design and Simulation forum
SystemReady Forum
Blogs
AI and ML blog
Announcements
Architectures and Processors blog
Automotive blog
Graphics, Gaming, and VR blog
High Performance Computing (HPC) blog
Infrastructure Solutions blog
Internet of Things (IoT) blog
Operating Systems blog
SoC Design and Simulation blog
Tools, Software and IDEs blog
Support
Arm Support Services
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Support forums
Graphics, Gaming, and VR forum
glShaderBinary problem
Jump...
Cancel
Locked
Locked
Replies
8 replies
Subscribers
136 subscribers
Views
6448 views
Users
0 members are here
OpenGL ES
Options
Share
More actions
Cancel
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
over 10 years ago
Parents
Chris Varnsverry
over 10 years ago
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
Cancel
Up
0
Down
Cancel
Reply
Chris Varnsverry
over 10 years ago
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
Cancel
Up
0
Down
Cancel
Children
No data