GNOME Bugzilla – Bug 730864
gl: manage GLSL versions
Last modified: 2016-11-15 03:29:47 UTC
* for deprecated keywords * for new features I would like to open the discussion about how to manage the GLSL versions for deprecated key words, as I have not found an ideal solution after a first investigation. attribute and varying keywords are deprecated since GLSL 1.3 (GL3, GLES2 ?). Not sure in which version they are removed though. in/out should be used instead. After initial investigation we could add the following in top of every shader text: vs: "#if __VERSION__ >= 130" "#define attribute in" "#define varying out" "#endif" fs: "#if __VERSION__ >= 130" "#define varying in\n" "#define out vec4 gl_FragColor\n" "#endif\n" If not set by the user, "#version N core" is automatically set with N be the highest that implementation supports if nothing is specified. "#version N compatibility" (core is implicit if you do not put it) could be added to allow using attribute and varying. So maybe "#version __VERSION__ compatibility" could be a solution too. Though I already saw that on my Mac __VERSION__ is set to 0 whereas it's explicitly mentioned in the 1.2 spec that it should be defined to the top most supported version. Or just put "#version 120" in top of our current shaders. In any cases it seems to also depend of if the driver correctly implement the spec or not. As mentioned above, __VERSION__ is set to 0 in some cases even on some mesa versions. For new features, i.e. in case of one of our shader require a minimal version to work, we would need to do some probing first to check which version is available and enable gl elements + some of their feature according to the actual version. (using GstDeviceMonitor ?) Any thought ?
(In reply to comment #0) > Or just put "#version 120" in top of our current shaders. This is the correct thing to do. However we don't ask for a core GL context with any platform yet. > For new features, i.e. in case of one of our shader require a minimal version > to work, we would need to do some probing first to check which version is > available and enable gl elements + some of their feature according to the > actual version. (using GstDeviceMonitor ?) There is a direct correlation between the GL version and the minimum required GLSL version supported by that context. There is API at the GstGLContext level to get/check the GL version supported that elements can use.
These days we perform some mangling of shaders to support the slight differences between shader versions. As a result most of the above is obselete, the rest is up to the user to decide exactly what they want.