After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765517 - glcolorconvert: fix Fragment shader compile error in GLES3.0 or higher
glcolorconvert: fix Fragment shader compile error in GLES3.0 or higher
Status: RESOLVED DUPLICATE of bug 765266
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-25 07:28 UTC by Haihua Hu
Modified: 2016-04-25 07:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Haihua Hu 2016-04-25 07:28:35 UTC 
1. glcolorconvert fragment shader compile error when using OpenGL ES 3.0 or higher.

When compile shader (for example RGB->PlanerYUV) on OpenGL ES 3.0 or higher，I meet an error like bellow:

(39:0) : error : function: 'texture2D' does not have a corresponding declaration
(55:0) : error : reserved keyword : 'sample'
(55:0) : error : syntax error at 'sample'

In OpenGL ES Shading Language version 3.0 or higher, function "texture2D" is changed to "texture" and 'sample' has become a reserved keyword for future use which will also result in compile error.

2. By the way, when build glcolorconvert for OpenGL ES, I meet another build error.
Form function “gst_gl_shader_bind_frag_data_location”, gl->BindFragDataLocation is not an OpenGL ES API but Desktop GL API. We need add compile macro here.
Comment 1 Sebastian Dröge (slomo) 2016-04-25 07:35:24 UTC 
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 765266 ***
Comment 2 Sebastian Dröge (slomo) 2016-04-25 07:37:45 UTC 
Can you open a bug with more details about the BindFragDataLocation problem? Everything compiles fine here on various platforms, even if only GLES is available.
Comment 3 Haihua Hu 2016-04-25 07:41:25 UTC 
(In reply to Sebastian Dröge (slomo) from comment #2)
> Can you open a bug with more details about the BindFragDataLocation problem?
> Everything compiles fine here on various platforms, even if only GLES is
> available.

Ok, Thanks for your information.
Comment 4 Haihua Hu 2016-04-25 07:56:55 UTC 
(In reply to Sebastian Dröge (slomo) from comment #2)
> Can you open a bug with more details about the BindFragDataLocation problem?
> Everything compiles fine here on various platforms, even if only GLES is
> available.

Hi Sebastian,

I think I have fix the BindFragDataLocation problem, because I missed a patch when I cherry pick commit to my local branch. So no need open a new bug.

Thanks a lot.