GNOME Bugzilla – Bug 740012
gl: support opengl3+ core contexts
Last modified: 2014-11-29 13:45:35 UTC
Some preliminary code is available from: https://github.com/ystreet/gst-plugins-bad/gl3 Only glx asks for the gl3 core context. Currently it unconditionally relies on the GL_ARB_es2_compatability extension to use the gles2 shaders without modification because I'm lazy :). That will need to be rectified by generating gl3 shaders either automatically (hard) or manually (easy ;)). The following elements have been ported: glimagesink, glcolorscale, gleffects (gles2 part).
On OSX this can also be easily activated by passing additional attributes to the context creation. I experimented a bit with that some time ago but don't have the changes anymore :)
Great! The correct link seems to be https://github.com/ystreet/gst-plugins-bad/commits/gl3 This is another subject but looking at the commits I think we should create gstgl API for vao's and vbo's . I can see that gstglcolorconvert, gstglfilter and gstglimagesink code around this. Also out of curiosity, in theory it should be faster but do you actually see any measurable performance gain ?
(In reply to comment #2) > This is another subject but looking at the commits I think we should create > gstgl API for vao's and vbo's . I can see that gstglcolorconvert, gstglfilter > and gstglimagesink code around this. For vbo's and gl buffers in general, I was thinking of some GstMemory subclass so that it might be possible to pass vertex data through elements (It also future proofs the 3d modelling side of things where that's pretty much all you deal with). also related is bug #726412 I'm still undecided on what to do with vao's for the exact same reason as framebuffers. They are simply client-side container objects that are not shareable across contexts and I'm not sure where they fit in with the gstgl API yet. > Also out of curiosity, in theory it should be faster but do you actually see > any measurable performance gain ? No, we're not push anywhere near enough vertex data to have any performance impact :)
I've just merged this branch irrespective of the shader versions issue as it seems that GL_ARB_ES2_compatability is supported by all the major drivers. http://feedback.wildfiregames.com/report/opengl/feature/GL_ARB_ES2_compatibility
Created attachment 291688 [details] [review] gldisplay: return GST_GL_API_NONE if display is not a GL_DISPLAY These commits break compilation with fatal warnings due to return with no value on a non-void function. This commit fix it by returning GST_GL_API_NONE.
Thanks for the patch however I already fixed it and did not see you patch :) commit f67190d3ca6f5d947a1f21ee5d52dcb5082655be Author: Matthew Waters <matthew@centricular.com> Date: Fri Nov 28 10:03:18 2014 +1100 gldisplay: fix build error gstgldisplay.c:234:541: error: 'return' with no value, in function returning non-void [-Werror] g_return_if_fail (GST_IS_GL_DISPLAY (display));
We should probably add some code that checks if the extension is actually available and fails early otherwise.
This breaks on platforms that don't support GL3, or hide GL3 functions if creating a context for an older version. E.g. OSX. glimagesink now unconditionally uses glGenVertexArrays (and a lot of other code too), which is only available in GL3 and GLES2.
commit 90a2477b9e63136730bf01d1ebcaec1a42dd3962 Author: Matthew Waters <matthew@centricular.com> Date: Sun Nov 30 00:42:17 2014 +1100 glcontext: require GL_ARB_ES2_compatibility for opengl3 until we generate gl3 compliant shaders https://bugzilla.gnome.org/show_bug.cgi?id=740012 commit 6361df77e8eac857e3757b13810be64ae347f786 Author: Matthew Waters <matthew@centricular.com> Date: Sun Nov 30 00:18:55 2014 +1100 glimagesink: properly handle the !opengl3 case https://bugzilla.gnome.org/show_bug.cgi?id=740012