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

1219 lines
38 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
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
#ifdef COGL_PIPELINE_BACKEND_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_GLES2
#include "../gles/cogl-gles2-wrapper.h"
#endif
#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
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
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;
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
typedef struct _CoglPipelineBackendARBfpPrivate
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;
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
} CoglPipelineBackendARBfpPrivate;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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
const CoglPipelineBackend _cogl_pipeline_arbfp_backend;
material: don't declare backend vtables in headers This fixes the material backends to declare their constant vtable in the c file with a corresponding extern declaration in the header. This should fix complaints about duplicate symbols seen on OSX.
2010-09-14 07:13:30 -04:00
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);
}
}
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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 int
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_backend_arbfp_get_max_texture_units (void)
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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 _cogl_get_max_texture_image_units ();
}
typedef struct
{
int i;
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 **layers;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
} AddLayersToArrayState;
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
add_layer_to_array_cb (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
void *user_data)
{
AddLayersToArrayState *state = user_data;
state->layers[state->i++] = layer;
return TRUE;
}
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
layers_arbfp_would_differ (CoglPipelineLayer **pipeline0_layers,
CoglPipelineLayer **pipeline1_layers,
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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)
{
int i;
/* The layer state that affects arbfp codegen... */
unsigned long arbfp_codegen_modifiers =
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_LAYER_STATE_COMBINE |
COGL_PIPELINE_LAYER_STATE_UNIT;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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 (i = 0; i < n_layers; i++)
{
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 *layer0 = pipeline0_layers[i];
CoglPipelineLayer *layer1 = pipeline1_layers[i];
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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 layer_differences;
if (layer0 == layer1)
continue;
layer_differences =
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_layer_compare_differences (layer0, layer1);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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 (layer_differences & arbfp_codegen_modifiers)
{
/* When it comes to texture differences the only thing that
* affects the arbfp is the target enum... */
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 (layer_differences == COGL_PIPELINE_LAYER_STATE_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
{
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
CoglHandle tex0 = _cogl_pipeline_layer_get_texture (layer0);
CoglHandle tex1 = _cogl_pipeline_layer_get_texture (layer1);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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_target0;
GLenum gl_target1;
cogl_texture_get_gl_texture (tex0, NULL, &gl_target0);
cogl_texture_get_gl_texture (tex1, NULL, &gl_target1);
if (gl_target0 == gl_target1)
continue;
}
return TRUE;
}
}
return FALSE;
}
/* This tries to find the oldest ancestor whos state would generate
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 arbfp program as the current pipeline. This is a 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
* mechanism for reducing the number of arbfp programs we have to
* generate.
*/
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
static CoglPipeline *
find_arbfp_authority (CoglPipeline *pipeline, 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: 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 *authority0;
CoglPipeline *authority1;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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;
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 **authority0_layers;
CoglPipelineLayer **authority1_layers;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
/* XXX: we'll need to update this when we add fog support to the
* arbfp codegen */
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
if (user_program != COGL_INVALID_HANDLE)
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
return 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
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
/* Find the first pipeline that modifies state that affects the
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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 codegen... */
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
authority0 = _cogl_pipeline_get_authority (pipeline,
COGL_PIPELINE_STATE_LAYERS);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
/* Find the next ancestor after that, that also modifies state
* affecting arbfp codegen... */
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_get_parent (authority0))
material: use common node type for materials and layers Since 365605cf42, materials and layers are represented in a tree structure that allows traversing up through parents and iterating down through children. This re-works the related typedefs and reparenting code so that they can be shared.
2010-07-08 06:49:31 -04:00
{
authority1 =
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_authority (_cogl_pipeline_get_parent (authority0),
COGL_PIPELINE_STATE_LAYERS);
material: use common node type for materials and layers Since 365605cf42, materials and layers are represented in a tree structure that allows traversing up through parents and iterating down through children. This re-works the related typedefs and reparenting code so that they can be shared.
2010-07-08 06:49:31 -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
return authority0;
n_layers = authority0->n_layers;
for (;;)
{
AddLayersToArrayState state;
if (authority0->n_layers != authority1->n_layers)
return authority0;
authority0_layers =
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_alloca (sizeof (CoglPipelineLayer *) * n_layers);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
state.i = 0;
state.layers = authority0_layers;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
_cogl_pipeline_foreach_layer_internal (authority0,
material: Adds experimental cogl_material_foreach_layer API This adds a way to iterate the layer indices of the given material since cogl_material_get_layers has been deprecated. The user provides a callback to be called once for each layer. Because modification of layers in the callback may potentially invalidate any number of the internal CoglMaterialLayer structures and invalidate the material's layer cache this should be more robust than cogl_material_get_layers() which used to return a const GList * pointing directly to internal state.
2010-07-05 16:33:26 -04:00
add_layer_to_array_cb,
&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
authority1_layers =
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_alloca (sizeof (CoglPipelineLayer *) * n_layers);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{glsl,arbfp,fixed}.c files in an effort to help and keep cogl-material.c maintainable.
2010-06-15 11:44:52 -04:00
state.i = 0;
state.layers = authority1_layers;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
_cogl_pipeline_foreach_layer_internal (authority1,
material: Adds experimental cogl_material_foreach_layer API This adds a way to iterate the layer indices of the given material since cogl_material_get_layers has been deprecated. The user provides a callback to be called once for each layer. Because modification of layers in the callback may potentially invalidate any number of the internal CoglMaterialLayer structures and invalidate the material's layer cache this should be more robust than cogl_material_get_layers() which used to return a const GList * pointing directly to internal state.
2010-07-05 16:33:26 -04:00
add_layer_to_array_cb,
&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
if (layers_arbfp_would_differ (authority0_layers, authority1_layers,
n_layers))
return authority0;
/* Find the next ancestor after that, that also modifies state
* affecting arbfp codegen... */
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_get_parent (authority1))
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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;
authority0 = authority1;
material: use common node type for materials and layers Since 365605cf42, materials and layers are represented in a tree structure that allows traversing up through parents and iterating down through children. This re-works the related typedefs and reparenting code so that they can be shared.
2010-07-08 06:49:31 -04:00
authority1 =
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_authority (_cogl_pipeline_get_parent (authority1),
COGL_PIPELINE_STATE_LAYERS);
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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 (authority1 == authority0)
break;
}
return authority1;
}
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
static CoglPipelineBackendARBfpPrivate *
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
{
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 (!(pipeline->backend_priv_set_mask & COGL_PIPELINE_BACKEND_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;
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
return pipeline->backend_privs[COGL_PIPELINE_BACKEND_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
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 (CoglPipeline *pipeline, CoglPipelineBackendARBfpPrivate *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
{
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->backend_privs[COGL_PIPELINE_BACKEND_ARBFP] = priv;
pipeline->backend_priv_set_mask |= COGL_PIPELINE_BACKEND_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
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->backend_priv_set_mask &= ~COGL_PIPELINE_BACKEND_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
{
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
CoglPipelineBackendARBfpPrivate *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
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_backend_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,
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
CoglPipelineBackendARBfpPrivate *priv;
CoglPipeline *authority;
CoglPipelineBackendARBfpPrivate *authority_priv;
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: 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
if (user_program != COGL_INVALID_HANDLE &&
_cogl_program_get_language (user_program) != COGL_SHADER_LANGUAGE_ARBFP)
return FALSE;
/* 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
{
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 = g_slice_new0 (CoglPipelineBackendARBfpPrivate);
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: 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
authority = find_arbfp_authority (pipeline, user_program);
material-arbfp: Another pass at simplifying the code Previously the backend private state was used to either link to an authority material or provide authoritative program state. The mechanism seemed overly complex and felt very fragile. I made a recent comment which added a lot of documentation to make it easier to understand but still it didn't feel very elegant. This patch takes a slightly different approach; we now have a ref-counted ArbfpProgramState object which encapsulates a single ARBfp program and the backend private state now just has a single member which is a pointer to one of these arbfp_program_state objects. We no longer need to cache pointers to our arbfp-authority and so we can get rid of a lot of awkward code that ensured these pointers were updated/invalidated at the right times. The program state objects are not tightly bound to a material so it will also allow us to later implement a cache mechanism that lets us share state outside a materials ancestry. This may help to optimize code not following the recommendations of deriving materials from templates, avoiding one-shot materials and not repeatedly modifying materials because even if a material's ancestry doesn't naturally lead us to shareable state we can fallback to searching for shareable state using central hash tables.
2010-09-14 13:50:50 -04:00
authority_priv = get_arbfp_priv (authority);
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
{
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
authority_priv = g_slice_new0 (CoglPipelineBackendARBfpPrivate);
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
}
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 existing program associated with the
* arbfp-authority then start generating code for a new 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
*/
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->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
{
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 =
arbfp_program_state_new (n_layers);
authority_priv->arbfp_program_state = arbfp_program_state;
arbfp_program_state->user_program = user_program;
if (user_program == COGL_INVALID_HANDLE)
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
{
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 i;
/* We reuse a single grow-only GString for ARBfp code-gen */
g_string_set_size (ctx->arbfp_source_buffer, 0);
arbfp_program_state->source = ctx->arbfp_source_buffer;
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");
for (i = 0; i < n_layers; i++)
{
arbfp_program_state->unit_state[i].sampled = FALSE;
arbfp_program_state->unit_state[i].dirty_combine_constant = FALSE;
}
arbfp_program_state->next_constant_id = 0;
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
}
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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
/* Finally, if the pipeline isn't actually its own arbfp-authority
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
* then steal a reference to the program state associated with the
* arbfp-authority... */
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 (authority != 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
priv->arbfp_program_state =
arbfp_program_state_ref (authority_priv->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
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
}
/* Determines if we need to handle the RGB and A texture combining
* separately or is the same function used for both channel masks and
* with the same arguments...
*/
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
need_texture_combine_separate (CoglPipelineLayer *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
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
int n_args;
int i;
if (big_state->texture_combine_rgb_func !=
big_state->texture_combine_alpha_func)
return TRUE;
n_args = _cogl_get_n_args_for_combine_func (big_state->texture_combine_rgb_func);
for (i = 0; i < n_args; i++)
{
if (big_state->texture_combine_rgb_src[i] !=
big_state->texture_combine_alpha_src[i])
return TRUE;
/*
* We can allow some variation of the source operands without
* needing a separation...
*
* "A = REPLACE (CONSTANT[A])" + either of the following...
* "RGB = REPLACE (CONSTANT[RGB])"
* "RGB = REPLACE (CONSTANT[A])"
*
* can be combined as:
* "RGBA = REPLACE (CONSTANT)" or
* "RGBA = REPLACE (CONSTANT[A])" or
*
* And "A = REPLACE (1-CONSTANT[A])" + either of the following...
* "RGB = REPLACE (1-CONSTANT)" or
* "RGB = REPLACE (1-CONSTANT[A])"
*
* can be combined as:
* "RGBA = REPLACE (1-CONSTANT)" or
* "RGBA = REPLACE (1-CONSTANT[A])"
*/
switch (big_state->texture_combine_alpha_op[i])
{
case GL_SRC_ALPHA:
switch (big_state->texture_combine_rgb_op[i])
{
case GL_SRC_COLOR:
case GL_SRC_ALPHA:
break;
default:
return FALSE;
}
break;
case GL_ONE_MINUS_SRC_ALPHA:
switch (big_state->texture_combine_rgb_op[i])
{
case GL_ONE_MINUS_SRC_COLOR:
case GL_ONE_MINUS_SRC_ALPHA:
break;
default:
return FALSE;
}
break;
default:
return FALSE; /* impossible */
}
}
return FALSE;
}
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
}
}
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
typedef enum _CoglPipelineBackendARBfpArgType
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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
COGL_PIPELINE_BACKEND_ARBFP_ARG_TYPE_SIMPLE,
COGL_PIPELINE_BACKEND_ARBFP_ARG_TYPE_CONSTANT,
COGL_PIPELINE_BACKEND_ARBFP_ARG_TYPE_TEXTURE
} CoglPipelineBackendARBfpArgType;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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
typedef struct _CoglPipelineBackendARBfpArg
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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;
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
CoglPipelineBackendARBfpArgType 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;
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
} CoglPipelineBackendARBfpArg;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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_arg (GString *source, const CoglPipelineBackendARBfpArg *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)
{
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
case COGL_PIPELINE_BACKEND_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;
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
case COGL_PIPELINE_BACKEND_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;
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
case COGL_PIPELINE_BACKEND_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
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
* CoglPipelineBackendARBfpArg 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,
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
CoglPipelineBackendARBfpArg *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)
{
case GL_TEXTURE:
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->type = COGL_PIPELINE_BACKEND_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;
case GL_CONSTANT:
{
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
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->type = COGL_PIPELINE_BACKEND_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;
}
case GL_PRIMARY_COLOR:
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->type = COGL_PIPELINE_BACKEND_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;
case GL_PREVIOUS:
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->type = COGL_PIPELINE_BACKEND_ARBFP_ARG_TYPE_SIMPLE;
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 */
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->type = COGL_PIPELINE_BACKEND_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)
{
case GL_SRC_COLOR:
break;
case GL_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");
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->type = COGL_PIPELINE_BACKEND_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;
case GL_SRC_ALPHA:
/* 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;
case GL_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");
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->type = COGL_PIPELINE_BACKEND_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
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
backend_arbfp_args_equal (CoglPipelineBackendARBfpArg *arg0,
CoglPipelineBackendARBfpArg *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;
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 (arg0->type == COGL_PIPELINE_BACKEND_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. */
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 (arg0->type == COGL_PIPELINE_BACKEND_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,
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
CoglPipelineBackendARBfpArg *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)
{
case GL_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;
case GL_MODULATE:
/* 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;
case GL_REPLACE:
/* 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;
case GL_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;
case GL_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;
case GL_DOT3_RGB:
/* 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.
*/
case GL_DOT3_RGBA:
{
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
if (!backend_arbfp_args_equal (&args[0], &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, "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;
case GL_INTERPOLATE:
/* 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,
GLint function,
GLint *src,
GLint *op)
{
int i;
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
CoglPipelineBackendARBfpArg 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
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_backend_arbfp_add_layer (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
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;
if (!need_texture_combine_separate (combine_authority))
{
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 if (big_state->texture_combine_rgb_func == GL_DOT3_RGBA)
{
/* 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
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_backend_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
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_backend_arbfp_end (CoglPipeline *pipeline,
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;
COGL_STATIC_COUNTER (backend_arbfp_compile_counter,
"arbfp compile counter",
"Increments each time a new ARBfp "
"program is compiled",
0 /* no application private data */);
COGL_COUNTER_INC (_cogl_uprof_context, backend_arbfp_compile_counter);
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;
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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: 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_use_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
{
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
CoglPipelineBackendARBfpPrivate *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
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_backend_arbfp_pipeline_pre_change_notify (
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)
{
static const unsigned long fragment_op_changes =
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_STATE_LAYERS |
COGL_PIPELINE_STATE_USER_SHADER;
/* TODO: COGL_PIPELINE_STATE_FOG */
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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
if (!(change & fragment_op_changes))
cogl: Allow setting ARBfp source on a CoglShader This makes CoglProgram/Shader automatically detect when the user has given an ARBfp program by checking for "!!ARBfp1.0" at the beginning of the user's source. ARBfp local parameters can be set with cogl_program_uniform_float assuming you pass a @size of 4 (all ARBfp program.local parameters are vectors of 4 floats). This doesn't expose ARBfp environment parameters or double precision local parameters.
2010-08-04 12:53:51 -04:00
return;
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 (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
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_backend_arbfp_layer_pre_change_notify (
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
{
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
CoglPipelineBackendARBfpPrivate *priv;
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
static const unsigned long not_fragment_op_changes =
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_LAYER_STATE_COMBINE_CONSTANT |
COGL_PIPELINE_LAYER_STATE_TEXTURE;
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
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
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;
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
if (!(change & not_fragment_op_changes))
{
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
{
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 =
get_arbfp_program_state (owner);
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
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
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_backend_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
{
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
CoglPipelineBackendARBfpPrivate *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);
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_slice_free (CoglPipelineBackendARBfpPrivate, priv);
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
}
}
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
const CoglPipelineBackend _cogl_pipeline_arbfp_backend =
material: Split the fragment processing backends out This splits the fragment processing backends (glsl, arbfp and fixed) out from cogl-material.c into their own cogl-material-{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
_cogl_pipeline_backend_arbfp_get_max_texture_units,
_cogl_pipeline_backend_arbfp_start,
_cogl_pipeline_backend_arbfp_add_layer,
_cogl_pipeline_backend_arbfp_passthrough,
_cogl_pipeline_backend_arbfp_end,
_cogl_pipeline_backend_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,
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_backend_arbfp_layer_pre_change_notify,
_cogl_pipeline_backend_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
NULL
};
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
#endif /* COGL_PIPELINE_BACKEND_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