isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-09-20 14:35:48 -04:00
Code Issues Packages Projects Releases Wiki Activity
9b7f362ea4
mutter/cogl/cogl-pipeline-fragend-glsl.c

900 lines
28 KiB
C
Raw Normal View History

material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2008,2009,2010 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*
*
*
* Authors:
* Robert Bragg <robert@linux.intel.com>
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
* Neil Roberts <neil@linux.intel.com>
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
#include <string.h>
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
#include "cogl-pipeline-private.h"
material-glsl: #include "cogl-shader-private.h" We need to include cogl-shader-private.h to have the COGL_SHADER_TYPE_GLSL define. When building for opengl this wasn't noticed probably because some other header indirectly includes this file. It was a problem when building for gles2 though.
2010-08-12 05:37:55 -04:00
#include "cogl-shader-private.h"
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
#include "cogl-blend-string.h"
build: Fix GLES builds since the material backend split The commit to split the fragment processing backends out from cogl-material.c (3e1323a6362906a95) broke the GLES 1 and 2 builds the fix was to guard the code in each backend according to the COGL_MATERIAL_BACKEND_XYZ defines which are setup in cogl-material-private.h.
2010-07-01 20:07:36 -04:00
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#ifdef COGL_PIPELINE_FRAGEND_GLSL
build: Fix GLES builds since the material backend split The commit to split the fragment processing backends out from cogl-material.c (3e1323a6362906a95) broke the GLES 1 and 2 builds the fix was to guard the code in each backend according to the COGL_MATERIAL_BACKEND_XYZ defines which are setup in cogl-material-private.h.
2010-07-01 20:07:36 -04:00
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
#include "cogl.h"
#include "cogl-internal.h"
#include "cogl-context.h"
#include "cogl-handle.h"
egl: Fix compilation for EGL native Some minor fixes here and there: missing include, wrongly placed #endif, unused variable warning fixes, missing #ifdef. Make ClutterStageEGL a subclass of either ClutterStageX11 or GObject depending if you compile with X11 support (EGLX) or not (native).
2010-08-12 09:05:01 -04:00
#include "cogl-shader-private.h"
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
#include "cogl-program-private.h"
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
#ifndef HAVE_COGL_GLES2
build: Start moving to a non-recursive layout *** WARNING: THIS COMMIT CHANGES THE BUILD *** Do not recurse into the backend directories to build private, internal libraries. We only recurse from clutter/ into the cogl sub-directory; from there, we don't recurse any further. All the backend-specific code in Cogl and Clutter is compiled conditionally depending on the macros defined by the configure script. We still recurse from the top-level directory into doc, clutter and tests, because gtk-doc and tests do not deal nicely with non-recursive layouts. This change makes Clutter compile slightly faster, and cleans up the build system, especially when dealing with introspection data. Ideally, we also want to make Cogl part of the top-level build, so that we can finally drop the sed trick to change the shared library from the GIR before compiling it. Currently disabled: ‣ OSX backend ‣ Fruity backend Currently enabled but untested: ‣ EGL backend ‣ Windows backend
2010-09-13 06:30:30 -04:00
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
#define glCreateShader ctx->drv.pf_glCreateShader
#define glGetShaderiv ctx->drv.pf_glGetShaderiv
#define glGetShaderInfoLog ctx->drv.pf_glGetShaderInfoLog
#define glCompileShader ctx->drv.pf_glCompileShader
#define glShaderSource ctx->drv.pf_glShaderSource
#define glDeleteShader ctx->drv.pf_glDeleteShader
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
#endif /* HAVE_COGL_GLES2 */
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
#include <glib.h>
/*
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* GL/GLES compatability defines for pipeline thingies:
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
*/
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
/* This might not be defined on GLES */
#ifndef GL_TEXTURE_3D
#define GL_TEXTURE_3D 0x806F
#endif
typedef struct _UnitState
{
unsigned int sampled:1;
unsigned int combine_constant_used:1;
} UnitState;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
typedef struct _GlslShaderState
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
int ref_count;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GLuint gl_shader;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
GString *header, *source;
UnitState *unit_state;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
/* Age of the user program that was current when the shader was
generated. We need to keep track of this because if the user
program changes then we may need to redecide whether to generate
a shader at all */
unsigned int user_program_age;
} GlslShaderState;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
typedef struct _CoglPipelineFragendGlslPrivate
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *glsl_shader_state;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
} CoglPipelineFragendGlslPrivate;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
const CoglPipelineFragend _cogl_pipeline_glsl_backend;
material: don't declare backend vtables in headers This fixes the material backends to declare their constant vtable in the c file with a corresponding extern declaration in the header. This should fix complaints about duplicate symbols seen on OSX.
2010-09-14 07:13:30 -04:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
static GlslShaderState *
glsl_shader_state_new (int n_layers)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *state = g_slice_new0 (GlslShaderState);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
state->ref_count = 1;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
state->unit_state = g_new0 (UnitState, n_layers);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
return state;
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
static GlslShaderState *
glsl_shader_state_ref (GlslShaderState *state)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
state->ref_count++;
return state;
}
void
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
glsl_shader_state_unref (GlslShaderState *state)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
g_return_if_fail (state->ref_count > 0);
state->ref_count--;
if (state->ref_count == 0)
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (state->gl_shader)
GE( glDeleteShader (state->gl_shader) );
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
g_free (state->unit_state);
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_slice_free (GlslShaderState, state);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
}
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
static CoglPipelineFragendGlslPrivate *
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
get_glsl_priv (CoglPipeline *pipeline)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
if (!(pipeline->fragend_priv_set_mask & COGL_PIPELINE_FRAGEND_GLSL_MASK))
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
return NULL;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
return pipeline->fragend_privs[COGL_PIPELINE_FRAGEND_GLSL];
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
static void
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
set_glsl_priv (CoglPipeline *pipeline, CoglPipelineFragendGlslPrivate *priv)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
if (priv)
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
pipeline->fragend_privs[COGL_PIPELINE_FRAGEND_GLSL] = priv;
pipeline->fragend_priv_set_mask |= COGL_PIPELINE_FRAGEND_GLSL_MASK;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
else
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
pipeline->fragend_priv_set_mask &= ~COGL_PIPELINE_FRAGEND_GLSL_MASK;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
static GlslShaderState *
get_glsl_shader_state (CoglPipeline *pipeline)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendGlslPrivate *priv = get_glsl_priv (pipeline);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
if (!priv)
return NULL;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
return priv->glsl_shader_state;
}
GLuint
_cogl_pipeline_fragend_glsl_get_shader (CoglPipeline *pipeline)
{
GlslShaderState *glsl_shader_state = get_glsl_shader_state (pipeline);
if (glsl_shader_state)
return glsl_shader_state->gl_shader;
else
return 0;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
static void
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
dirty_glsl_shader_state (CoglPipeline *pipeline)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendGlslPrivate *priv;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
priv = get_glsl_priv (pipeline);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
if (!priv)
return;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (priv->glsl_shader_state)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
glsl_shader_state_unref (priv->glsl_shader_state);
priv->glsl_shader_state = NULL;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
}
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
static gboolean
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_start (CoglPipeline *pipeline,
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
int n_layers,
Revert "cogl: Remove the generated array size for cogl_tex_coord_in" This reverts commit 4cfe90bde275dbb952645397aa2ba2d6f6e2f3ba. GLSL 1.00 on GLES doesn't support unsized arrays so the whole idea can't work. Conflicts: clutter/cogl/cogl/cogl-pipeline-glsl.c
2010-12-02 16:08:30 -05:00
unsigned long pipelines_difference,
int n_tex_coord_attribs)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendGlslPrivate *priv;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *authority;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendGlslPrivate *authority_priv;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
CoglProgram *user_program;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
int i;
cogl: Allow setting ARBfp source on a CoglShader This makes CoglProgram/Shader automatically detect when the user has given an ARBfp program by checking for "!!ARBfp1.0" at the beginning of the user's source. ARBfp local parameters can be set with cogl_program_uniform_float assuming you pass a @size of 4 (all ARBfp program.local parameters are vectors of 4 floats). This doesn't expose ARBfp environment parameters or double precision local parameters.
2010-08-04 12:53:51 -04:00
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
_COGL_GET_CONTEXT (ctx, FALSE);
if (!cogl_features_available (COGL_FEATURE_SHADERS_GLSL))
return FALSE;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
user_program = cogl_pipeline_get_user_program (pipeline);
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
/* If the user fragment shader isn't GLSL then we should let
another backend handle it */
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
if (user_program &&
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
_cogl_program_has_fragment_shader (user_program) &&
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_cogl_program_get_language (user_program) != COGL_SHADER_LANGUAGE_GLSL)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
return FALSE;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
/* Now lookup our glsl backend private state (allocating if
* necessary) */
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
priv = get_glsl_priv (pipeline);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
if (!priv)
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
priv = g_slice_new0 (CoglPipelineFragendGlslPrivate);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
set_glsl_priv (pipeline, priv);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (!priv->glsl_shader_state)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
/* If we don't have an associated glsl shader yet then find the
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
* glsl-authority (the oldest ancestor whose state will result in
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
* the same shader being generated as for this pipeline).
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
*
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
* We always make sure to associate new shader with the
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* glsl-authority to maximize the chance that other pipelines can
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
* share it.
*/
cogl-pipeline: Make find codegen authority more general The pipeline function _cogl_pipeline_find_codegen_authority has been renamed to _cogl_pipeline_find_equivalent_parent and it now takes a set of flags for the pipeline and layer state that affects the authority. This is needed so that we can reuse the same code in the vertend and progends.
2010-12-01 12:06:18 -05:00
authority = _cogl_pipeline_find_equivalent_parent
(pipeline,
COGL_PIPELINE_STATE_AFFECTS_FRAGMENT_CODEGEN &
~COGL_PIPELINE_STATE_LAYERS,
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
COGL_PIPELINE_LAYER_STATE_AFFECTS_FRAGMENT_CODEGEN);
cogl-pipeline: Make find codegen authority more general The pipeline function _cogl_pipeline_find_codegen_authority has been renamed to _cogl_pipeline_find_equivalent_parent and it now takes a set of flags for the pipeline and layer state that affects the authority. This is needed so that we can reuse the same code in the vertend and progends.
2010-12-01 12:06:18 -05:00
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
authority_priv = get_glsl_priv (authority);
if (!authority_priv)
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
authority_priv = g_slice_new0 (CoglPipelineFragendGlslPrivate);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
set_glsl_priv (authority, authority_priv);
}
/* If we don't have an existing program associated with the
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
* glsl-authority then start generating code for a new shader...
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
*/
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (!authority_priv->glsl_shader_state)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *glsl_shader_state =
glsl_shader_state_new (n_layers);
authority_priv->glsl_shader_state = glsl_shader_state;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
/* If the pipeline isn't actually its own glsl-authority
* then take a reference to the program state associated
* with the glsl-authority... */
if (authority != pipeline)
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
priv->glsl_shader_state =
glsl_shader_state_ref (authority_priv->glsl_shader_state);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (priv->glsl_shader_state->gl_shader)
cogl-pipeline-glsl: Fix reusing shaders for shared ancestors The check for whether we can reuse a program we've already generated was only being done if the pipeline already had a glsl_program_state. When there is no glsl_program_state it then looks for the nearest ancestor it can share the program with. It then wasn't checking whether that ancestor already had a GL program so it would start generating the source again. It wouldn't however compile that source again because _cogl_pipeline_backend_glsl_end does check whether there is already a program. This patch moves the check until after it has found the glsl_program_state, whether or not it was found from an ancestor or as its own state.
2010-12-02 11:30:55 -05:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
/* If we already have a valid GLSL shader then we don't need to
generate a new one. However if there's a user program and it
has changed since the last link then we do need a new shader */
cogl-pipeline-glsl: Fix reusing shaders for shared ancestors The check for whether we can reuse a program we've already generated was only being done if the pipeline already had a glsl_program_state. When there is no glsl_program_state it then looks for the nearest ancestor it can share the program with. It then wasn't checking whether that ancestor already had a GL program so it would start generating the source again. It wouldn't however compile that source again because _cogl_pipeline_backend_glsl_end does check whether there is already a program. This patch moves the check until after it has found the glsl_program_state, whether or not it was found from an ancestor or as its own state.
2010-12-02 11:30:55 -05:00
if (user_program == NULL ||
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
(priv->glsl_shader_state->user_program_age == user_program->age))
cogl-pipeline-glsl: Fix reusing shaders for shared ancestors The check for whether we can reuse a program we've already generated was only being done if the pipeline already had a glsl_program_state. When there is no glsl_program_state it then looks for the nearest ancestor it can share the program with. It then wasn't checking whether that ancestor already had a GL program so it would start generating the source again. It wouldn't however compile that source again because _cogl_pipeline_backend_glsl_end does check whether there is already a program. This patch moves the check until after it has found the glsl_program_state, whether or not it was found from an ancestor or as its own state.
2010-12-02 11:30:55 -05:00
return TRUE;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
/* We need to recreate the shader so destroy the existing one */
GE( glDeleteShader (priv->glsl_shader_state->gl_shader) );
priv->glsl_shader_state->gl_shader = 0;
cogl-pipeline-glsl: Fix reusing shaders for shared ancestors The check for whether we can reuse a program we've already generated was only being done if the pipeline already had a glsl_program_state. When there is no glsl_program_state it then looks for the nearest ancestor it can share the program with. It then wasn't checking whether that ancestor already had a GL program so it would start generating the source again. It wouldn't however compile that source again because _cogl_pipeline_backend_glsl_end does check whether there is already a program. This patch moves the check until after it has found the glsl_program_state, whether or not it was found from an ancestor or as its own state.
2010-12-02 11:30:55 -05:00
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
/* If we make it here then we have a glsl_shader_state struct
without a gl_shader either because this is the first time we've
encountered it or because the user program has changed */
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
if (user_program)
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
priv->glsl_shader_state->user_program_age = user_program->age;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
/* If the user program contains a fragment shader then we don't need
to generate one */
if (user_program &&
_cogl_program_has_fragment_shader (user_program))
return TRUE;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
/* We reuse two grow-only GStrings for code-gen. One string
contains the uniform and attribute declarations while the
other contains the main function. We need two strings
because we need to dynamically declare attributes as the
add_layer callback is invoked */
cogl-pipeline: Rename the fragment_{source,header}_buffer to codegen We want to reuse the same buffers for vertends so calling them fragment_* doesn't make sense.
2010-12-02 13:05:22 -05:00
g_string_set_size (ctx->codegen_header_buffer, 0);
g_string_set_size (ctx->codegen_source_buffer, 0);
priv->glsl_shader_state->header = ctx->codegen_header_buffer;
priv->glsl_shader_state->source = ctx->codegen_source_buffer;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (priv->glsl_shader_state->source,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
"void\n"
"main ()\n"
"{\n");
for (i = 0; i < n_layers; i++)
cogl-shader: Prepend boilerplate for portable shaders We now prepend a set of defines to any given GLSL shader so that we can define builtin uniforms/attributes within the "cogl" namespace that we can use to provide compatibility across a range of the earlier versions of GLSL. This updates test-cogl-shader-glsl.c and test-shader.c so they no longer needs to special case GLES vs GL when splicing together its shaders as well as the blur, colorize and desaturate effects. To get a feel for the new, portable uniform/attribute names here are the defines for OpenGL vertex shaders: #define cogl_position_in gl_Vertex #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_MultiTexCoord0 #define cogl_tex_coord0_in gl_MultiTexCoord0 #define cogl_tex_coord1_in gl_MultiTexCoord1 #define cogl_tex_coord2_in gl_MultiTexCoord2 #define cogl_tex_coord3_in gl_MultiTexCoord3 #define cogl_tex_coord4_in gl_MultiTexCoord4 #define cogl_tex_coord5_in gl_MultiTexCoord5 #define cogl_tex_coord6_in gl_MultiTexCoord6 #define cogl_tex_coord7_in gl_MultiTexCoord7 #define cogl_normal_in gl_Normal #define cogl_position_out gl_Position #define cogl_point_size_out gl_PointSize #define cogl_color_out gl_FrontColor #define cogl_tex_coord_out gl_TexCoord #define cogl_modelview_matrix gl_ModelViewMatrix #define cogl_modelview_projection_matrix gl_ModelViewProjectionMatrix #define cogl_projection_matrix gl_ProjectionMatrix #define cogl_texture_matrix gl_TextureMatrix And for fragment shaders we have: #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_TexCoord #define cogl_color_out gl_FragColor #define cogl_depth_out gl_FragDepth #define cogl_front_facing gl_FrontFacing
2010-07-23 12:46:41 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
priv->glsl_shader_state->unit_state[i].sampled = FALSE;
priv->glsl_shader_state->unit_state[i].combine_constant_used = FALSE;
cogl-shader: Prepend boilerplate for portable shaders We now prepend a set of defines to any given GLSL shader so that we can define builtin uniforms/attributes within the "cogl" namespace that we can use to provide compatibility across a range of the earlier versions of GLSL. This updates test-cogl-shader-glsl.c and test-shader.c so they no longer needs to special case GLES vs GL when splicing together its shaders as well as the blur, colorize and desaturate effects. To get a feel for the new, portable uniform/attribute names here are the defines for OpenGL vertex shaders: #define cogl_position_in gl_Vertex #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_MultiTexCoord0 #define cogl_tex_coord0_in gl_MultiTexCoord0 #define cogl_tex_coord1_in gl_MultiTexCoord1 #define cogl_tex_coord2_in gl_MultiTexCoord2 #define cogl_tex_coord3_in gl_MultiTexCoord3 #define cogl_tex_coord4_in gl_MultiTexCoord4 #define cogl_tex_coord5_in gl_MultiTexCoord5 #define cogl_tex_coord6_in gl_MultiTexCoord6 #define cogl_tex_coord7_in gl_MultiTexCoord7 #define cogl_normal_in gl_Normal #define cogl_position_out gl_Position #define cogl_point_size_out gl_PointSize #define cogl_color_out gl_FrontColor #define cogl_tex_coord_out gl_TexCoord #define cogl_modelview_matrix gl_ModelViewMatrix #define cogl_modelview_projection_matrix gl_ModelViewProjectionMatrix #define cogl_projection_matrix gl_ProjectionMatrix #define cogl_texture_matrix gl_TextureMatrix And for fragment shaders we have: #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_TexCoord #define cogl_color_out gl_FragColor #define cogl_depth_out gl_FragDepth #define cogl_front_facing gl_FrontFacing
2010-07-23 12:46:41 -04:00
}
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
return TRUE;
}
static void
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_constant_lookup (GlslShaderState *glsl_shader_state,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
CoglPipeline *pipeline,
CoglPipelineLayer *layer,
const char *swizzle)
{
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
/* Create a sampler uniform for this layer if we haven't already */
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (!glsl_shader_state->unit_state[unit_index].combine_constant_used)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->header,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
"uniform vec4 _cogl_layer_constant_%i;\n",
unit_index);
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
glsl_shader_state->unit_state[unit_index].combine_constant_used = TRUE;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
}
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->source,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
"_cogl_layer_constant_%i.%s",
unit_index, swizzle);
}
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
static void
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_texture_lookup (GlslShaderState *glsl_shader_state,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
CoglPipeline *pipeline,
CoglPipelineLayer *layer,
const char *swizzle)
{
CoglHandle texture;
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
const char *target_string, *tex_coord_swizzle;
texture = _cogl_pipeline_layer_get_texture (layer);
cogl-shader: Prepend boilerplate for portable shaders We now prepend a set of defines to any given GLSL shader so that we can define builtin uniforms/attributes within the "cogl" namespace that we can use to provide compatibility across a range of the earlier versions of GLSL. This updates test-cogl-shader-glsl.c and test-shader.c so they no longer needs to special case GLES vs GL when splicing together its shaders as well as the blur, colorize and desaturate effects. To get a feel for the new, portable uniform/attribute names here are the defines for OpenGL vertex shaders: #define cogl_position_in gl_Vertex #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_MultiTexCoord0 #define cogl_tex_coord0_in gl_MultiTexCoord0 #define cogl_tex_coord1_in gl_MultiTexCoord1 #define cogl_tex_coord2_in gl_MultiTexCoord2 #define cogl_tex_coord3_in gl_MultiTexCoord3 #define cogl_tex_coord4_in gl_MultiTexCoord4 #define cogl_tex_coord5_in gl_MultiTexCoord5 #define cogl_tex_coord6_in gl_MultiTexCoord6 #define cogl_tex_coord7_in gl_MultiTexCoord7 #define cogl_normal_in gl_Normal #define cogl_position_out gl_Position #define cogl_point_size_out gl_PointSize #define cogl_color_out gl_FrontColor #define cogl_tex_coord_out gl_TexCoord #define cogl_modelview_matrix gl_ModelViewMatrix #define cogl_modelview_projection_matrix gl_ModelViewProjectionMatrix #define cogl_projection_matrix gl_ProjectionMatrix #define cogl_texture_matrix gl_TextureMatrix And for fragment shaders we have: #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_TexCoord #define cogl_color_out gl_FragColor #define cogl_depth_out gl_FragDepth #define cogl_front_facing gl_FrontFacing
2010-07-23 12:46:41 -04:00
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
if (texture == COGL_INVALID_HANDLE)
{
target_string = "2D";
tex_coord_swizzle = "st";
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
else
{
GLenum gl_target;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl_texture_get_gl_texture (texture, NULL, &gl_target);
switch (gl_target)
{
#ifndef HAVE_COGL_GLES2
case GL_TEXTURE_1D:
target_string = "1D";
tex_coord_swizzle = "s";
break;
#endif
case GL_TEXTURE_2D:
target_string = "2D";
tex_coord_swizzle = "st";
break;
#ifdef GL_ARB_texture_rectangle
case GL_TEXTURE_RECTANGLE_ARB:
target_string = "2DRect";
tex_coord_swizzle = "st";
break;
cogl-shader: Prepend boilerplate for portable shaders We now prepend a set of defines to any given GLSL shader so that we can define builtin uniforms/attributes within the "cogl" namespace that we can use to provide compatibility across a range of the earlier versions of GLSL. This updates test-cogl-shader-glsl.c and test-shader.c so they no longer needs to special case GLES vs GL when splicing together its shaders as well as the blur, colorize and desaturate effects. To get a feel for the new, portable uniform/attribute names here are the defines for OpenGL vertex shaders: #define cogl_position_in gl_Vertex #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_MultiTexCoord0 #define cogl_tex_coord0_in gl_MultiTexCoord0 #define cogl_tex_coord1_in gl_MultiTexCoord1 #define cogl_tex_coord2_in gl_MultiTexCoord2 #define cogl_tex_coord3_in gl_MultiTexCoord3 #define cogl_tex_coord4_in gl_MultiTexCoord4 #define cogl_tex_coord5_in gl_MultiTexCoord5 #define cogl_tex_coord6_in gl_MultiTexCoord6 #define cogl_tex_coord7_in gl_MultiTexCoord7 #define cogl_normal_in gl_Normal #define cogl_position_out gl_Position #define cogl_point_size_out gl_PointSize #define cogl_color_out gl_FrontColor #define cogl_tex_coord_out gl_TexCoord #define cogl_modelview_matrix gl_ModelViewMatrix #define cogl_modelview_projection_matrix gl_ModelViewProjectionMatrix #define cogl_projection_matrix gl_ProjectionMatrix #define cogl_texture_matrix gl_TextureMatrix And for fragment shaders we have: #define cogl_color_in gl_Color #define cogl_tex_coord_in gl_TexCoord #define cogl_color_out gl_FragColor #define cogl_depth_out gl_FragDepth #define cogl_front_facing gl_FrontFacing
2010-07-23 12:46:41 -04:00
#endif
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
case GL_TEXTURE_3D:
target_string = "3D";
tex_coord_swizzle = "stp";
break;
default:
g_assert_not_reached ();
}
}
/* Create a sampler uniform for this layer if we haven't already */
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (!glsl_shader_state->unit_state[unit_index].sampled)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->header,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
"uniform sampler%s _cogl_sampler_%i;\n",
target_string,
unit_index);
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
glsl_shader_state->unit_state[unit_index].sampled = TRUE;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->source,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
"texture%s (_cogl_sampler_%i, ",
target_string, unit_index);
/* If point sprite coord generation is being used then divert to the
built-in varying var for that instead of the texture
cogl-pipeline-glsl: Don't use gl_PointCoord on OpenGL We don't want to use gl_PointCoord to implement point sprites on big GL because in that case we already use glTexEnv(GL_COORD_REPLACE) to replace the texture coords with the point sprite coords. Although GL also supports the gl_PointCoord variable, it requires GLSL 1.2 which would mean we would have to declare the GLSL version and check for it. We continue to use gl_PointCoord for GLES2 because it has no glTexEnv function.
2010-11-24 10:30:56 -05:00
coordinates. We don't want to do this under GL because in that
case we will instead use glTexEnv(GL_COORD_REPLACE) to replace
the texture coords with the point sprite coords. Although GL also
supports the gl_PointCoord variable, it requires GLSL 1.2 which
would mean we would have to declare the GLSL version and check
for it */
#ifdef HAVE_COGL_GLES2
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
if (cogl_pipeline_get_layer_point_sprite_coords_enabled (pipeline,
layer->index))
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->source,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
"gl_PointCoord.%s",
tex_coord_swizzle);
else
cogl-pipeline-glsl: Don't use gl_PointCoord on OpenGL We don't want to use gl_PointCoord to implement point sprites on big GL because in that case we already use glTexEnv(GL_COORD_REPLACE) to replace the texture coords with the point sprite coords. Although GL also supports the gl_PointCoord variable, it requires GLSL 1.2 which would mean we would have to declare the GLSL version and check for it. We continue to use gl_PointCoord for GLES2 because it has no glTexEnv function.
2010-11-24 10:30:56 -05:00
#endif
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->source,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
"cogl_tex_coord_in[%d].%s",
unit_index, tex_coord_swizzle);
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->source, ").%s", swizzle);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
}
typedef struct
{
int unit_index;
CoglPipelineLayer *layer;
} FindPipelineLayerData;
static gboolean
find_pipeline_layer_cb (CoglPipelineLayer *layer,
void *user_data)
{
FindPipelineLayerData *data = user_data;
int unit_index;
unit_index = _cogl_pipeline_layer_get_unit_index (layer);
if (unit_index == data->unit_index)
{
data->layer = layer;
return FALSE;
}
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
cogl: Allow setting ARBfp source on a CoglShader This makes CoglProgram/Shader automatically detect when the user has given an ARBfp program by checking for "!!ARBfp1.0" at the beginning of the user's source. ARBfp local parameters can be set with cogl_program_uniform_float assuming you pass a @size of 4 (all ARBfp program.local parameters are vectors of 4 floats). This doesn't expose ARBfp environment parameters or double precision local parameters.
2010-08-04 12:53:51 -04:00
return TRUE;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
}
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
static void
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (GlslShaderState *glsl_shader_state,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
CoglPipeline *pipeline,
CoglPipelineLayer *layer,
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
CoglPipelineCombineSource src,
CoglPipelineCombineOp operand,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
const char *swizzle)
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GString *shader_source = glsl_shader_state->source;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
char alpha_swizzle[5] = "aaaa";
g_string_append_c (shader_source, '(');
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
if (operand == COGL_PIPELINE_COMBINE_OP_ONE_MINUS_SRC_COLOR ||
operand == COGL_PIPELINE_COMBINE_OP_ONE_MINUS_SRC_ALPHA)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
g_string_append_printf (shader_source,
"vec4(1.0, 1.0, 1.0, 1.0).%s - ",
swizzle);
/* If the operand is reading from the alpha then replace the swizzle
with the same number of copies of the alpha */
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
if (operand == COGL_PIPELINE_COMBINE_OP_SRC_ALPHA ||
operand == COGL_PIPELINE_COMBINE_OP_ONE_MINUS_SRC_ALPHA)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
{
alpha_swizzle[strlen (swizzle)] = '\0';
swizzle = alpha_swizzle;
}
switch (src)
{
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_SOURCE_TEXTURE:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_texture_lookup (glsl_shader_state,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
pipeline,
layer,
swizzle);
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_SOURCE_CONSTANT:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_constant_lookup (glsl_shader_state,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
pipeline,
layer,
swizzle);
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_SOURCE_PREVIOUS:
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
if (_cogl_pipeline_layer_get_unit_index (layer) > 0)
{
g_string_append_printf (shader_source, "cogl_color_out.%s", swizzle);
break;
}
/* flow through */
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_SOURCE_PRIMARY_COLOR:
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
g_string_append_printf (shader_source, "cogl_color_in.%s", swizzle);
break;
default:
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
if (src >= COGL_PIPELINE_COMBINE_SOURCE_TEXTURE0 &&
src < COGL_PIPELINE_COMBINE_SOURCE_TEXTURE0 + 32)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
{
FindPipelineLayerData data;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
data.unit_index = src - COGL_PIPELINE_COMBINE_SOURCE_TEXTURE0;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
data.layer = layer;
_cogl_pipeline_foreach_layer_internal (pipeline,
find_pipeline_layer_cb,
&data);
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_texture_lookup (glsl_shader_state,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
pipeline,
data.layer,
swizzle);
}
break;
}
g_string_append_c (shader_source, ')');
}
static void
append_masked_combine (CoglPipeline *pipeline,
CoglPipelineLayer *layer,
const char *swizzle,
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
CoglPipelineCombineFunc function,
CoglPipelineCombineSource *src,
CoglPipelineCombineOp *op)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *glsl_shader_state = get_glsl_shader_state (pipeline);
GString *shader_source = glsl_shader_state->source;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append_printf (glsl_shader_state->source,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
" cogl_color_out.%s = ", swizzle);
switch (function)
{
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_FUNC_REPLACE:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], swizzle);
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_FUNC_MODULATE:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], swizzle);
g_string_append (shader_source, " * ");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], swizzle);
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_FUNC_ADD:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], swizzle);
g_string_append (shader_source, " + ");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], swizzle);
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_FUNC_ADD_SIGNED:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], swizzle);
g_string_append (shader_source, " + ");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], swizzle);
g_string_append_printf (shader_source,
" - vec4(0.5, 0.5, 0.5, 0.5).%s",
swizzle);
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_FUNC_SUBTRACT:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], swizzle);
g_string_append (shader_source, " - ");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], swizzle);
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_FUNC_INTERPOLATE:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], swizzle);
g_string_append (shader_source, " * ");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[2], op[2], swizzle);
g_string_append (shader_source, " + ");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], swizzle);
g_string_append_printf (shader_source,
" * (vec4(1.0, 1.0, 1.0, 1.0).%s - ",
swizzle);
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[2], op[2], swizzle);
g_string_append_c (shader_source, ')');
break;
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
case COGL_PIPELINE_COMBINE_FUNC_DOT3_RGB:
case COGL_PIPELINE_COMBINE_FUNC_DOT3_RGBA:
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
g_string_append (shader_source, "vec4(4.0 * ((");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], "r");
g_string_append (shader_source, " - 0.5) * (");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], "r");
g_string_append (shader_source, " - 0.5) + (");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], "g");
g_string_append (shader_source, " - 0.5) * (");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], "g");
g_string_append (shader_source, " - 0.5) + (");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[0], op[0], "b");
g_string_append (shader_source, " - 0.5) * (");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_arg (glsl_shader_state, pipeline, layer,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
src[1], op[1], "b");
g_string_append_printf (shader_source, " - 0.5))).%s", swizzle);
break;
}
g_string_append_printf (shader_source, ";\n");
}
static gboolean
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_add_layer (CoglPipeline *pipeline,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
CoglPipelineLayer *layer,
unsigned long layers_difference)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *glsl_shader_state = get_glsl_shader_state (pipeline);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
CoglPipelineLayer *combine_authority =
_cogl_pipeline_layer_get_authority (layer,
COGL_PIPELINE_LAYER_STATE_COMBINE);
CoglPipelineLayerBigState *big_state = combine_authority->big_state;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (!glsl_shader_state->source)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
return TRUE;
if (!_cogl_pipeline_need_texture_combine_separate (combine_authority) ||
/* GL_DOT3_RGBA Is a bit weird as a GL_COMBINE_RGB function
* since if you use it, it overrides your ALPHA function...
*/
cogl-pipeline: Use enums for the layer combine values Once the GLES2 wrapper is removed then we won't have the GLenums needed for setting up the layer combine state. This adds Cogl enums instead which have the same values as the corresponding GLenums. The enums are: CoglPipelineCombineFunc CoglPipelineCombineSource and CoglPipelineCombineOp
2010-12-06 16:29:56 -05:00
big_state->texture_combine_rgb_func ==
COGL_PIPELINE_COMBINE_FUNC_DOT3_RGBA)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
append_masked_combine (pipeline,
layer,
"rgba",
big_state->texture_combine_rgb_func,
big_state->texture_combine_rgb_src,
big_state->texture_combine_rgb_op);
else
{
append_masked_combine (pipeline,
layer,
"rgb",
big_state->texture_combine_rgb_func,
big_state->texture_combine_rgb_src,
big_state->texture_combine_rgb_op);
append_masked_combine (pipeline,
layer,
"a",
big_state->texture_combine_alpha_func,
big_state->texture_combine_alpha_src,
big_state->texture_combine_alpha_op);
}
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
return TRUE;
}
gboolean
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_passthrough (CoglPipeline *pipeline)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *glsl_shader_state = get_glsl_shader_state (pipeline);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (!glsl_shader_state->source)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
return TRUE;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source,
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
" cogl_color_out = cogl_color_in;\n");
return TRUE;
}
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
/* GLES2 doesn't have alpha testing so we need to implement it in the
shader */
#ifdef HAVE_COGL_GLES2
static void
add_alpha_test_snippet (CoglPipeline *pipeline,
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *glsl_shader_state)
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
{
CoglPipelineAlphaFunc alpha_func;
alpha_func = cogl_pipeline_get_alpha_test_function (pipeline);
if (alpha_func == COGL_PIPELINE_ALPHA_FUNC_ALWAYS)
/* Do nothing */
return;
if (alpha_func == COGL_PIPELINE_ALPHA_FUNC_NEVER)
{
/* Always discard the fragment */
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source,
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
" discard;\n");
return;
}
/* For all of the other alpha functions we need a uniform for the
reference */
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->header,
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
"uniform float _cogl_alpha_test_ref;\n");
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source,
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
" if (cogl_color_out.a ");
switch (alpha_func)
{
case COGL_PIPELINE_ALPHA_FUNC_LESS:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source, ">=");
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
break;
case COGL_PIPELINE_ALPHA_FUNC_EQUAL:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source, "!=");
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
break;
case COGL_PIPELINE_ALPHA_FUNC_LEQUAL:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source, ">");
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
break;
case COGL_PIPELINE_ALPHA_FUNC_GREATER:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source, "<=");
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
break;
case COGL_PIPELINE_ALPHA_FUNC_NOTEQUAL:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source, "==");
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
break;
case COGL_PIPELINE_ALPHA_FUNC_GEQUAL:
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source, "< ");
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
break;
case COGL_PIPELINE_ALPHA_FUNC_ALWAYS:
case COGL_PIPELINE_ALPHA_FUNC_NEVER:
g_assert_not_reached ();
break;
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source,
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
" _cogl_alpha_test_ref)\n discard;\n");
}
#endif /* HAVE_COGL_GLES2 */
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
gboolean
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_end (CoglPipeline *pipeline,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
unsigned long pipelines_difference)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GlslShaderState *glsl_shader_state = get_glsl_shader_state (pipeline);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
_COGL_GET_CONTEXT (ctx, FALSE);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (glsl_shader_state->source)
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
const char *source_strings[2];
GLint lengths[2];
GLint compile_status;
GLuint shader;
int n_tex_coord_attribs = 0;
int i, n_layers;
COGL_STATIC_COUNTER (fragend_glsl_compile_counter,
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
"glsl fragment compile counter",
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
"Increments each time a new GLSL "
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
"fragment shader is compiled",
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
0 /* no application private data */);
COGL_COUNTER_INC (_cogl_uprof_context, fragend_glsl_compile_counter);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
#ifdef HAVE_COGL_GLES2
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
add_alpha_test_snippet (pipeline, glsl_shader_state);
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
#endif
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
g_string_append (glsl_shader_state->source, "}\n");
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GE_RET( shader, glCreateShader (GL_FRAGMENT_SHADER) );
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
lengths[0] = glsl_shader_state->header->len;
source_strings[0] = glsl_shader_state->header->str;
lengths[1] = glsl_shader_state->source->len;
source_strings[1] = glsl_shader_state->source->str;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
/* Find the highest texture unit that is sampled to pass as the
number of texture coordinate attributes */
n_layers = cogl_pipeline_get_n_layers (pipeline);
for (i = 0; i < n_layers; i++)
if (glsl_shader_state->unit_state[i].sampled)
n_tex_coord_attribs = i + 1;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
_cogl_shader_set_source_with_boilerplate (shader, GL_FRAGMENT_SHADER,
n_tex_coord_attribs,
2, /* count */
source_strings, lengths);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GE( glCompileShader (shader) );
GE( glGetShaderiv (shader, GL_COMPILE_STATUS, &compile_status) );
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (!compile_status)
{
GLint len = 0;
char *shader_log;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
GE( glGetShaderiv (shader, GL_INFO_LOG_LENGTH, &len) );
shader_log = g_alloca (len);
GE( glGetShaderInfoLog (shader, len, &len, shader_log) );
g_warning ("Shader compilation failed:\n%s", shader_log);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
}
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
glsl_shader_state->header = NULL;
glsl_shader_state->source = NULL;
glsl_shader_state->gl_shader = shader;
cogl-pipeline-glsl: Generate the alpha test snippet under GLES2 GLES2 has no glAlphaFunc function so we need to simulate the behaviour in the fragment shader. The alpha test function is simulated with an if-statement and a discard statement. The reference value is stored as a uniform.
2010-11-22 13:33:49 -05:00
}
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
return TRUE;
}
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
static void
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_pre_change_notify (CoglPipeline *pipeline,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipelineState change,
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
const CoglColor *new_color)
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if ((change & COGL_PIPELINE_STATE_AFFECTS_FRAGMENT_CODEGEN))
dirty_glsl_shader_state (pipeline);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
/* NB: layers are considered immutable once they have any dependants
* so although multiple pipelines can end up depending on a single
* static layer, we can guarantee that if a layer is being *changed*
* then it can only have one pipeline depending on it.
*
* XXX: Don't forget this is *pre* change, we can't read the new value
* yet!
*/
static void
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_layer_pre_change_notify (
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
CoglPipeline *owner,
CoglPipelineLayer *layer,
CoglPipelineLayerState change)
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendGlslPrivate *priv;
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
priv = get_glsl_priv (owner);
if (!priv)
return;
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if ((change & COGL_PIPELINE_LAYER_STATE_AFFECTS_FRAGMENT_CODEGEN))
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
dirty_glsl_shader_state (owner);
Generate GLSL in the CoglPipeline GLSL backend The GLSL pipeline backend can now generate code to represent the pipeline state in a similar way to the ARBfp backend. Most of the code for this is taken from the GLES 2 wrapper.
2010-11-19 05:44:27 -05:00
return;
}
/* TODO: we could be saving snippets of texture combine code along
* with each layer and then when a layer changes we would just free
* the snippet. */
}
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
static void
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_free_priv (CoglPipeline *pipeline)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendGlslPrivate *priv = get_glsl_priv (pipeline);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
if (priv)
{
cogl: Add a GLSL 'progend' 'progend' is short for 'program backend'. The progend is intended to operate on combined state from a fragment backend and a vertex backend. The progend has an 'end' function which is run whenever the pipeline is flushed and the two pipeline change notification functions. All of the progends are run whenever the pipeline is flushed instead of selecting a single one because it is possible that multiple progends may be in use for example if the vertends and fragends are different. The GLSL progend will take the shaders generated by the fragend and vertend and link them into a single program. The fragend code has been changed to only generate the shader and not the program. The idea is that pipelines can share fragment shader objects even if their vertex state is different. The authority for the progend needs to be the combined authority on the vertend and fragend state.
2010-12-02 09:00:46 -05:00
if (priv->glsl_shader_state)
glsl_shader_state_unref (priv->glsl_shader_state);
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
g_slice_free (CoglPipelineFragendGlslPrivate, priv);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
set_glsl_priv (pipeline, NULL);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
}
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
const CoglPipelineFragend _cogl_pipeline_glsl_fragend =
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_start,
_cogl_pipeline_fragend_glsl_add_layer,
_cogl_pipeline_fragend_glsl_passthrough,
_cogl_pipeline_fragend_glsl_end,
_cogl_pipeline_fragend_glsl_pre_change_notify,
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
NULL, /* pipeline_set_parent_notify */
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
_cogl_pipeline_fragend_glsl_layer_pre_change_notify,
_cogl_pipeline_fragend_glsl_free_priv,
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
};
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#endif /* COGL_PIPELINE_FRAGEND_GLSL */
build: Fix GLES builds since the material backend split The commit to split the fragment processing backends out from cogl-material.c (3e1323a6362906a95) broke the GLES 1 and 2 builds the fix was to guard the code in each backend according to the COGL_MATERIAL_BACKEND_XYZ defines which are setup in cogl-material-private.h.
2010-07-01 20:07:36 -04:00
Reference in New Issue Copy Permalink