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
89731d160e
mutter/cogl/cogl-pipeline-fragend-arbfp.c

975 lines
32 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>
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
cogl: don't include cogl-debug.h in cogl.h or install cogl-debug.h is an internal header so it shouldn't have been included by cogl.h and the header shouldn't be installed either.
2010-07-25 16:36:41 -04:00
#include "cogl-debug.h"
cogl-pipeline/cogl-pango: Added forgotten includes It seems that cogl-context-private.h needs to be included before including any of the pipeline-related stuff to avoid build errors on C89 compilers. This is due to the recent cogl-pipeline decoupling, seems like. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-23 04:43:05 -04:00
#include "cogl-context-private.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"
pipeline: Split more code out from cogl-pipeline.c This splits out the core CoglPipelineLayer support code from cogl-pipeline.c into cogl-pipeline-layer.c; it splits out the debugging code for dumping a pipeline to a .dot file into cogl-pipeline-debug.c and it splits the CoglPipelineNode support which is shared between CoglPipeline and CoglPipelineLayer into cogl-node.c. Note: cogl-pipeline-layer.c only contains the layer code directly relating to CoglPipelineLayer objects; it does not contain any _cogl_pipeline API relating to how CoglPipeline tracks and manipulates layers.
2011-09-08 19:40:06 -04:00
#include "cogl-pipeline-layer-private.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_ARBFP
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"
cogl: rename cogl-context.h cogl-context-private.h Since we plan to add public cogl_context_* API we need to rename the current cogl-context.h which contains private member details.
2010-11-04 18:25:52 -04:00
#include "cogl-context-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
#include "cogl-handle.h"
#include "cogl-texture-private.h"
#include "cogl-blend-string.h"
#include "cogl-journal-private.h"
#include "cogl-color-private.h"
#include "cogl-profile.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
#include <glib.h>
#include <glib/gprintf.h>
#include <string.h>
Add a Cogl texture 3D backend This adds a publicly exposed experimental API for a 3D texture backend. There is a feature flag which can be checked for whether 3D textures are supported. Although we require OpenGL 1.2 which has 3D textures in core, GLES only provides them through an extension so the feature can be used to detect that. The textures can be created with one of two new API functions :- cogl_texture_3d_new_with_size and cogl_texture_3d_new_from_data There is also internally a new_from_bitmap function. new_from_data is implemented in terms of this function. The two constructors are effectively the only way to upload data to a 3D texture. It does not work to call glTexImage2D with the GL_TEXTURE_3D target so the virtual for cogl_texture_set_region does nothing. It would be possible to make cogl_texture_get_data do something sensible like returning all of the images as a single long image but this is not currently implemented and instead the virtual just always fails. We may want to add API specific to the 3D texture backend to get and set a sub region of the texture. All of those three functions can throw a GError. This will happen if the GPU does not support 3D textures or it does not support NPOTs and an NPOT size is requested. It will also fail if the FBO extension is not supported and the COGL_TEXTURE_NO_AUTO_MIPMAP flag is not given. This could be avoided by copying the code for the GL_GENERATE_MIPMAP TexParameter fallback, but in the interests of keeping the code simple this is not yet done. This adds a couple of functions to cogl-texture-driver for uploading 3D data and querying the 3D proxy texture. prep_gl_for_pixels_upload_full now also takes sets the GL_UNPACK_IMAGE_HEIGHT parameter so that 3D textures can have padding between the images. Whenever 3D texture is uploading, both the height of the images and the height of all of the data is specified (either explicitly or implicilty from the CoglBitmap) so that the image height can be deduced by dividing by the depth.
2010-07-01 17:04:59 -04:00
/* This might not be defined on GLES */
#ifndef GL_TEXTURE_3D
#define GL_TEXTURE_3D 0x806F
#endif
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
const CoglPipelineFragend _cogl_pipeline_arbfp_fragend;
material: track unit state with arbfp private state We are going to start tracking more per-texture unit state with arbfp private state so this adds an internal UnitState type and we allocate an array of these when setting up a new private state structure. The first thing that has been moved into this is the sampled boolean to know when a particular texture unit gets sampled from in the generated arbfp code.
2010-09-13 16:17:30 -04:00
typedef struct _UnitState
{
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
int constant_id; /* The program.local[] index */
unsigned int dirty_combine_constant:1;
arbfp: track which layers have combine constants We weren't actually tracking which layers have been allocated param space for combine constants; all layers just had a default constant_id of 0 that indexes into the program.local[] params array and a dirty flag to say when the constant needs updating. There are times though when we say to update everything by-passing the dirty flag and because we weren't actually tracking which layers needed constants we would always write a constant to program.local[0] for every layer. The upshot was that we could end up clobbering a real constant that was actually allocated the constant_id = 0 slot. This patch adds a new UnitState bitfield to track if the layer has a corresponding constant that may need flushing and we only ever write the constant with glProgramLocalParameter4fv if that's set. https://bugzilla.gnome.org/show_bug.cgi?id=658092 Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-09-08 18:08:43 -04:00
unsigned int has_combine_constant:1;
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
material: track unit state with arbfp private state We are going to start tracking more per-texture unit state with arbfp private state so this adds an internal UnitState type and we allocate an array of these when setting up a new private state structure. The first thing that has been moved into this is the sampled boolean to know when a particular texture unit gets sampled from in the generated arbfp code.
2010-09-13 16:17:30 -04:00
unsigned int sampled:1;
} UnitState;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
typedef struct
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
{
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
int ref_count;
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: 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
CoglHandle user_program;
arbfp: Copy pipelines used as cache keys We are currently using a pipeline as a key into our arbfp program cache but because we weren't making a copy of the pipelines used as keys there were times when doing a lookup in the cache would end up trying to compare a lookup key with an entry key that would point to invalid memory. Note: the current approach isn't ideal from the pov that that key pipeline may reference some arbitrarily large user textures will now be kept alive indefinitely. The plan to improve on this is that we will have a mechanism to create a special "key pipeline" which will derive from the default Cogl pipeline (to avoid affecting the lifetime of other pipelines) and only copy state from the original pipeline that affects the arbfp program and will reference small dummy textures instead of potentially large user textures.
2010-12-08 11:29:37 -05:00
/* XXX: only valid during codegen */
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
GString *source;
GLuint gl_program;
material: track unit state with arbfp private state We are going to start tracking more per-texture unit state with arbfp private state so this adds an internal UnitState type and we allocate an array of these when setting up a new private state structure. The first thing that has been moved into this is the sampled boolean to know when a particular texture unit gets sampled from in the generated arbfp code.
2010-09-13 16:17:30 -04:00
UnitState *unit_state;
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 next_constant_id;
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -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
/* Age of the program the last time the uniforms were flushed. This
is used to detect when we need to flush all of the uniforms */
unsigned int user_program_age;
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
/* We need to track the last pipeline that an ARBfp program was used
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
* with so know if we need to update any program.local parameters. */
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 *last_used_for_pipeline;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
} CoglPipelineShaderState;
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
static CoglUserDataKey shader_state_key;
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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
static CoglPipelineShaderState *
shader_state_new (int n_layers)
{
CoglPipelineShaderState *shader_state;
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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = g_slice_new0 (CoglPipelineShaderState);
shader_state->ref_count = 1;
shader_state->unit_state = g_new0 (UnitState, n_layers);
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
return shader_state;
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
}
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
static CoglPipelineShaderState *
get_shader_state (CoglPipeline *pipeline)
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
return cogl_object_get_user_data (COGL_OBJECT (pipeline), &shader_state_key);
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
}
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
static void
pipeline: Reset last_used_for_pipeline when the pipeline is destroyed Both the GLSL and the ARBfp pipeline backends were using a variable called last_used_for_pipeline to keep track of the last pipeline that the shader or program state was used for. If this address is the same as last time when the pipeline state is flushed then Cogl will only flush the uniforms that have been modified, otherwise it will flush all of them. The problem with this is that there was nothing to keep that address alive so it could be destroyed and reused for a different pipeline by the time the shader state is reused. This is quite likely to happen in an application using legacy state because in that case the shader state will always be used with a one-shot pipeline that will likely be recycled in the next frame. There is already a destroy callback to unref the shader state when the pipeline is destroyed so this patch just makes that callback also clear the last_used_for_pipeline pointer if it matches the pipeline being destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=662542 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-10-23 15:22:23 -04:00
destroy_shader_state (void *user_data,
void *instance)
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = user_data;
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
pipeline: Reset last_used_for_pipeline when the pipeline is destroyed Both the GLSL and the ARBfp pipeline backends were using a variable called last_used_for_pipeline to keep track of the last pipeline that the shader or program state was used for. If this address is the same as last time when the pipeline state is flushed then Cogl will only flush the uniforms that have been modified, otherwise it will flush all of them. The problem with this is that there was nothing to keep that address alive so it could be destroyed and reused for a different pipeline by the time the shader state is reused. This is quite likely to happen in an application using legacy state because in that case the shader state will always be used with a one-shot pipeline that will likely be recycled in the next frame. There is already a destroy callback to unref the shader state when the pipeline is destroyed so this patch just makes that callback also clear the last_used_for_pipeline pointer if it matches the pipeline being destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=662542 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-10-23 15:22:23 -04:00
/* If the shader state was last used for this pipeline then clear it
so that if same address gets used again for a new pipeline then
we won't think it's the same pipeline and avoid updating the
constants */
if (shader_state->last_used_for_pipeline == instance)
shader_state->last_used_for_pipeline = NULL;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (--shader_state->ref_count == 0)
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state->gl_program)
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
GE (ctx, glDeletePrograms (1, &shader_state->gl_program));
shader_state->gl_program = 0;
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
}
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_free (shader_state->unit_state);
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_slice_free (CoglPipelineShaderState, shader_state);
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
}
}
material-arbfp: fixes for how we track private state This fixes a number of issues relating to how we track the arbfp private state associated with CoglMaterials. At the same time it adds much more extensive code documentation to try and make it a bit more approachable.
2010-09-13 18:52:18 -04:00
static void
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
set_shader_state (CoglPipeline *pipeline, CoglPipelineShaderState *shader_state)
material-arbfp: fixes for how we track private state This fixes a number of issues relating to how we track the arbfp private state associated with CoglMaterials. At the same time it adds much more extensive code documentation to try and make it a bit more approachable.
2010-09-13 18:52:18 -04:00
{
pipeline: Reset last_used_for_pipeline when the pipeline is destroyed Both the GLSL and the ARBfp pipeline backends were using a variable called last_used_for_pipeline to keep track of the last pipeline that the shader or program state was used for. If this address is the same as last time when the pipeline state is flushed then Cogl will only flush the uniforms that have been modified, otherwise it will flush all of them. The problem with this is that there was nothing to keep that address alive so it could be destroyed and reused for a different pipeline by the time the shader state is reused. This is quite likely to happen in an application using legacy state because in that case the shader state will always be used with a one-shot pipeline that will likely be recycled in the next frame. There is already a destroy callback to unref the shader state when the pipeline is destroyed so this patch just makes that callback also clear the last_used_for_pipeline pointer if it matches the pipeline being destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=662542 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-10-23 15:22:23 -04:00
_cogl_object_set_user_data (COGL_OBJECT (pipeline),
&shader_state_key,
shader_state,
destroy_shader_state);
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
}
material-arbfp: fixes for how we track private state This fixes a number of issues relating to how we track the arbfp private state associated with CoglMaterials. At the same time it adds much more extensive code documentation to try and make it a bit more approachable.
2010-09-13 18:52:18 -04:00
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
static void
dirty_shader_state (CoglPipeline *pipeline)
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
cogl_object_set_user_data (COGL_OBJECT (pipeline),
&shader_state_key,
NULL,
NULL);
material-arbfp: fixes for how we track private state This fixes a number of issues relating to how we track the arbfp private state associated with CoglMaterials. At the same time it adds much more extensive code documentation to try and make it a bit more approachable.
2010-09-13 18:52:18 -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_arbfp_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
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state;
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;
cogl-pipeline-fragend-arbfp: Initialise template_pipeline The template_pipeline variable in _cogl_pipeline_fragend_arbfp_start was not being initialised if the program caches are disabled with COGL_DEBUG=disable-program-caches so it would crash. The other backends have a similar variable but they already initialise it. https://bugzilla.gnome.org/show_bug.cgi?id=655400
2011-07-26 12:33:27 -04:00
CoglPipeline *template_pipeline = NULL;
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
CoglHandle user_program;
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);
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
/* First validate that we can handle the current state using ARBfp
*/
features: Support more than 32 features! Currently features are represented as bits in a 32bit mask so we obviously can't have more than 32 features with that approach. The new approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks without a size limit and we change the public api to accept individual feature enums instead of a mask. This way there is no limit on the number of features we can add to Cogl. Instead of using cogl_features_available() there is a new cogl_has_feature() function and for checking multiple features there is cogl_has_features() which takes a zero terminated vararg list of features. In addition to being able to check for individual features this also adds a way to query all the features currently available via cogl_foreach_feature() which will call a callback for each feature. Since the new functions take an explicit context pointer there is also no longer any ambiguity over when users can first start to query features. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-12 17:31:12 -04:00
if (!cogl_has_feature (ctx, COGL_FEATURE_ID_ARBFP))
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 FALSE;
/* TODO: support fog */
pipeline-arbfp: Check for fog on the pipeline not the legacy state The ARBfp backend can't handle fog so it tries to check for when it's enabled and bails out. However it was checking using the global legacy state value on the CoglContext but this doesn't necessarily reflect the state that will actually be used by the pipeline because Cogl may have internally pushed a different pipeline. This patch adds an internal _cogl_pipeline_get_fog_enabled which the ARBfp backend now uses. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-14 10:25:58 -04:00
if (_cogl_pipeline_get_fog_enabled (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
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-pipeline-fragend-arbfp: Generate ARBfp if user vertex shader The ARBfp fragend was bypassing generating a shader if the pipeline contains a user program. However it shouldn't do this if the pipeline only contains a vertex shader. This was breaking test-cogl-just-vertex-shader.
2010-12-14 08:02:47 -05:00
if (user_program != COGL_INVALID_HANDLE)
{
/* If the program doesn't have a fragment shader then some other
vertend will handle the vertex shader state and we still need
to generate a fragment program */
if (!_cogl_program_has_fragment_shader (user_program))
user_program = COGL_INVALID_HANDLE;
/* If the user program does have a fragment shader then we can
only handle it if it's in ARBfp */
else if (_cogl_program_get_language (user_program) !=
COGL_SHADER_LANGUAGE_ARBFP)
return FALSE;
}
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
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
/* Now lookup our ARBfp backend private state */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = get_shader_state (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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
/* If we have a valid shader_state then we are all set and don't
* need to generate a new program. */
if (shader_state)
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -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
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
/* If we don't have an associated arbfp program yet then find the
* arbfp-authority (the oldest ancestor whose state will result in
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
* the same program being generated as for this pipeline).
material-arbfp: fixes for how we track private state This fixes a number of issues relating to how we track the arbfp private state associated with CoglMaterials. At the same time it adds much more extensive code documentation to try and make it a bit more approachable.
2010-09-13 18:52:18 -04:00
*
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
* We always make sure to associate new programs 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
* arbfp-authority to maximize the chance that other pipelines can
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
* share it.
material-arbfp: fixes for how we track private state This fixes a number of issues relating to how we track the arbfp private state associated with CoglMaterials. At the same time it adds much more extensive code documentation to try and make it a bit more approachable.
2010-09-13 18:52:18 -04:00
*/
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,
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
_cogl_pipeline_get_state_for_fragment_codegen (ctx) &
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
~COGL_PIPELINE_STATE_LAYERS,
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
_cogl_pipeline_get_layer_state_for_fragment_codegen (ctx));
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = get_shader_state (authority);
if (shader_state)
pipeline: Clarify stages for finding an arbfp program In the arbfp backend there is a seqential approach to finding a suitable arbfp program to use for a given pipeline; first we see if there's already a program associated with the pipeline, 2nd we try and find a program associated with the "arbfp-authority" 3rd we try and lookup a program in a cache and finally we resort to starting code-generation for a new program. This patch slightly reworks the code of these steps to hopefully make them a bit clearer.
2010-12-08 11:23:10 -05:00
{
/* If we are going to share our program state with an arbfp-authority
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
* then add a reference to the program state associated with that
pipeline: Clarify stages for finding an arbfp program In the arbfp backend there is a seqential approach to finding a suitable arbfp program to use for a given pipeline; first we see if there's already a program associated with the pipeline, 2nd we try and find a program associated with the "arbfp-authority" 3rd we try and lookup a program in a cache and finally we resort to starting code-generation for a new program. This patch slightly reworks the code of these steps to hopefully make them a bit clearer.
2010-12-08 11:23:10 -05:00
* arbfp-authority... */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->ref_count++;
set_shader_state (pipeline, shader_state);
pipeline: Clarify stages for finding an arbfp program In the arbfp backend there is a seqential approach to finding a suitable arbfp program to use for a given pipeline; first we see if there's already a program associated with the pipeline, 2nd we try and find a program associated with the "arbfp-authority" 3rd we try and lookup a program in a cache and finally we resort to starting code-generation for a new program. This patch slightly reworks the code of these steps to hopefully make them a bit clearer.
2010-12-08 11:23:10 -05:00
return TRUE;
}
arbfp: Adds an ARBfp program cache This adds a cache (A GHashTable) of ARBfp programs and before ever starting to code-generate a new program we will always first try and find an existing program in the cache. This uses _cogl_pipeline_hash and _cogl_pipeline_equal to hash and compare the keys for the cache. There is a new COGL_DEBUG=disable-program-caches option that can disable the cache for debugging purposes.
2010-12-03 07:01:18 -05:00
/* If we haven't yet found an existing program then before we resort to
* generating a new arbfp program we see if we can find a suitable
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
* program in the pipeline_cache. */
cogl-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_LIKELY (!(COGL_DEBUG_ENABLED (COGL_DEBUG_DISABLE_PROGRAM_CACHES))))
arbfp: Adds an ARBfp program cache This adds a cache (A GHashTable) of ARBfp programs and before ever starting to code-generate a new program we will always first try and find an existing program in the cache. This uses _cogl_pipeline_hash and _cogl_pipeline_equal to hash and compare the keys for the cache. There is a new COGL_DEBUG=disable-program-caches option that can disable the cache for debugging purposes.
2010-12-03 07:01:18 -05:00
{
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
template_pipeline =
_cogl_pipeline_cache_get_fragment_template (ctx->pipeline_cache,
authority);
shader_state = get_shader_state (template_pipeline);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state)
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
shader_state->ref_count++;
}
/* If we still haven't got a shader state then we'll have to create
a new one */
if (shader_state == NULL)
{
shader_state = shader_state_new (n_layers);
pipeline: Clarify stages for finding an arbfp program In the arbfp backend there is a seqential approach to finding a suitable arbfp program to use for a given pipeline; first we see if there's already a program associated with the pipeline, 2nd we try and find a program associated with the "arbfp-authority" 3rd we try and lookup a program in a cache and finally we resort to starting code-generation for a new program. This patch slightly reworks the code of these steps to hopefully make them a bit clearer.
2010-12-08 11:23:10 -05:00
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
shader_state->user_program = user_program;
if (user_program == COGL_INVALID_HANDLE)
{
/* We reuse a single grow-only GString for code-gen */
g_string_set_size (ctx->codegen_source_buffer, 0);
shader_state->source = ctx->codegen_source_buffer;
g_string_append (shader_state->source,
"!!ARBfp1.0\n"
"TEMP output;\n"
"TEMP tmp0, tmp1, tmp2, tmp3, tmp4;\n"
"PARAM half = {.5, .5, .5, .5};\n"
"PARAM one = {1, 1, 1, 1};\n"
"PARAM two = {2, 2, 2, 2};\n"
"PARAM minus_one = {-1, -1, -1, -1};\n");
pipeline: Clarify stages for finding an arbfp program In the arbfp backend there is a seqential approach to finding a suitable arbfp program to use for a given pipeline; first we see if there's already a program associated with the pipeline, 2nd we try and find a program associated with the "arbfp-authority" 3rd we try and lookup a program in a cache and finally we resort to starting code-generation for a new program. This patch slightly reworks the code of these steps to hopefully make them a bit clearer.
2010-12-08 11:23:10 -05:00
}
arbfp: Adds an ARBfp program cache This adds a cache (A GHashTable) of ARBfp programs and before ever starting to code-generate a new program we will always first try and find an existing program in the cache. This uses _cogl_pipeline_hash and _cogl_pipeline_equal to hash and compare the keys for the cache. There is a new COGL_DEBUG=disable-program-caches option that can disable the cache for debugging purposes.
2010-12-03 07:01:18 -05:00
}
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
set_shader_state (pipeline, shader_state);
pipeline: Clarify stages for finding an arbfp program In the arbfp backend there is a seqential approach to finding a suitable arbfp program to use for a given pipeline; first we see if there's already a program associated with the pipeline, 2nd we try and find a program associated with the "arbfp-authority" 3rd we try and lookup a program in a cache and finally we resort to starting code-generation for a new program. This patch slightly reworks the code of these steps to hopefully make them a bit clearer.
2010-12-08 11:23:10 -05:00
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
/* Since we have already resolved the arbfp-authority at this point
* we might as well also associate any program we find from the cache
* with the authority too... */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (authority != pipeline)
{
shader_state->ref_count++;
set_shader_state (authority, shader_state);
}
pipeline: Clarify stages for finding an arbfp program In the arbfp backend there is a seqential approach to finding a suitable arbfp program to use for a given pipeline; first we see if there's already a program associated with the pipeline, 2nd we try and find a program associated with the "arbfp-authority" 3rd we try and lookup a program in a cache and finally we resort to starting code-generation for a new program. This patch slightly reworks the code of these steps to hopefully make them a bit clearer.
2010-12-08 11:23:10 -05:00
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
/* If we found a template then we'll attach it to that too so that
next time a similar pipeline is used it can use the same state */
if (template_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
{
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
shader_state->ref_count++;
set_shader_state (template_pipeline, shader_state);
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
}
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -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
}
static const char *
gl_target_to_arbfp_string (GLenum gl_target)
{
if (gl_target == GL_TEXTURE_1D)
return "1D";
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
else if (gl_target == GL_TEXTURE_2D)
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 "2D";
#ifdef GL_ARB_texture_rectangle
else if (gl_target == GL_TEXTURE_RECTANGLE_ARB)
return "RECT";
#endif
Add a Cogl texture 3D backend This adds a publicly exposed experimental API for a 3D texture backend. There is a feature flag which can be checked for whether 3D textures are supported. Although we require OpenGL 1.2 which has 3D textures in core, GLES only provides them through an extension so the feature can be used to detect that. The textures can be created with one of two new API functions :- cogl_texture_3d_new_with_size and cogl_texture_3d_new_from_data There is also internally a new_from_bitmap function. new_from_data is implemented in terms of this function. The two constructors are effectively the only way to upload data to a 3D texture. It does not work to call glTexImage2D with the GL_TEXTURE_3D target so the virtual for cogl_texture_set_region does nothing. It would be possible to make cogl_texture_get_data do something sensible like returning all of the images as a single long image but this is not currently implemented and instead the virtual just always fails. We may want to add API specific to the 3D texture backend to get and set a sub region of the texture. All of those three functions can throw a GError. This will happen if the GPU does not support 3D textures or it does not support NPOTs and an NPOT size is requested. It will also fail if the FBO extension is not supported and the COGL_TEXTURE_NO_AUTO_MIPMAP flag is not given. This could be avoided by copying the code for the GL_GENERATE_MIPMAP TexParameter fallback, but in the interests of keeping the code simple this is not yet done. This adds a couple of functions to cogl-texture-driver for uploading 3D data and querying the 3D proxy texture. prep_gl_for_pixels_upload_full now also takes sets the GL_UNPACK_IMAGE_HEIGHT parameter so that 3D textures can have padding between the images. Whenever 3D texture is uploading, both the height of the images and the height of all of the data is specified (either explicitly or implicilty from the CoglBitmap) so that the image height can be deduced by dividing by the depth.
2010-07-01 17:04:59 -04:00
else if (gl_target == GL_TEXTURE_3D)
return "3D";
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
else
return "2D";
}
static void
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
setup_texture_source (CoglPipelineShaderState *shader_state,
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 unit_index,
GLenum gl_target)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (!shader_state->unit_state[unit_index].sampled)
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
{
Implement COGL_DEBUG=disable-texturing for ARBFp and GLSL fragends The COGL_DEBUG=disable-texturing debug variable disables texturing in the fixed function fragend by not bothering to enable the texture targets. This wasn't working for the programmable fragends because the texture targets don't need to be enabled to use them. This patch modifies the two programmable backends to generate a constant value for the texture lookups in the shader when the debug variable is given.
2011-06-08 13:03:58 -04:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (COGL_DEBUG_DISABLE_TEXTURING)))
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
Implement COGL_DEBUG=disable-texturing for ARBFp and GLSL fragends The COGL_DEBUG=disable-texturing debug variable disables texturing in the fixed function fragend by not bothering to enable the texture targets. This wasn't working for the programmable fragends because the texture targets don't need to be enabled to use them. This patch modifies the two programmable backends to generate a constant value for the texture lookups in the shader when the debug variable is given.
2011-06-08 13:03:58 -04:00
"TEMP texel%d;\n"
"MOV texel%d, one;\n",
unit_index,
unit_index);
else
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
Implement COGL_DEBUG=disable-texturing for ARBFp and GLSL fragends The COGL_DEBUG=disable-texturing debug variable disables texturing in the fixed function fragend by not bothering to enable the texture targets. This wasn't working for the programmable fragends because the texture targets don't need to be enabled to use them. This patch modifies the two programmable backends to generate a constant value for the texture lookups in the shader when the debug variable is given.
2011-06-08 13:03:58 -04:00
"TEMP texel%d;\n"
"TEX texel%d,fragment.texcoord[%d],"
"texture[%d],%s;\n",
unit_index,
unit_index,
unit_index,
unit_index,
gl_target_to_arbfp_string (gl_target));
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->unit_state[unit_index].sampled = 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
}
}
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 enum _CoglPipelineFragendARBfpArgType
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_ARBFP_ARG_TYPE_SIMPLE,
COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_CONSTANT,
COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_TEXTURE
} CoglPipelineFragendARBfpArgType;
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
typedef struct _CoglPipelineFragendARBfpArg
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
{
const char *name;
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
CoglPipelineFragendARBfpArgType type;
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
/* for type = TEXTURE */
int texture_unit;
GLenum texture_target;
/* for type = CONSTANT */
int constant_id;
const char *swizzle;
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
} CoglPipelineFragendARBfpArg;
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 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
append_arg (GString *source, const CoglPipelineFragendARBfpArg *arg)
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
{
switch (arg->type)
{
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
case COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_TEXTURE:
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
g_string_append_printf (source, "texel%d%s",
arg->texture_unit, arg->swizzle);
break;
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
case COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_CONSTANT:
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
g_string_append_printf (source, "program.local[%d]%s",
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
arg->constant_id, arg->swizzle);
break;
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
case COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_SIMPLE:
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
g_string_append_printf (source, "%s%s",
arg->name, arg->swizzle);
break;
}
}
/* Note: we are trying to avoid duplicating strings during codegen
* which is why we have the slightly awkward
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
* CoglPipelineFragendARBfpArg mechanism. */
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 void
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
setup_arg (CoglPipeline *pipeline,
CoglPipelineLayer *layer,
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
CoglBlendStringChannelMask mask,
int arg_index,
GLint src,
GLint op,
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
CoglPipelineFragendARBfpArg *arg)
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
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = get_shader_state (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
static const char *tmp_name[3] = { "tmp0", "tmp1", "tmp2" };
GLenum gl_target;
CoglHandle texture;
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:
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
arg->type = COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_TEXTURE;
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
arg->name = "texel%d";
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
arg->texture_unit = _cogl_pipeline_layer_get_unit_index (layer);
texture = _cogl_pipeline_layer_get_texture (layer);
arbfp: assume GL_TEXTURE_2D target for NULL texture During arbfp codegen we weren't checking for NULL textures and so we would crash when trying to query a NULL texture's GL texture target. Since NULL texture targets result in ctx->default_gl_texture_2d_tex being bound we can assume that a NULL texture corresponds to a GL_TEXTURE_2D target. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-09-21 15:04:44 -04:00
if (texture)
cogl_texture_get_gl_texture (texture, NULL, &gl_target);
else
gl_target = GL_TEXTURE_2D;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
setup_texture_source (shader_state, arg->texture_unit, gl_target);
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
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:
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: 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
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
UnitState *unit_state = &shader_state->unit_state[unit_index];
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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
unit_state->constant_id = shader_state->next_constant_id++;
arbfp: track which layers have combine constants We weren't actually tracking which layers have been allocated param space for combine constants; all layers just had a default constant_id of 0 that indexes into the program.local[] params array and a dirty flag to say when the constant needs updating. There are times though when we say to update everything by-passing the dirty flag and because we weren't actually tracking which layers needed constants we would always write a constant to program.local[0] for every layer. The upshot was that we could end up clobbering a real constant that was actually allocated the constant_id = 0 slot. This patch adds a new UnitState bitfield to track if the layer has a corresponding constant that may need flushing and we only ever write the constant with glProgramLocalParameter4fv if that's set. https://bugzilla.gnome.org/show_bug.cgi?id=658092 Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-09-08 18:08:43 -04:00
unit_state->has_combine_constant = TRUE;
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
unit_state->dirty_combine_constant = TRUE;
material-arbfp: Use locale-independent double to string conversion The ARBfp programs are created with a printf() wrapper, which usually fails in non-en locales as soon as you start throwing things like floating point values in the mix. We should use the g_ascii_dtostr() function which places a double into a string buffer in a locale-independent way. http://bugzilla.clutter-project.org/show_bug.cgi?id=2219
2010-07-16 18:37:59 -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
arg->type = COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_CONSTANT;
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
arg->name = "program.local[%d]";
arg->constant_id = unit_state->constant_id;
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
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_PRIMARY_COLOR:
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
arg->type = COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_SIMPLE;
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
arg->name = "fragment.color.primary";
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:
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
arg->type = COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_SIMPLE;
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
if (_cogl_pipeline_layer_get_unit_index (layer) == 0)
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
arg->name = "fragment.color.primary";
else
arg->name = "output";
break;
default: /* GL_TEXTURE0..N */
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
arg->type = COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_TEXTURE;
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
arg->name = "texture[%d]";
arg->texture_unit = src - GL_TEXTURE0;
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
texture = _cogl_pipeline_layer_get_texture (layer);
arbfp: assume GL_TEXTURE_2D target for NULL texture During arbfp codegen we weren't checking for NULL textures and so we would crash when trying to query a NULL texture's GL texture target. Since NULL texture targets result in ctx->default_gl_texture_2d_tex being bound we can assume that a NULL texture corresponds to a GL_TEXTURE_2D target. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-09-21 15:04:44 -04:00
if (texture)
cogl_texture_get_gl_texture (texture, NULL, &gl_target);
else
gl_target = GL_TEXTURE_2D;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
setup_texture_source (shader_state, arg->texture_unit, gl_target);
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
}
arg->swizzle = "";
switch (op)
{
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_OP_SRC_COLOR:
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
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_OP_ONE_MINUS_SRC_COLOR:
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
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
"SUB tmp%d, one, ",
arg_index);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
append_arg (shader_state->source, arg);
g_string_append_printf (shader_state->source, ";\n");
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
arg->type = COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_SIMPLE;
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
arg->name = tmp_name[arg_index];
arg->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_OP_SRC_ALPHA:
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
/* avoid a swizzle if we know RGB are going to be masked
* in the end anyway */
if (mask != COGL_BLEND_STRING_CHANNEL_MASK_ALPHA)
arg->swizzle = ".a";
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_OP_ONE_MINUS_SRC_ALPHA:
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
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
"SUB tmp%d, one, ",
arg_index);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
append_arg (shader_state->source, arg);
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
/* avoid a swizzle if we know RGB are going to be masked
* in the end anyway */
if (mask != COGL_BLEND_STRING_CHANNEL_MASK_ALPHA)
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source, ".a;\n");
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
else
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source, ";\n");
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
arg->type = COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_SIMPLE;
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
arg->name = tmp_name[arg_index];
break;
default:
g_error ("Unknown texture combine operator %d", op);
break;
}
}
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
fragend_arbfp_args_equal (CoglPipelineFragendARBfpArg *arg0,
CoglPipelineFragendARBfpArg *arg1)
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
{
if (arg0->type != arg1->type)
return FALSE;
if (arg0->name != arg1->name &&
strcmp (arg0->name, arg1->name) != 0)
return FALSE;
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 (arg0->type == COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_TEXTURE &&
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
arg0->texture_unit != arg1->texture_unit)
return FALSE;
/* Note we don't have to check the target; a texture unit can only
* have one target enabled at a time. */
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 (arg0->type == COGL_PIPELINE_FRAGEND_ARBFP_ARG_TYPE_CONSTANT &&
cogl-pipeline-fragend-arbfp: Fix the comparison for dot3 arguments There was a typo in fragend_arbfp_args_equal so that it wasn't comparing the constants correctly. Thomas Wood found this bug with static analysis.
2011-05-11 08:50:32 -04:00
arg0->constant_id != arg1->constant_id)
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 FALSE;
if (arg0->swizzle != arg1->swizzle &&
strcmp (arg0->swizzle, arg1->swizzle) != 0)
return FALSE;
return TRUE;
}
static void
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
append_function (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
CoglBlendStringChannelMask mask,
GLint function,
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
CoglPipelineFragendARBfpArg *args,
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_args)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = get_shader_state (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
const char *mask_name;
switch (mask)
{
case COGL_BLEND_STRING_CHANNEL_MASK_RGB:
mask_name = ".rgb";
break;
case COGL_BLEND_STRING_CHANNEL_MASK_ALPHA:
mask_name = ".a";
break;
case COGL_BLEND_STRING_CHANNEL_MASK_RGBA:
mask_name = "";
break;
default:
g_error ("Unknown channel mask %d", mask);
mask_name = "";
}
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_ADD:
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
"ADD_SAT output%s, ",
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
mask_name);
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:
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
/* Note: no need to saturate since we can assume operands
* have values in the range [0,1] */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source, "MUL output%s, ",
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
mask_name);
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_REPLACE:
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
/* Note: no need to saturate since we can assume operand
* has a value in the range [0,1] */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source, "MOV output%s, ",
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
mask_name);
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:
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
"SUB_SAT output%s, ",
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
mask_name);
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:
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source, "ADD tmp3%s, ",
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
mask_name);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
append_arg (shader_state->source, &args[0]);
g_string_append (shader_state->source, ", ");
append_arg (shader_state->source, &args[1]);
g_string_append (shader_state->source, ";\n");
g_string_append_printf (shader_state->source,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
"SUB_SAT output%s, tmp3, half",
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
mask_name);
n_args = 0;
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:
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
/* These functions are the same except that GL_DOT3_RGB never
* updates the alpha channel.
*
* NB: GL_DOT3_RGBA is a bit special because it effectively forces
* an RGBA mask and we end up ignoring any separate alpha channel
* 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_DOT3_RGBA:
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
{
const char *tmp4 = "tmp4";
/* The maths for this was taken from Mesa;
* apparently:
*
* tmp3 = 2*src0 - 1
* tmp4 = 2*src1 - 1
* output = DP3 (tmp3, tmp4)
*
* is the same as:
*
* output = 4 * DP3 (src0 - 0.5, src1 - 0.5)
*/
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source, "MAD tmp3, two, ");
append_arg (shader_state->source, &args[0]);
g_string_append (shader_state->source, ", minus_one;\n");
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
if (!fragend_arbfp_args_equal (&args[0], &args[1]))
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
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source, "MAD tmp4, two, ");
append_arg (shader_state->source, &args[1]);
g_string_append (shader_state->source, ", minus_one;\n");
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
}
else
tmp4 = "tmp3";
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
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
"DP3_SAT output%s, tmp3, %s",
mask_name, tmp4);
n_args = 0;
}
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:
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
/* Note: no need to saturate since we can assume operands
* have values in the range [0,1] */
/* NB: GL_INTERPOLATE = arg0*arg2 + arg1*(1-arg2)
* but LRP dst, a, b, c = b*a + c*(1-a) */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source, "LRP output%s, ",
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
mask_name);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
append_arg (shader_state->source, &args[2]);
g_string_append (shader_state->source, ", ");
append_arg (shader_state->source, &args[0]);
g_string_append (shader_state->source, ", ");
append_arg (shader_state->source, &args[1]);
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
n_args = 0;
break;
default:
g_error ("Unknown texture combine function %d", function);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source, "MUL_SAT output%s, ",
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
mask_name);
n_args = 2;
break;
}
if (n_args > 0)
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
append_arg (shader_state->source, &args[0]);
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
if (n_args > 1)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source, ", ");
append_arg (shader_state->source, &args[1]);
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
}
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source, ";\n");
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 void
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
append_masked_combine (CoglPipeline *arbfp_authority,
CoglPipelineLayer *layer,
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
CoglBlendStringChannelMask mask,
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)
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 i;
int n_args;
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
CoglPipelineFragendARBfpArg args[3];
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
n_args = _cogl_get_n_args_for_combine_func (function);
for (i = 0; i < n_args; i++)
{
setup_arg (arbfp_authority,
layer,
mask,
i,
src[i],
op[i],
&args[i]);
}
append_function (arbfp_authority,
mask,
function,
args,
n_args);
}
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_arbfp_add_layer (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
CoglPipelineLayer *layer,
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
unsigned long layers_difference)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = get_shader_state (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
CoglPipelineLayer *combine_authority =
_cogl_pipeline_layer_get_authority (layer,
COGL_PIPELINE_LAYER_STATE_COMBINE);
CoglPipelineLayerBigState *big_state = combine_authority->big_state;
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
/* Notes...
*
* We are ignoring the issue of texture indirection limits until
* someone complains (Ref Section 3.11.6 in the ARB_fragment_program
* spec)
*
* There always five TEMPs named tmp0, tmp1 and tmp2, tmp3 and tmp4
* available and these constants: 'one' = {1, 1, 1, 1}, 'half'
* {.5, .5, .5, .5}, 'two' = {2, 2, 2, 2}, 'minus_one' = {-1, -1,
* -1, -1}
*
* tmp0-2 are intended for dealing with some of the texture combine
* operands (e.g. GL_ONE_MINUS_SRC_COLOR) tmp3/4 are for dealing
* with the GL_ADD_SIGNED texture combine and the GL_DOT3_RGB[A]
* functions.
*
* Each layer outputs to the TEMP called "output", and reads from
* output if it needs to refer to GL_PREVIOUS. (we detect if we are
* layer0 so we will read fragment.color for GL_PREVIOUS in that
* case)
*
* We aim to do all the channels together if the same function is
* used for RGB as for A.
*
* We aim to avoid string duplication / allocations during codegen.
*
* We are careful to only saturate when writing to output.
*/
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (!shader_state->source)
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;
pipeline: Split more code out from cogl-pipeline.c This splits out the core CoglPipelineLayer support code from cogl-pipeline.c into cogl-pipeline-layer.c; it splits out the debugging code for dumping a pipeline to a .dot file into cogl-pipeline-debug.c and it splits the CoglPipelineNode support which is shared between CoglPipeline and CoglPipelineLayer into cogl-node.c. Note: cogl-pipeline-layer.c only contains the layer code directly relating to CoglPipelineLayer objects; it does not contain any _cogl_pipeline API relating to how CoglPipeline tracks and manipulates layers.
2011-09-08 19:40:06 -04:00
if (!_cogl_pipeline_layer_needs_combine_separate (combine_authority))
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: 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
append_masked_combine (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
layer,
COGL_BLEND_STRING_CHANNEL_MASK_RGBA,
big_state->texture_combine_rgb_func,
big_state->texture_combine_rgb_src,
big_state->texture_combine_rgb_op);
}
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
else if (big_state->texture_combine_rgb_func ==
COGL_PIPELINE_COMBINE_FUNC_DOT3_RGBA)
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
{
/* GL_DOT3_RGBA Is a bit weird as a GL_COMBINE_RGB function
* since if you use it, it overrides your ALPHA function...
*/
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
append_masked_combine (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
layer,
COGL_BLEND_STRING_CHANNEL_MASK_RGBA,
big_state->texture_combine_rgb_func,
big_state->texture_combine_rgb_src,
big_state->texture_combine_rgb_op);
}
else
{
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
append_masked_combine (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
layer,
COGL_BLEND_STRING_CHANNEL_MASK_RGB,
big_state->texture_combine_rgb_func,
big_state->texture_combine_rgb_src,
big_state->texture_combine_rgb_op);
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
append_masked_combine (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
layer,
COGL_BLEND_STRING_CHANNEL_MASK_ALPHA,
big_state->texture_combine_alpha_func,
big_state->texture_combine_alpha_src,
big_state->texture_combine_alpha_op);
}
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_arbfp_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
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = get_shader_state (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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (!shader_state->source)
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;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
"MOV output, fragment.color.primary;\n");
return TRUE;
}
typedef struct _UpdateConstantsState
{
int unit;
material-arbfp: fix updating params if sharing progs If a single arbfp program is being shared between multiple CoglMaterials then we need to make sure we update all program.local params when switching between materials. Previously we had a dirty flag to track when combine_constant params were changed but didn't take in to account that different materials sharing the same program may have different combine constants.
2010-09-14 15:25:23 -04:00
gboolean update_all;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state;
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
} UpdateConstantsState;
static gboolean
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
update_constants_cb (CoglPipeline *pipeline,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
int layer_index,
void *user_data)
{
UpdateConstantsState *state = user_data;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = state->shader_state;
UnitState *unit_state = &shader_state->unit_state[state->unit++];
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
_COGL_GET_CONTEXT (ctx, FALSE);
arbfp: track which layers have combine constants We weren't actually tracking which layers have been allocated param space for combine constants; all layers just had a default constant_id of 0 that indexes into the program.local[] params array and a dirty flag to say when the constant needs updating. There are times though when we say to update everything by-passing the dirty flag and because we weren't actually tracking which layers needed constants we would always write a constant to program.local[0] for every layer. The upshot was that we could end up clobbering a real constant that was actually allocated the constant_id = 0 slot. This patch adds a new UnitState bitfield to track if the layer has a corresponding constant that may need flushing and we only ever write the constant with glProgramLocalParameter4fv if that's set. https://bugzilla.gnome.org/show_bug.cgi?id=658092 Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-09-08 18:08:43 -04:00
if (unit_state->has_combine_constant &&
(state->update_all || unit_state->dirty_combine_constant))
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
{
float constant[4];
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
_cogl_pipeline_get_layer_combine_constant (pipeline,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
layer_index,
constant);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glProgramLocalParameter4fv (GL_FRAGMENT_PROGRAM_ARB,
unit_state->constant_id,
constant));
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
unit_state->dirty_combine_constant = 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
return TRUE;
}
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_arbfp_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
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = get_shader_state (pipeline);
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
GLuint gl_program;
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);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state->source)
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
{
GLenum gl_error;
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_STATIC_COUNTER (fragend_arbfp_compile_counter,
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
"arbfp compile counter",
"Increments each time a new ARBfp "
"program is compiled",
0 /* no application private data */);
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_COUNTER_INC (_cogl_uprof_context, fragend_arbfp_compile_counter);
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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
"MOV result.color,output;\n");
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source, "END\n");
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-debug: Split the flags to support more than 32 The CoglDebugFlags are now stored in an array of unsigned ints rather than a single variable. The flags are accessed using macros instead of directly peeking at the cogl_debug_flags variable. The index values are stored in the enum rather than the actual mask values so that the enum doesn't need to be more than 32 bits wide. The hope is that the code to determine the index into the array can be optimized out by the compiler so it should have exactly the same performance as the old code.
2011-01-24 09:28:00 -05:00
if (G_UNLIKELY (COGL_DEBUG_ENABLED (COGL_DEBUG_SHOW_SOURCE)))
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_message ("pipeline program:\n%s", shader_state->source->str);
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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
GE (ctx, glGenPrograms (1, &shader_state->gl_program));
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
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindProgram (GL_FRAGMENT_PROGRAM_ARB,
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->gl_program));
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
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
while ((gl_error = ctx->glGetError ()) != GL_NO_ERROR)
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
;
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
ctx->glProgramString (GL_FRAGMENT_PROGRAM_ARB,
GL_PROGRAM_FORMAT_ASCII_ARB,
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->source->len,
shader_state->source->str);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
if (ctx->glGetError () != GL_NO_ERROR)
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
{
g_warning ("\n%s\n%s",
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->source->str,
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
ctx->glGetString (GL_PROGRAM_ERROR_STRING_ARB));
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
}
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->source = NULL;
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: 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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state->user_program != COGL_INVALID_HANDLE)
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
{
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
/* An arbfp program should contain exactly one shader which we
can use directly */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglProgram *program = shader_state->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
CoglShader *shader = program->attached_shaders->data;
gl_program = shader->gl_handle;
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
else
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
gl_program = shader_state->gl_program;
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
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindProgram (GL_FRAGMENT_PROGRAM_ARB, gl_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_use_fragment_program (0, COGL_PIPELINE_PROGRAM_TYPE_ARBFP);
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
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state->user_program == COGL_INVALID_HANDLE)
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
{
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
UpdateConstantsState state;
state.unit = 0;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
state.shader_state = shader_state;
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
/* If this arbfp program was last used with a different pipeline
material-arbfp: fix updating params if sharing progs If a single arbfp program is being shared between multiple CoglMaterials then we need to make sure we update all program.local params when switching between materials. Previously we had a dirty flag to track when combine_constant params were changed but didn't take in to account that different materials sharing the same program may have different combine constants.
2010-09-14 15:25:23 -04:00
* then we need to ensure we update all program.local params */
state.update_all =
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
pipeline != shader_state->last_used_for_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
cogl_pipeline_foreach_layer (pipeline,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
update_constants_cb,
&state);
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -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
else
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglProgram *program = shader_state->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
gboolean program_changed;
/* If the shader has changed since it was last flushed then we
need to update all uniforms */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
program_changed = program->age != shader_state->user_program_age;
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_flush_uniforms (program, gl_program, program_changed);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->user_program_age = program->age;
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-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
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
/* We need to track what pipeline used this arbfp program last since
material-arbfp: fix updating params if sharing progs If a single arbfp program is being shared between multiple CoglMaterials then we need to make sure we update all program.local params when switching between materials. Previously we had a dirty flag to track when combine_constant params were changed but didn't take in to account that different materials sharing the same program may have different combine constants.
2010-09-14 15:25:23 -04:00
* we will need to update program.local params when switching
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
* between different pipelines. */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->last_used_for_pipeline = pipeline;
material-arbfp: fix updating params if sharing progs If a single arbfp program is being shared between multiple CoglMaterials then we need to make sure we update all program.local params when switching between materials. Previously we had a dirty flag to track when combine_constant params were changed but didn't take in to account that different materials sharing the same program may have different combine constants.
2010-09-14 15:25:23 -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;
}
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_arbfp_pipeline_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
CoglPipeline *pipeline,
CoglPipelineState change,
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
const CoglColor *new_color)
{
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if ((change & _cogl_pipeline_get_state_for_fragment_codegen (ctx)))
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
dirty_shader_state (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
}
material: pass material owner for layer pre changes When notifying a backend about a layer being modified we now pass the layers current owner for reference. NB: Although a layer can indirectly be referenced by multiple layers, a layer is considered immutable once it has dependants, so there is only ever one material associated with a layer being modified. Passing the material pointer to the backends layer_pre_change callback can be useful for backends that associate their private state with materials and may need to update that state in response to layer changes.
2010-09-13 18:05:49 -04:00
/* NB: layers are considered immutable once they have any dependants
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
* so although multiple pipelines can end up depending on a single
material: pass material owner for layer pre changes When notifying a backend about a layer being modified we now pass the layers current owner for reference. NB: Although a layer can indirectly be referenced by multiple layers, a layer is considered immutable once it has dependants, so there is only ever one material associated with a layer being modified. Passing the material pointer to the backends layer_pre_change callback can be useful for backends that associate their private state with materials and may need to update that state in response to layer changes.
2010-09-13 18:05:49 -04:00
* static layer, we can guarantee that if a layer is being *changed*
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
* then it can only have one pipeline depending on it.
material: pass material owner for layer pre changes When notifying a backend about a layer being modified we now pass the layers current owner for reference. NB: Although a layer can indirectly be referenced by multiple layers, a layer is considered immutable once it has dependants, so there is only ever one material associated with a layer being modified. Passing the material pointer to the backends layer_pre_change callback can be useful for backends that associate their private state with materials and may need to update that state in response to layer changes.
2010-09-13 18:05:49 -04:00
*
* XXX: Don't forget this is *pre* change, we can't read the new value
* yet!
*/
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 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_arbfp_layer_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
CoglPipeline *owner,
CoglPipelineLayer *layer,
CoglPipelineLayerState change)
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
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = get_shader_state (owner);
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (!shader_state)
material: make layer/material_pre_changes mutually exclusive This makes it so we only notify backends of either a single material change or a single layer change. Previously all material STATE_LAYERS changes would be followed by a more detailed layer change. For backends that perform code generation for fragment processing they typically need to understand the details of how layers get changed to determine if they need to repeat codegen. It doesn't help them to report a material STATE_LAYERS change for all layer changes since it's so broad, they really need to wait for the layer change to be notified. What does help though is to report a STATE_LAYERS change for a change in material->n_layers because they typically do need to repeat codegen in that case.
2010-09-13 19:18:02 -04:00
return;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if ((change & _cogl_pipeline_get_layer_state_for_fragment_codegen (ctx)))
material-arbfp: don't redo codegen for texture changes This makes it so we don't consider LAYER_STATE_TEXTURE changes to affect the arbfp code. This should avoid a lot of unneeded passes of code generation for applications modifying the texture for a layer.
2010-09-13 19:27:57 -04:00
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
dirty_shader_state (owner);
material-arbfp: don't redo codegen for texture changes This makes it so we don't consider LAYER_STATE_TEXTURE changes to affect the arbfp code. This should avoid a lot of unneeded passes of code generation for applications modifying the texture for a layer.
2010-09-13 19:27:57 -04:00
return;
}
material: make layer/material_pre_changes mutually exclusive This makes it so we only notify backends of either a single material change or a single layer change. Previously all material STATE_LAYERS changes would be followed by a more detailed layer change. For backends that perform code generation for fragment processing they typically need to understand the details of how layers get changed to determine if they need to repeat codegen. It doesn't help them to report a material STATE_LAYERS change for all layer changes since it's so broad, they really need to wait for the layer change to be notified. What does help though is to report a STATE_LAYERS change for a change in material->n_layers because they typically do need to repeat codegen in that case.
2010-09-13 19:18:02 -04:00
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
if (change & COGL_PIPELINE_LAYER_STATE_COMBINE_CONSTANT)
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -04:00
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
shader_state->unit_state[unit_index].dirty_combine_constant = TRUE;
material-arbfp: don't recompile for constant changes Instead of lazily incorporating combine constants as arbfp PARAM constants in the source directly we now use program.local parameters instead so we can avoid repeating codegen if a material's combine constant is updated. This should be a big win for applications animating a constant used for example in an animated interpolation, such as gnome-shell. http://bugzilla.clutter-project.org/show_bug.cgi?id=2280
2010-09-13 19:33:46 -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
/* 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. */
return;
}
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_arbfp_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_arbfp_start,
_cogl_pipeline_fragend_arbfp_add_layer,
_cogl_pipeline_fragend_arbfp_passthrough,
_cogl_pipeline_fragend_arbfp_end,
_cogl_pipeline_fragend_arbfp_pipeline_pre_change_notify,
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
NULL,
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
_cogl_pipeline_fragend_arbfp_layer_pre_change_notify
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_ARBFP */
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