Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Pelion IoT Platform
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
Tools and Software
Graphics and Gaming
Jump...
Cancel
Graphics and Gaming
Graphics and Gaming forum
glShaderBinary problem
Blog
Forum
Videos & Files
Help
Jump...
Cancel
New
Replies
8 replies
Subscribers
133 subscribers
Views
4221 views
Users
0 members are here
OpenGL ES
Related
glShaderBinary problem
Offline
dhammike wickramanayake
over 7 years ago
Parents
Offline
Chris Varnsverry
over 7 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
Reply
Cancel
Reply
Offline
Chris Varnsverry
over 7 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
Reply
Cancel
Children
No data
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Not Answered
mali-checker showing as no opengl es version support available.
0
4117
views
0
replies
Started
2 months ago
by
tattimano
Answered
Zero GPU activity during "long" periods of time
+1
Mali GPU (Bifrost Architecture)
Streamline Performance Analyzer
5167
views
5
replies
Latest
2 months ago
by
JPJ
Answered
Help interpreting L/S and Texture memory usage
0
Mali GPU (Bifrost Architecture)
Streamline Performance Analyzer
5585
views
4
replies
Latest
2 months ago
by
JPJ
Not Answered
Display problem in GTK/Webkit with RK3288 Mali-T764
0
4720
views
1
reply
Latest
2 months ago
by
IronKang
Answered
Texture Cache on Mali-G76
+1
4998
views
1
reply
Latest
2 months ago
by
Kévin Petit
<
>
View all questions in Graphics and Gaming forum