isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-23 00:20:42 -05:00
Code Issues Packages Projects Releases Wiki Activity
b2285058a4
mutter/cogl/cogl-pipeline-fragend-arbfp.c

1110 lines
36 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: 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"
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"
#include "cogl-context.h"
#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>
/*
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
* GL/GLES compatability defines for pipeline thingies:
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
*/
#ifdef HAVE_COGL_GL
#define glProgramString ctx->drv.pf_glProgramString
#define glBindProgram ctx->drv.pf_glBindProgram
#define glDeletePrograms ctx->drv.pf_glDeletePrograms
#define glGenPrograms ctx->drv.pf_glGenPrograms
#define glProgramLocalParameter4fv ctx->drv.pf_glProgramLocalParameter4fv
#define glUseProgram ctx->drv.pf_glUseProgram
#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
/* This might not be defined on GLES */
#ifndef GL_TEXTURE_3D
#define GL_TEXTURE_3D 0x806F
#endif
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;
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;
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
typedef struct _ArbfpProgramState
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
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 */
CoglPipeline *arbfp_authority;
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;
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
} ArbfpProgramState;
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 _CoglPipelineFragendARBfpPrivate
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
{
ArbfpProgramState *arbfp_program_state;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
} CoglPipelineFragendARBfpPrivate;
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
const CoglPipelineFragend _cogl_pipeline_arbfp_fragend;
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
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
static ArbfpProgramState *
arbfp_program_state_new (int n_layers)
{
ArbfpProgramState *state = g_slice_new0 (ArbfpProgramState);
state->ref_count = 1;
state->unit_state = g_new0 (UnitState, n_layers);
return state;
}
static ArbfpProgramState *
arbfp_program_state_ref (ArbfpProgramState *state)
{
state->ref_count++;
return state;
}
void
arbfp_program_state_unref (ArbfpProgramState *state)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
g_return_if_fail (state->ref_count > 0);
state->ref_count--;
if (state->ref_count == 0)
{
if (state->gl_program)
{
GE (glDeletePrograms (1, &state->gl_program));
state->gl_program = 0;
}
g_free (state->unit_state);
g_slice_free (ArbfpProgramState, state);
}
}
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
static CoglPipelineFragendARBfpPrivate *
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
get_arbfp_priv (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
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
if (!(pipeline->fragend_priv_set_mask & COGL_PIPELINE_FRAGEND_ARBFP_MASK))
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 NULL;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
return pipeline->fragend_privs[COGL_PIPELINE_FRAGEND_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
}
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
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
set_arbfp_priv (CoglPipeline *pipeline, CoglPipelineFragendARBfpPrivate *priv)
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
if (priv)
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
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
pipeline->fragend_privs[COGL_PIPELINE_FRAGEND_ARBFP] = priv;
pipeline->fragend_priv_set_mask |= COGL_PIPELINE_FRAGEND_ARBFP_MASK;
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
else
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
pipeline->fragend_priv_set_mask &= ~COGL_PIPELINE_FRAGEND_ARBFP_MASK;
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
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
static ArbfpProgramState *
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
get_arbfp_program_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
{
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
CoglPipelineFragendARBfpPrivate *priv = get_arbfp_priv (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
if (!priv)
return NULL;
return priv->arbfp_program_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
}
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
{
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
CoglPipelineFragendARBfpPrivate *priv;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *authority;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
CoglPipelineFragendARBfpPrivate *authority_priv;
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
ArbfpProgramState *arbfp_program_state;
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
*/
cogl: Adds a COGL_FEATURE_SHADERS_ARBFP feature flag This adds a public feature flag for ARBfp so developers can determine if the cogl API supports ARBfp or not.
2010-08-05 05:59:03 -04:00
if (!cogl_features_available (COGL_FEATURE_SHADERS_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 */
material: route fogging state through CoglMaterial Previously cogl_set_fog would cause a flush of the Cogl journal and would directly bang the GL state machine to setup fogging. As part of the ongoing effort to track most state in CoglMaterial to support renderlists this now adds an indirection so that cogl_set_fog now just updates ctx->legacy_fog_state. The fogging state then gets enabled as a legacy override similar to how the old depth testing API is handled.
2010-07-06 15:18:26 -04:00
if (ctx->legacy_fog_state.enabled)
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
/* Now lookup our ARBfp backend private state (allocating if
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
* necessary) */
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
priv = get_arbfp_priv (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
if (!priv)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
priv = g_slice_new0 (CoglPipelineFragendARBfpPrivate);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
set_arbfp_priv (pipeline, priv);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
}
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 have a valid arbfp_program_state pointer then we are all
* set and don't need to generate a new program. */
if (priv->arbfp_program_state)
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,
COGL_PIPELINE_STATE_AFFECTS_FRAGMENT_CODEGEN &
~COGL_PIPELINE_STATE_LAYERS,
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
COGL_PIPELINE_LAYER_STATE_AFFECTS_FRAGMENT_CODEGEN);
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
authority_priv = get_arbfp_priv (authority);
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 (authority_priv &&
authority_priv->arbfp_program_state)
{
/* If we are going to share our program state with an arbfp-authority
* then steal a reference to the program state associated with that
* arbfp-authority... */
priv->arbfp_program_state =
arbfp_program_state_ref (authority_priv->arbfp_program_state);
return TRUE;
}
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 (!authority_priv)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
authority_priv = g_slice_new0 (CoglPipelineFragendARBfpPrivate);
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
set_arbfp_priv (authority, authority_priv);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
}
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
* program in the arbfp_cache. */
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 (G_LIKELY (!(cogl_debug_flags & 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
{
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_program_state = g_hash_table_lookup (ctx->arbfp_cache, authority);
if (arbfp_program_state)
{
priv->arbfp_program_state =
arbfp_program_state_ref (arbfp_program_state);
/* 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... */
if (authority_priv != priv)
authority_priv->arbfp_program_state =
arbfp_program_state_ref (arbfp_program_state);
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
}
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 still haven't found an existing program then start
* generating code for a new program...
*/
arbfp_program_state = arbfp_program_state_new (n_layers);
priv->arbfp_program_state = arbfp_program_state_ref (arbfp_program_state);
/* Since we have already resolved the arbfp-authority at this point we might
* as well also associate any program we generate with the authority too...
*/
if (authority_priv != priv)
authority_priv->arbfp_program_state =
arbfp_program_state_ref (arbfp_program_state);
arbfp_program_state->user_program = user_program;
if (user_program == COGL_INVALID_HANDLE)
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: 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
int i;
/* We reuse a single grow-only GString for code-gen */
cogl-pipeline: Rename the fragment_{source,header}_buffer to codegen We want to reuse the same buffers for vertends so calling them fragment_* doesn't make sense.
2010-12-02 13:05:22 -05:00
g_string_set_size (ctx->codegen_source_buffer, 0);
arbfp_program_state->source = ctx->codegen_source_buffer;
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
g_string_append (arbfp_program_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");
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
/* At the end of code-gen we'll add the program to a cache and
* we'll use the authority pipeline as the basis for key into
* that cache... */
arbfp_program_state->arbfp_authority = authority;
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
for (i = 0; i < n_layers; i++)
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
{
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_program_state->unit_state[i].sampled = FALSE;
arbfp_program_state->unit_state[i].dirty_combine_constant = FALSE;
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
}
arbfp: initialize arbfp_program_state->next_constant_id When allocating a new ArbfpProgramState struct when starting code generation we weren't initializing arbfp_program_state->next_constant_id to 0.
2010-12-08 11:27:57 -05:00
arbfp_program_state->next_constant_id = 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
}
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
}
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
unsigned int
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_hash (const void *data)
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
{
unsigned long fragment_state =
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_AFFECTS_FRAGMENT_CODEGEN;
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
unsigned long layer_fragment_state =
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_LAYER_STATE_AFFECTS_FRAGMENT_CODEGEN;
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
return _cogl_pipeline_hash ((CoglPipeline *)data,
fragment_state, layer_fragment_state,
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
0);
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
}
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_equal (const void *a, const void *b)
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
{
unsigned long fragment_state =
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_AFFECTS_FRAGMENT_CODEGEN;
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
unsigned long layer_fragment_state =
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_LAYER_STATE_AFFECTS_FRAGMENT_CODEGEN;
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
return _cogl_pipeline_equal ((CoglPipeline *)a, (CoglPipeline *)b,
fragment_state, layer_fragment_state,
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
0);
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
}
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)
{
#ifndef HAVE_COGL_GLES2
if (gl_target == GL_TEXTURE_1D)
return "1D";
else
#endif
if (gl_target == GL_TEXTURE_2D)
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
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
setup_texture_source (ArbfpProgramState *arbfp_program_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)
{
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 (!arbfp_program_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
{
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
g_string_append_printf (arbfp_program_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
"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));
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
arbfp_program_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
{
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
ArbfpProgramState *arbfp_program_state = get_arbfp_program_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);
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_texture_get_gl_texture (texture, NULL, &gl_target);
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
setup_texture_source (arbfp_program_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);
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
UnitState *unit_state = &arbfp_program_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
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->constant_id = arbfp_program_state->next_constant_id++;
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);
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_texture_get_gl_texture (texture, NULL, &gl_target);
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
setup_texture_source (arbfp_program_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:
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
g_string_append_printf (arbfp_program_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);
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
append_arg (arbfp_program_state->source, arg);
g_string_append_printf (arbfp_program_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:
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
g_string_append_printf (arbfp_program_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);
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
append_arg (arbfp_program_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)
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
g_string_append_printf (arbfp_program_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
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
g_string_append_printf (arbfp_program_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 &&
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->constant_id != arg0->constant_id)
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)
{
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
ArbfpProgramState *arbfp_program_state = get_arbfp_program_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:
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
g_string_append_printf (arbfp_program_state->source,
"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] */
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
g_string_append_printf (arbfp_program_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] */
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
g_string_append_printf (arbfp_program_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:
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
g_string_append_printf (arbfp_program_state->source,
"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:
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
g_string_append_printf (arbfp_program_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);
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
append_arg (arbfp_program_state->source, &args[0]);
g_string_append (arbfp_program_state->source, ", ");
append_arg (arbfp_program_state->source, &args[1]);
g_string_append (arbfp_program_state->source, ";\n");
g_string_append_printf (arbfp_program_state->source,
"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)
*/
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
g_string_append (arbfp_program_state->source, "MAD tmp3, two, ");
append_arg (arbfp_program_state->source, &args[0]);
g_string_append (arbfp_program_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
{
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
g_string_append (arbfp_program_state->source, "MAD tmp4, two, ");
append_arg (arbfp_program_state->source, &args[1]);
g_string_append (arbfp_program_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";
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
g_string_append_printf (arbfp_program_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) */
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
g_string_append_printf (arbfp_program_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);
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
append_arg (arbfp_program_state->source, &args[2]);
g_string_append (arbfp_program_state->source, ", ");
append_arg (arbfp_program_state->source, &args[0]);
g_string_append (arbfp_program_state->source, ", ");
append_arg (arbfp_program_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);
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
g_string_append_printf (arbfp_program_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)
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
append_arg (arbfp_program_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)
{
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
g_string_append (arbfp_program_state->source, ", ");
append_arg (arbfp_program_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
}
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
g_string_append (arbfp_program_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)
{
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
ArbfpProgramState *arbfp_program_state = get_arbfp_program_state (pipeline);
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.
*/
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 (!arbfp_program_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;
Move need_texture_combine_separate to cogl-pipeline need_texture_combine_separate is moved to cogl-pipeline.c and renamed to _cogl_pipeline_need_texture_combine_separate. The function is needed by both the ARBfp and GLSL codegen backends so it makes sense to share it.
2010-11-19 10:42:26 -05:00
if (!_cogl_pipeline_need_texture_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
{
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
ArbfpProgramState *arbfp_program_state = get_arbfp_program_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-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 (!arbfp_program_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;
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
g_string_append (arbfp_program_state->source,
"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;
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
ArbfpProgramState *arbfp_program_state;
} 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;
ArbfpProgramState *arbfp_program_state = state->arbfp_program_state;
UnitState *unit_state = &arbfp_program_state->unit_state[state->unit++];
_COGL_GET_CONTEXT (ctx, FALSE);
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
if (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);
GE (glProgramLocalParameter4fv (GL_FRAGMENT_PROGRAM_ARB,
unit_state->constant_id,
constant));
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
{
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
ArbfpProgramState *arbfp_program_state = get_arbfp_program_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);
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 (arbfp_program_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
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
g_string_append (arbfp_program_state->source,
"MOV result.color,output;\n");
g_string_append (arbfp_program_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
if (G_UNLIKELY (cogl_debug_flags & COGL_DEBUG_SHOW_SOURCE))
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
g_message ("pipeline program:\n%s", arbfp_program_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
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
GE (glGenPrograms (1, &arbfp_program_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
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
GE (glBindProgram (GL_FRAGMENT_PROGRAM_ARB,
arbfp_program_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
while ((gl_error = glGetError ()) != GL_NO_ERROR)
;
glProgramString (GL_FRAGMENT_PROGRAM_ARB,
GL_PROGRAM_FORMAT_ASCII_ARB,
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
arbfp_program_state->source->len,
arbfp_program_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
if (glGetError () != GL_NO_ERROR)
{
g_warning ("\n%s\n%s",
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
arbfp_program_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
glGetString (GL_PROGRAM_ERROR_STRING_ARB));
}
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
arbfp_program_state->source = NULL;
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 (G_LIKELY (!(cogl_debug_flags & COGL_DEBUG_DISABLE_PROGRAM_CACHES)))
{
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
CoglPipeline *key;
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
/* XXX: I wish there was a way to insert into a GHashTable
* with a pre-calculated hash value since there is a cost to
* calculating the hash of a CoglPipeline and in this case
* we know we have already called _cogl_pipeline_hash during
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_backend_start so we could pass the
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
* value through to here to avoid hashing it again.
*/
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: Any keys referenced by the hash table need to remain
* valid all the while that there are corresponding values,
* so for now we simply make a copy of the current authority
* pipeline.
*
* FIXME: A problem with this is that our key into the cache
* may hold references to some arbitrary user textures which
* will now be kept alive indefinitly which is a shame. A
* better solution will be to derive a special "key
* pipeline" from the authority which derives from the base
* Cogl pipeline (to avoid affecting the lifetime of any
* other pipelines) and only takes a copy of the state that
* relates to the arbfp program and references small dummy
* textures instead of potentially large user textures. */
key = cogl_pipeline_copy (arbfp_program_state->arbfp_authority);
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
arbfp_program_state_ref (arbfp_program_state);
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
g_hash_table_insert (ctx->arbfp_cache, key, arbfp_program_state);
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 (G_UNLIKELY (g_hash_table_size (ctx->arbfp_cache) > 50))
{
static gboolean seen = FALSE;
if (!seen)
g_warning ("Over 50 separate ARBfp programs have been "
"generated which is very unusual, so something "
"is probably wrong!\n");
seen = TRUE;
}
}
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
/* The authority is only valid during codegen since the program
* state may have a longer lifetime than the original authority
* it is created for. */
arbfp_program_state->arbfp_authority = 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
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 (arbfp_program_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 */
CoglProgram *program = arbfp_program_state->user_program;
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
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
gl_program = arbfp_program_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
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
GE (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
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 (arbfp_program_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;
state.arbfp_program_state = arbfp_program_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 =
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
pipeline != arbfp_program_state->last_used_for_pipeline;
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
{
CoglProgram *program = arbfp_program_state->user_program;
gboolean program_changed;
/* If the shader has changed since it was last flushed then we
need to update all uniforms */
program_changed = program->age != arbfp_program_state->user_program_age;
_cogl_program_flush_uniforms (program, gl_program, program_changed);
arbfp_program_state->user_program_age = program->age;
}
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. */
arbfp_program_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;
}
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
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
dirty_arbfp_program_state (CoglPipeline *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
{
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
CoglPipelineFragendARBfpPrivate *priv;
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
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
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: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
priv = get_arbfp_priv (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
if (!priv)
return;
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
if (priv->arbfp_program_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
{
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
arbfp_program_state_unref (priv->arbfp_program_state);
priv->arbfp_program_state = 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 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)
{
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
if ((change & COGL_PIPELINE_STATE_AFFECTS_FRAGMENT_CODEGEN))
dirty_arbfp_program_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
{
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
CoglPipelineFragendARBfpPrivate *priv = get_arbfp_priv (owner);
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
if (!priv)
return;
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
if ((change & COGL_PIPELINE_LAYER_STATE_AFFECTS_FRAGMENT_CODEGEN))
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
{
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
dirty_arbfp_program_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: don't dereference NULL program state This avoid dereferencing a NULL arbfp program state in _cogl_pipeline_backend_arbfp_layer_pre_change_notify for _STATE_COMBINE_CONSTANT changes.
2010-12-08 13:57:42 -05:00
ArbfpProgramState *arbfp_program_state = get_arbfp_program_state (owner);
if (arbfp_program_state)
{
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
arbfp_program_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;
}
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_free_priv (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
{
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
CoglPipelineFragendARBfpPrivate *priv = get_arbfp_priv (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
if (priv)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
{
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 (priv->arbfp_program_state)
arbfp_program_state_unref (priv->arbfp_program_state);
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
g_slice_free (CoglPipelineFragendARBfpPrivate, priv);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
set_arbfp_priv (pipeline, 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
}
}
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,
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_pipeline_fragend_arbfp_free_priv
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
};
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#endif /* COGL_PIPELINE_FRAGEND_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