brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
18486a6aa9
mutter/cogl/driver/gl/cogl-pipeline-opengl.c

1474 lines
50 KiB
C
Raw Normal View History

material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -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>
*/
#include "config.h"
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"
Remove cogl-internal.h This remove cogl-internal.h in favour of using cogl-private.h. Some things in cogl-internal.h were moved to driver/gl/cogl-util-gl-private.h and the _cogl_gl_error_to_string function whose prototype was moved from cogl-internal.h to cogl-util-gl-private.h has had its implementation moved from cogl.c to cogl-util-gl.c Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 01cc82ece091aa3bec4c07fdd6bc9e5135fca573)
2013-01-20 13:47:40 -05:00
#include "cogl-util-gl-private.h"
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
#include "cogl-pipeline-opengl-private.h"
#include "cogl-pipeline-private.h"
cogl: rename cogl-context.h cogl-context-private.h Since we plan to add public cogl_context_* API we need to rename the current cogl-context.h which contains private member details.
2010-11-04 18:25:52 -04:00
#include "cogl-context-private.h"
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#include "cogl-texture-private.h"
framebuffer: split out CoglOnscreen code This factors out the CoglOnscreen code from cogl-framebuffer.c so we now have cogl-onscreen.c, cogl-onscreen.h and cogl-onscreen-private.h. Notably some of the functions pulled out are currently namespaced as cogl_framebuffer but we know we are planning on renaming them to be in the cogl_onscreen namespace; such as cogl_framebuffer_swap_buffers(). Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-13 16:31:04 -04:00
#include "cogl-framebuffer-private.h"
Remove all internal includes of cogl.h The cogl.h header is meant to be the public header for including the 1.x api used by Clutter so we should stop using that as a convenient way to include all likely prototypes and typedefs. Actually we already do a good job of listing the specific headers we depend on in each of the .c files we have so mostly this patch just strip out the redundant includes for cogl.h with a few fixups where that broke the build. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-17 20:19:17 -05:00
#include "cogl-offscreen.h"
moves some gl texture code too cogl-texture-gl.c This adds a driver/gl/cogl-texture-gl.c file and moves some gl specific bits from cogl-texture.c into it. The moved symbols were also given a _gl_ infix and the calling code was updated accordingly. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 2c9e81de70cc02d72b1ce9013c49e39300a05b6a)
2012-11-08 18:00:49 -05:00
#include "cogl-texture-gl-private.h"
build: Start moving to a non-recursive layout *** WARNING: THIS COMMIT CHANGES THE BUILD *** Do not recurse into the backend directories to build private, internal libraries. We only recurse from clutter/ into the cogl sub-directory; from there, we don't recurse any further. All the backend-specific code in Cogl and Clutter is compiled conditionally depending on the macros defined by the configure script. We still recurse from the top-level directory into doc, clutter and tests, because gtk-doc and tests do not deal nicely with non-recursive layouts. This change makes Clutter compile slightly faster, and cleans up the build system, especially when dealing with introspection data. Ideally, we also want to make Cogl part of the top-level build, so that we can finally drop the sed trick to change the shared library from the GIR before compiling it. Currently disabled: ‣ OSX backend ‣ Fruity backend Currently enabled but untested: ‣ EGL backend ‣ Windows backend
2010-09-13 06:30:30 -04:00
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
#include "cogl-pipeline-progend-glsl-private.h"
tests: Adds our first white-box unit test This adds a white-box unit test that verifies that GL_BLEND is disabled when drawing an opaque rectangle, enabled when drawing a transparent rectangle and then disabled again when drawing a transparent rectangle but with a blend string that effectively disables blending. This shares the test utilities and launcher infrastructure we are using for conformance tests so we get consistent reporting and so unit tests will be run against a range of different drivers. This adds a --enable-unit-tests configure option which is enabled by default but if disabled will make all UNIT_TESTS() into static inline functions that we should expect the compiler to discard since they won't be referenced by anything. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 9047cce06bbf9051ec77e622be2fdbb96ed767a8)
2013-05-30 08:22:22 -04:00
#include <test-fixtures/test-unit.h>
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#include <glib.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: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*/
/* These aren't defined in the GLES headers */
#ifndef GL_POINT_SPRITE
#define GL_POINT_SPRITE 0x8861
#endif
#ifndef GL_COORD_REPLACE
#define GL_COORD_REPLACE 0x8862
#endif
#ifndef GL_CLAMP_TO_BORDER
#define GL_CLAMP_TO_BORDER 0x812d
#endif
Add support for per-vertex point sizes This adds a new function to enable per-vertex point size on a pipeline. This can be set with cogl_pipeline_set_per_vertex_point_size(). Once enabled the point size can be set either by drawing with an attribute named 'cogl_point_size_in' or by writing to the 'cogl_point_size_out' builtin from a snippet. There is a feature flag which must be checked for before using per-vertex point sizes. This will only be set on GL >= 2.0 or on GLES 2.0. GL will only let you set a per-vertex point size from GLSL by writing to gl_PointSize. This is only available in GL2 and not in the older GLSL extensions. The per-vertex point size has its own pipeline state flag so that it can be part of the state that affects vertex shader generation. Having to enable the per vertex point size with a separate function is a bit awkward. Ideally it would work like the color attribute where you can just set it for every vertex in your primitive with cogl_pipeline_set_color or set it per-vertex by just using the attribute. This is harder to get working with the point size because we need to generate a different vertex shader depending on what attributes are bound. I think if we wanted to make this work transparently we would still want to internally have a pipeline property describing whether the shader was generated with per-vertex support so that it would work with the shader cache correctly. Potentially we could make the per-vertex property internal and automatically make a weak pipeline whenever the attribute is bound. However we would then also need to automatically detect when an application is writing to cogl_point_size_out from a snippet. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 8495d9c1c15ce389885a9356d965eabd97758115) Conflicts: cogl/cogl-context.c cogl/cogl-pipeline-private.h cogl/cogl-pipeline.c cogl/cogl-private.h cogl/driver/gl/cogl-pipeline-progend-fixed.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c
2012-11-08 11:56:02 -05:00
#ifndef GL_PROGRAM_POINT_SIZE
#define GL_PROGRAM_POINT_SIZE 0x8642
#endif
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
static void
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
texture_unit_init (CoglContext *ctx,
CoglTextureUnit *unit,
int index_)
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
{
unit->index = index_;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->enabled_gl_target = 0;
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->gl_texture = 0;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->gl_target = 0;
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->is_foreign = FALSE;
unit->dirty_gl_texture = FALSE;
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
unit->matrix_stack = cogl_matrix_stack_new (ctx);
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->layer = NULL;
unit->layer_changes_since_flush = 0;
unit->texture_storage_changed = FALSE;
}
static void
texture_unit_free (CoglTextureUnit *unit)
{
if (unit->layer)
cogl_object_unref (unit->layer);
cogl-matrix-stack: Convert to be a CoglObject We will want to use ref-counting on the CoglMatrixStack so it might as well be a CoglObject.
2010-12-10 11:06:16 -05:00
cogl_object_unref (unit->matrix_stack);
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
}
CoglTextureUnit *
_cogl_get_texture_unit (int index_)
{
_COGL_GET_CONTEXT (ctx, NULL);
if (ctx->texture_units->len < (index_ + 1))
{
int i;
int prev_len = ctx->texture_units->len;
ctx->texture_units = g_array_set_size (ctx->texture_units, index_ + 1);
for (i = prev_len; i <= index_; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
matrix-stack: make CoglMatrixStack public We have found several times now when writing code using Cogl that it would really help if Cogl's matrix stack api was public as a utility api. In Rig for example we want to avoid redundant arithmetic when deriving the matrices of entities used to render and we aren't able to simply use the framebuffer's matrix stack to achieve this. Also when implementing cairo-cogl we found that it would be really useful if we could have a matrix stack utility api. (cherry picked from commit d17a01fd935d88fab96fe6cc0b906c84026c0067)
2012-11-20 12:08:43 -05:00
texture_unit_init (ctx, unit, i);
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
}
}
return &g_array_index (ctx->texture_units, CoglTextureUnit, index_);
}
void
_cogl_destroy_texture_units (void)
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
texture_unit_free (unit);
}
g_array_free (ctx->texture_units, TRUE);
}
void
_cogl_set_active_texture_unit (int unit_index)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (ctx->active_texture_unit != unit_index)
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glActiveTexture (GL_TEXTURE0 + unit_index));
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
ctx->active_texture_unit = unit_index;
}
}
/* Note: _cogl_bind_gl_texture_transient conceptually has slightly
* different semantics to OpenGL's glBindTexture because Cogl never
* cares about tracking multiple textures bound to different targets
* on the same texture unit.
*
* glBindTexture lets you bind multiple textures to a single texture
* unit if they are bound to different targets. So it does something
* like:
* unit->current_texture[target] = texture;
*
* Cogl only lets you associate one texture with the currently active
* texture unit, so the target is basically a redundant parameter
* that's implicitly set on that texture.
*
* Technically this is just a thin wrapper around glBindTexture so
* actually it does have the GL semantics but it seems worth
* mentioning the conceptual difference in case anyone wonders why we
* don't associate the gl_texture with a gl_target in the
* CoglTextureUnit.
*/
void
_cogl_bind_gl_texture_transient (GLenum gl_target,
GLuint gl_texture,
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool is_foreign)
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
{
CoglTextureUnit *unit;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* We choose to always make texture unit 1 active for transient
* binds so that in the common case where multitexturing isn't used
* we can simply ignore the state of this texture unit. Notably we
* didn't use a large texture unit (.e.g. (GL_MAX_TEXTURE_UNITS - 1)
* in case the driver doesn't have a sparse data structure for
* texture units.
*/
_cogl_set_active_texture_unit (1);
unit = _cogl_get_texture_unit (1);
/* NB: If we have previously bound a foreign texture to this texture
* unit we don't know if that texture has since been deleted and we
* are seeing the texture name recycled */
if (unit->gl_texture == gl_texture &&
!unit->dirty_gl_texture &&
!unit->is_foreign)
return;
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindTexture (gl_target, gl_texture));
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->dirty_gl_texture = TRUE;
unit->is_foreign = is_foreign;
}
void
_cogl_delete_gl_texture (GLuint gl_texture)
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
if (unit->gl_texture == gl_texture)
{
unit->gl_texture = 0;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->gl_target = 0;
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->dirty_gl_texture = FALSE;
}
}
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDeleteTextures (1, &gl_texture));
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
}
/* Whenever the underlying GL texture storage of a CoglTexture is
* changed (e.g. due to migration out of a texture atlas) then we are
* notified. This lets us ensure that we reflush that texture's state
material: don't dereference layer->texture directly In _cogl_material_texture_storage_change_notify we were potentially dereferencing layer->texture without checking first that it is the authority of texture state. We now use _cogl_material_layer_get_texture() instead.
2010-08-08 08:05:40 -04:00
* if it is reused again with the same texture unit.
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
*/
void
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
_cogl_pipeline_texture_storage_change_notify (CoglTexture *texture)
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
if (unit->layer &&
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_get_texture (unit->layer) == texture)
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
unit->texture_storage_changed = TRUE;
/* NB: the texture may be bound to multiple texture units so
* we continue to check the rest */
}
}
cogl-pipeline-opengl: #ifdef out set_glsl_program for GLES 1.1 glUseProgram is not available under GLES 1.1 so it was breaking the build. http://bugzilla.clutter-project.org/show_bug.cgi?id=2516
2011-01-17 07:20:06 -05:00
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
static void
set_glsl_program (GLuint gl_program)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (ctx->current_gl_program != gl_program)
{
GLenum gl_error;
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
while ((gl_error = ctx->glGetError ()) != GL_NO_ERROR)
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
;
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
ctx->glUseProgram (gl_program);
if (ctx->glGetError () == GL_NO_ERROR)
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
ctx->current_gl_program = gl_program;
else
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE( ctx, glUseProgram (0) );
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
ctx->current_gl_program = 0;
}
}
}
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
void
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
_cogl_use_fragment_program (GLuint gl_program, CoglPipelineProgramType type)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Avoid mixing declarations and code Mixing declarations and code causes problems for MSVC as it is a C99 feature so we should try to avoid it.
2010-10-25 08:08:52 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
/* If we're changing program type... */
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
if (type != ctx->current_fragment_program_type)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
/* ... disable the old type */
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
switch (ctx->current_fragment_program_type)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
/* If the program contains a vertex shader then we shouldn't
disable it */
if (ctx->current_vertex_program_type !=
COGL_PIPELINE_PROGRAM_TYPE_GLSL)
set_glsl_program (0);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
break;
cogl-program: gles2: bind programs lazily as for GL This makes the gles2 cogl_program_use consistent with the GL version by not binding the program immediately and instead leaving it to cogl-material.c to bind the program when actually drawing something.
2010-07-23 05:12:39 -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
case COGL_PIPELINE_PROGRAM_TYPE_ARBFP:
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
#ifdef HAVE_COGL_GL
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE( ctx, glDisable (GL_FRAGMENT_PROGRAM_ARB) );
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#endif
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
break;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
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
/* don't need to to anything */
break;
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
/* ... and enable the new type */
switch (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_PROGRAM_TYPE_ARBFP:
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
#ifdef HAVE_COGL_GL
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE( ctx, glEnable (GL_FRAGMENT_PROGRAM_ARB) );
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#endif
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
break;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
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
/* don't need to to anything */
break;
}
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 (type == COGL_PIPELINE_PROGRAM_TYPE_GLSL)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#ifdef COGL_PIPELINE_FRAGEND_GLSL
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
set_glsl_program (gl_program);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#else
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
g_warning ("Unexpected use of GLSL fragend!");
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#endif /* COGL_PIPELINE_FRAGEND_GLSL */
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#ifndef COGL_PIPELINE_FRAGEND_ARBFP
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
else if (type == COGL_PIPELINE_PROGRAM_TYPE_ARBFP)
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
g_warning ("Unexpected use of ARBFP fragend!");
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
#endif /* COGL_PIPELINE_FRAGEND_ARBFP */
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
cogl: Add a vertend to generate GLSL The GLSL vertend is mostly only useful for GLES2. The fixed function vertend is kept at higher priority than the GLSL vertend so it is unlikely to be used in any other circumstances.
2010-12-02 15:48:45 -05:00
ctx->current_fragment_program_type = type;
}
void
_cogl_use_vertex_program (GLuint gl_program, CoglPipelineProgramType type)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* If we're changing program type... */
if (type != ctx->current_vertex_program_type)
{
/* ... disable the old type */
switch (ctx->current_vertex_program_type)
{
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
/* If the program contains a fragment shader then we shouldn't
disable it */
if (ctx->current_fragment_program_type !=
COGL_PIPELINE_PROGRAM_TYPE_GLSL)
set_glsl_program (0);
break;
case COGL_PIPELINE_PROGRAM_TYPE_ARBFP:
/* It doesn't make sense to enable ARBfp for the vertex program */
g_assert_not_reached ();
break;
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
/* don't need to to anything */
break;
}
/* ... and enable the new type */
switch (type)
{
case COGL_PIPELINE_PROGRAM_TYPE_ARBFP:
/* It doesn't make sense to enable ARBfp for the vertex program */
g_assert_not_reached ();
break;
case COGL_PIPELINE_PROGRAM_TYPE_GLSL:
case COGL_PIPELINE_PROGRAM_TYPE_FIXED:
/* don't need to to anything */
break;
}
}
if (type == COGL_PIPELINE_PROGRAM_TYPE_GLSL)
{
#ifdef COGL_PIPELINE_VERTEND_GLSL
set_glsl_program (gl_program);
#else
g_warning ("Unexpected use of GLSL vertend!");
#endif /* COGL_PIPELINE_VERTEND_GLSL */
}
#ifndef COGL_PIPELINE_VERTEND_ARBFP
else if (type == COGL_PIPELINE_PROGRAM_TYPE_ARBFP)
g_warning ("Unexpected use of ARBFP vertend!");
#endif /* COGL_PIPELINE_VERTEND_ARBFP */
ctx->current_vertex_program_type = type;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#if defined(HAVE_COGL_GLES2) || defined(HAVE_COGL_GL)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
blend_factor_uses_constant (GLenum blend_factor)
{
return (blend_factor == GL_CONSTANT_COLOR ||
blend_factor == GL_ONE_MINUS_CONSTANT_COLOR ||
blend_factor == GL_CONSTANT_ALPHA ||
blend_factor == GL_ONE_MINUS_CONSTANT_ALPHA);
}
#endif
static void
Fix depth testing, write enable bug This fixes a bug in _cogl_pipeline_flush_color_blend_alpha_depth_state whereby we were only calling flush_depth_state if we knew that at least depth testing was enabled. This didn't take into account that enabling and disabling depth writing is a useful change to make even if depth testing is disabled. It also seemed a bit messy to flush the depth-testing enable separately from the other depth state. _cogl_pipeline_flush_color_blend_alpha_depth_state now simply calls flush_depth_state() if there is a _DEPTH_STATE difference and flush_depth_state() also handles flushing the depth-testing enable in along with all the other depth state. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6a9dfc55b8f55d7023cb592e5bef2118d0f3d50c)
2012-04-29 17:14:43 -04:00
flush_depth_state (CoglContext *ctx,
CoglDepthState *depth_state)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Fix depth testing, write enable bug This fixes a bug in _cogl_pipeline_flush_color_blend_alpha_depth_state whereby we were only calling flush_depth_state if we knew that at least depth testing was enabled. This didn't take into account that enabling and disabling depth writing is a useful change to make even if depth testing is disabled. It also seemed a bit messy to flush the depth-testing enable separately from the other depth state. _cogl_pipeline_flush_color_blend_alpha_depth_state now simply calls flush_depth_state() if there is a _DEPTH_STATE difference and flush_depth_state() also handles flushing the depth-testing enable in along with all the other depth state. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6a9dfc55b8f55d7023cb592e5bef2118d0f3d50c)
2012-04-29 17:14:43 -04:00
if (ctx->depth_test_enabled_cache != depth_state->test_enabled)
{
if (depth_state->test_enabled == TRUE)
GE (ctx, glEnable (GL_DEPTH_TEST));
else
GE (ctx, glDisable (GL_DEPTH_TEST));
ctx->depth_test_enabled_cache = depth_state->test_enabled;
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Fix depth testing, write enable bug This fixes a bug in _cogl_pipeline_flush_color_blend_alpha_depth_state whereby we were only calling flush_depth_state if we knew that at least depth testing was enabled. This didn't take into account that enabling and disabling depth writing is a useful change to make even if depth testing is disabled. It also seemed a bit messy to flush the depth-testing enable separately from the other depth state. _cogl_pipeline_flush_color_blend_alpha_depth_state now simply calls flush_depth_state() if there is a _DEPTH_STATE difference and flush_depth_state() also handles flushing the depth-testing enable in along with all the other depth state. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6a9dfc55b8f55d7023cb592e5bef2118d0f3d50c)
2012-04-29 17:14:43 -04:00
if (ctx->depth_test_function_cache != depth_state->test_function &&
depth_state->test_enabled == TRUE)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDepthFunc (depth_state->test_function));
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
ctx->depth_test_function_cache = depth_state->test_function;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
if (ctx->depth_writing_enabled_cache != depth_state->write_enabled)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDepthMask (depth_state->write_enabled ?
GL_TRUE : GL_FALSE));
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
ctx->depth_writing_enabled_cache = depth_state->write_enabled;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->driver != COGL_DRIVER_GLES1 &&
(ctx->depth_range_near_cache != depth_state->range_near ||
ctx->depth_range_far_cache != depth_state->range_far))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (ctx->private_feature_flags & COGL_PRIVATE_FEATURE_GL_EMBEDDED)
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glDepthRangef (depth_state->range_near,
depth_state->range_far));
else
GE (ctx, glDepthRange (depth_state->range_near,
depth_state->range_far));
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
ctx->depth_range_near_cache = depth_state->range_near;
ctx->depth_range_far_cache = depth_state->range_far;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
tests: Adds our first white-box unit test This adds a white-box unit test that verifies that GL_BLEND is disabled when drawing an opaque rectangle, enabled when drawing a transparent rectangle and then disabled again when drawing a transparent rectangle but with a blend string that effectively disables blending. This shares the test utilities and launcher infrastructure we are using for conformance tests so we get consistent reporting and so unit tests will be run against a range of different drivers. This adds a --enable-unit-tests configure option which is enabled by default but if disabled will make all UNIT_TESTS() into static inline functions that we should expect the compiler to discard since they won't be referenced by anything. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 9047cce06bbf9051ec77e622be2fdbb96ed767a8)
2013-05-30 08:22:22 -04:00
UNIT_TEST (check_gl_blend_enable,
0 /* no requirements */,
0 /* no failure cases */)
{
CoglPipeline *pipeline = cogl_pipeline_new (test_ctx);
/* By default blending should be disabled */
g_assert_cmpint (test_ctx->gl_blend_enable_cache, ==, 0);
cogl_framebuffer_draw_rectangle (test_fb, pipeline, 0, 0, 1, 1);
_cogl_framebuffer_flush_journal (test_fb);
/* After drawing an opaque rectangle blending should still be
* disabled */
g_assert_cmpint (test_ctx->gl_blend_enable_cache, ==, 0);
cogl_pipeline_set_color4f (pipeline, 0, 0, 0, 0);
cogl_framebuffer_draw_rectangle (test_fb, pipeline, 0, 0, 1, 1);
_cogl_framebuffer_flush_journal (test_fb);
/* After drawing a transparent rectangle blending should be enabled */
g_assert_cmpint (test_ctx->gl_blend_enable_cache, ==, 1);
cogl_pipeline_set_blend (pipeline, "RGBA=ADD(SRC_COLOR, 0)", NULL);
cogl_framebuffer_draw_rectangle (test_fb, pipeline, 0, 0, 1, 1);
_cogl_framebuffer_flush_journal (test_fb);
/* After setting a blend string that effectively disables blending
* then blending should be disabled */
g_assert_cmpint (test_ctx->gl_blend_enable_cache, ==, 0);
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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_flush_color_blend_alpha_depth_state (
CoglPipeline *pipeline,
unsigned long pipelines_difference,
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
CoglBool with_color_attrib)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
/* On GLES2 we'll flush the color later */
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if ((ctx->private_feature_flags & COGL_PRIVATE_FEATURE_GL_FIXED) &&
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
!with_color_attrib)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 ((pipelines_difference & COGL_PIPELINE_STATE_COLOR) ||
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* Assume if we were previously told to skip the color, then
* the current color needs updating... */
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
ctx->current_pipeline_with_color_attrib)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_COLOR);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glColor4ub (cogl_color_get_red_byte (&authority->color),
cogl_color_get_green_byte (&authority->color),
cogl_color_get_blue_byte (&authority->color),
cogl_color_get_alpha_byte (&authority->color)));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 (pipelines_difference & COGL_PIPELINE_STATE_BLEND)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_BLEND);
CoglPipelineBlendState *blend_state =
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
&authority->big_state->blend_state;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* GLES 1 only has glBlendFunc */
if (ctx->driver == COGL_DRIVER_GLES1)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glBlendFunc (blend_state->blend_src_factor_rgb,
blend_state->blend_dst_factor_rgb));
}
#if defined(HAVE_COGL_GLES2) || defined(HAVE_COGL_GL)
else
{
if (blend_factor_uses_constant (blend_state->blend_src_factor_rgb) ||
blend_factor_uses_constant (blend_state
->blend_src_factor_alpha) ||
blend_factor_uses_constant (blend_state->blend_dst_factor_rgb) ||
blend_factor_uses_constant (blend_state->blend_dst_factor_alpha))
{
float red =
cogl_color_get_red_float (&blend_state->blend_constant);
float green =
cogl_color_get_green_float (&blend_state->blend_constant);
float blue =
cogl_color_get_blue_float (&blend_state->blend_constant);
float alpha =
cogl_color_get_alpha_float (&blend_state->blend_constant);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glBlendColor (red, green, blue, alpha));
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if (ctx->glBlendEquationSeparate &&
blend_state->blend_equation_rgb !=
blend_state->blend_equation_alpha)
GE (ctx,
glBlendEquationSeparate (blend_state->blend_equation_rgb,
blend_state->blend_equation_alpha));
else
GE (ctx, glBlendEquation (blend_state->blend_equation_rgb));
if (ctx->glBlendFuncSeparate &&
(blend_state->blend_src_factor_rgb !=
blend_state->blend_src_factor_alpha ||
opengl: Fix conditional call of BlendFuncSeparate Checking whether src_rgb != src_alpha twice is pointless; not checking whether dst_rgb != dst_alpha is clearly wrong. Found by Coverity. Signed-off-by: Adam Jackson <ajax@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=689850 Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit fc292c25db3004543e277d92693ab9cb388d2121)
2012-12-07 09:47:50 -05:00
(blend_state->blend_dst_factor_rgb !=
blend_state->blend_dst_factor_alpha)))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glBlendFuncSeparate (blend_state->blend_src_factor_rgb,
blend_state->blend_dst_factor_rgb,
blend_state->blend_src_factor_alpha,
blend_state->blend_dst_factor_alpha));
else
GE (ctx, glBlendFunc (blend_state->blend_src_factor_rgb,
blend_state->blend_dst_factor_rgb));
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
#endif
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#if defined (HAVE_COGL_GL) || defined (HAVE_COGL_GLES)
cogl-pipeline: Flush the lighting params in common code not vertend The lighting parameters such as the diffuse and ambient colors were previously only flushed in the fixed vertend. This meant that if a vertex shader was used then they would not be set. The lighting parameters are uniforms which are just as useful in a fragment shader so it doesn't really make sense to set them in the vertend. They are now flushed in the common cogl-pipeline-opengl code but the code is #ifdef'd for GLES2 because they need to be part of the progend in that case.
2011-01-14 06:11:44 -05:00
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 15:32:36 -04:00
if ((ctx->private_feature_flags & COGL_PRIVATE_FEATURE_ALPHA_TEST))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* Under GLES2 the alpha function is implemented as part of the
fragment shader */
if (pipelines_difference & (COGL_PIPELINE_STATE_ALPHA_FUNC |
COGL_PIPELINE_STATE_ALPHA_FUNC_REFERENCE))
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline,
COGL_PIPELINE_STATE_ALPHA_FUNC);
CoglPipelineAlphaFuncState *alpha_state =
&authority->big_state->alpha_state;
/* NB: Currently the Cogl defines are compatible with the GL ones: */
GE (ctx, glAlphaFunc (alpha_state->alpha_func,
alpha_state->alpha_func_reference));
}
cogl-pipeline: Flush the lighting params in common code not vertend The lighting parameters such as the diffuse and ambient colors were previously only flushed in the fixed vertend. This meant that if a vertex shader was used then they would not be set. The lighting parameters are uniforms which are just as useful in a fragment shader so it doesn't really make sense to set them in the vertend. They are now flushed in the common cogl-pipeline-opengl code but the code is #ifdef'd for GLES2 because they need to be part of the progend in that case.
2011-01-14 06:11:44 -05:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* Under GLES2 the lighting parameters are implemented as uniforms
in the progend */
if (pipelines_difference & COGL_PIPELINE_STATE_LIGHTING)
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline,
COGL_PIPELINE_STATE_LIGHTING);
CoglPipelineLightingState *lighting_state =
&authority->big_state->lighting_state;
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_AMBIENT,
lighting_state->ambient));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_DIFFUSE,
lighting_state->diffuse));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_SPECULAR,
lighting_state->specular));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_EMISSION,
lighting_state->emission));
GE (ctx, glMaterialfv (GL_FRONT_AND_BACK, GL_SHININESS,
&lighting_state->shininess));
}
cogl-pipeline: Flush the lighting params in common code not vertend The lighting parameters such as the diffuse and ambient colors were previously only flushed in the fixed vertend. This meant that if a vertex shader was used then they would not be set. The lighting parameters are uniforms which are just as useful in a fragment shader so it doesn't really make sense to set them in the vertend. They are now flushed in the common cogl-pipeline-opengl code but the code is #ifdef'd for GLES2 because they need to be part of the progend in that case.
2011-01-14 06:11:44 -05:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#endif
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 (pipelines_difference & COGL_PIPELINE_STATE_DEPTH)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_DEPTH);
Add CoglDepthState API Instead of simply extending the cogl_pipeline_ namespace to add api for controlling the depth testing state we now break the api out. This adds a CoglDepthState type that can be stack allocated. The members of the structure are private but we have the following API to setup the state: cogl_depth_state_init cogl_depth_state_set_test_enabled cogl_depth_state_get_test_enabled cogl_depth_state_set_test_function cogl_depth_state_get_test_function cogl_depth_state_set_writing_enabled cogl_depth_state_get_writing_enabled cogl_depth_state_set_range cogl_depth_state_get_range This removes the following experimental API which is now superseded: cogl_material_set_depth_test_enabled cogl_material_get_depth_test_enabled cogl_material_set_depth_test_function cogl_material_get_depth_test_function cogl_material_set_depth_writing_enabled cogl_material_get_depth_writing_enabled cogl_material_set_depth_range cogl_material_get_depth_range Once a CoglDepthState structure is setup it can be set on a pipeline using cogl_pipeline_set_depth_state().
2011-04-14 13:12:03 -04:00
CoglDepthState *depth_state = &authority->big_state->depth_state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Fix depth testing, write enable bug This fixes a bug in _cogl_pipeline_flush_color_blend_alpha_depth_state whereby we were only calling flush_depth_state if we knew that at least depth testing was enabled. This didn't take into account that enabling and disabling depth writing is a useful change to make even if depth testing is disabled. It also seemed a bit messy to flush the depth-testing enable separately from the other depth state. _cogl_pipeline_flush_color_blend_alpha_depth_state now simply calls flush_depth_state() if there is a _DEPTH_STATE difference and flush_depth_state() also handles flushing the depth-testing enable in along with all the other depth state. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6a9dfc55b8f55d7023cb592e5bef2118d0f3d50c)
2012-04-29 17:14:43 -04:00
flush_depth_state (ctx, depth_state);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Adds ColorMask support to Cogl This adds CoglPipeline and CoglFramebuffer support for setting a color mask which is a bit mask defining which color channels should be written to the current framebuffer. The final color mask is the intersection of the framebuffer color mask and the pipeline color mask. The framebuffer mask affects all rendering to the framebuffer while the pipeline masks can be used to affect individual primitives. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-07-10 21:27:54 -04:00
if (pipelines_difference & COGL_PIPELINE_STATE_LOGIC_OPS)
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_LOGIC_OPS);
CoglPipelineLogicOpsState *logic_ops_state = &authority->big_state->logic_ops_state;
CoglColorMask color_mask = logic_ops_state->color_mask;
Don't use cogl_get_draw_framebuffer when flushing pipeline state Some of the state when flushing a pipeline depends on the current framebuffer being used. These are: • The matrix stack, so that it can flip vertically or not depending on whether the framebuffer is offscreen. • The colormask. This is combined with the framebuffer's color mask. • The cull face mode. If the framebuffer is offscreen then backface culling is translated to frontface culling and vice-versa. These states were not working if the new framebuffer draw_primitive API was used because in that case the framebuffer is not pushed to the framebuffer stack so it would use the wrong one. This patch changes it to use ctx->current_draw_buffer which is a pointer to the framebuffer whose state was last flushed. https://bugzilla.gnome.org/show_bug.cgi?id=670793 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 10:10:02 -05:00
if (ctx->current_draw_buffer)
color_mask &= ctx->current_draw_buffer->color_mask;
Adds ColorMask support to Cogl This adds CoglPipeline and CoglFramebuffer support for setting a color mask which is a bit mask defining which color channels should be written to the current framebuffer. The final color mask is the intersection of the framebuffer color mask and the pipeline color mask. The framebuffer mask affects all rendering to the framebuffer while the pipeline masks can be used to affect individual primitives. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-07-10 21:27:54 -04:00
GE (ctx, glColorMask (!!(color_mask & COGL_COLOR_MASK_RED),
!!(color_mask & COGL_COLOR_MASK_GREEN),
!!(color_mask & COGL_COLOR_MASK_BLUE),
!!(color_mask & COGL_COLOR_MASK_ALPHA)));
ctx->current_gl_color_mask = color_mask;
}
Make backface culling be part of the legacy state This adds an internal function to set the backface culling state on a pipeline. This includes properties to set the culling mode (front, back or both) and also to set which face is considered the front (COGL_WINDING_CLOCKWISE or COGL_WINDING_COUNTER_CLOCKWISE). The actual front face flushed to GL depends on whether we are rendering to an offscreen buffer or not. This means that when changing between on- and off- screen framebuffers it now checks whether the last flushed pipeline has backface culling enabled and forces a reflush of the cull face state if so. The backface culling is now set on a pipeline as part of the legacy state. This is important because some code in Cogl assumes it can flush a temporary pipeline to revert to a known state, but previously this wouldn't disable backface culling so things such as flushing the clip stack could get confused. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-15 06:25:39 -04:00
if (pipelines_difference & COGL_PIPELINE_STATE_CULL_FACE)
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_CULL_FACE);
CoglPipelineCullFaceState *cull_face_state
= &authority->big_state->cull_face_state;
if (cull_face_state->mode == COGL_PIPELINE_CULL_FACE_MODE_NONE)
GE( ctx, glDisable (GL_CULL_FACE) );
else
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool invert_winding;
Make backface culling be part of the legacy state This adds an internal function to set the backface culling state on a pipeline. This includes properties to set the culling mode (front, back or both) and also to set which face is considered the front (COGL_WINDING_CLOCKWISE or COGL_WINDING_COUNTER_CLOCKWISE). The actual front face flushed to GL depends on whether we are rendering to an offscreen buffer or not. This means that when changing between on- and off- screen framebuffers it now checks whether the last flushed pipeline has backface culling enabled and forces a reflush of the cull face state if so. The backface culling is now set on a pipeline as part of the legacy state. This is important because some code in Cogl assumes it can flush a temporary pipeline to revert to a known state, but previously this wouldn't disable backface culling so things such as flushing the clip stack could get confused. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-15 06:25:39 -04:00
GE( ctx, glEnable (GL_CULL_FACE) );
switch (cull_face_state->mode)
{
case COGL_PIPELINE_CULL_FACE_MODE_NONE:
g_assert_not_reached ();
case COGL_PIPELINE_CULL_FACE_MODE_FRONT:
GE( ctx, glCullFace (GL_FRONT) );
break;
case COGL_PIPELINE_CULL_FACE_MODE_BACK:
GE( ctx, glCullFace (GL_BACK) );
break;
case COGL_PIPELINE_CULL_FACE_MODE_BOTH:
GE( ctx, glCullFace (GL_FRONT_AND_BACK) );
break;
}
/* If we are painting to an offscreen framebuffer then we
need to invert the winding of the front face because
everything is painted upside down */
Don't use cogl_get_draw_framebuffer when flushing pipeline state Some of the state when flushing a pipeline depends on the current framebuffer being used. These are: • The matrix stack, so that it can flip vertically or not depending on whether the framebuffer is offscreen. • The colormask. This is combined with the framebuffer's color mask. • The cull face mode. If the framebuffer is offscreen then backface culling is translated to frontface culling and vice-versa. These states were not working if the new framebuffer draw_primitive API was used because in that case the framebuffer is not pushed to the framebuffer stack so it would use the wrong one. This patch changes it to use ctx->current_draw_buffer which is a pointer to the framebuffer whose state was last flushed. https://bugzilla.gnome.org/show_bug.cgi?id=670793 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-25 10:10:02 -05:00
invert_winding = cogl_is_offscreen (ctx->current_draw_buffer);
Make backface culling be part of the legacy state This adds an internal function to set the backface culling state on a pipeline. This includes properties to set the culling mode (front, back or both) and also to set which face is considered the front (COGL_WINDING_CLOCKWISE or COGL_WINDING_COUNTER_CLOCKWISE). The actual front face flushed to GL depends on whether we are rendering to an offscreen buffer or not. This means that when changing between on- and off- screen framebuffers it now checks whether the last flushed pipeline has backface culling enabled and forces a reflush of the cull face state if so. The backface culling is now set on a pipeline as part of the legacy state. This is important because some code in Cogl assumes it can flush a temporary pipeline to revert to a known state, but previously this wouldn't disable backface culling so things such as flushing the clip stack could get confused. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-15 06:25:39 -04:00
switch (cull_face_state->front_winding)
{
case COGL_WINDING_CLOCKWISE:
GE( ctx, glFrontFace (invert_winding ? GL_CCW : GL_CW) );
break;
case COGL_WINDING_COUNTER_CLOCKWISE:
GE( ctx, glFrontFace (invert_winding ? GL_CW : GL_CCW) );
break;
}
}
}
Add support for per-vertex point sizes This adds a new function to enable per-vertex point size on a pipeline. This can be set with cogl_pipeline_set_per_vertex_point_size(). Once enabled the point size can be set either by drawing with an attribute named 'cogl_point_size_in' or by writing to the 'cogl_point_size_out' builtin from a snippet. There is a feature flag which must be checked for before using per-vertex point sizes. This will only be set on GL >= 2.0 or on GLES 2.0. GL will only let you set a per-vertex point size from GLSL by writing to gl_PointSize. This is only available in GL2 and not in the older GLSL extensions. The per-vertex point size has its own pipeline state flag so that it can be part of the state that affects vertex shader generation. Having to enable the per vertex point size with a separate function is a bit awkward. Ideally it would work like the color attribute where you can just set it for every vertex in your primitive with cogl_pipeline_set_color or set it per-vertex by just using the attribute. This is harder to get working with the point size because we need to generate a different vertex shader depending on what attributes are bound. I think if we wanted to make this work transparently we would still want to internally have a pipeline property describing whether the shader was generated with per-vertex support so that it would work with the shader cache correctly. Potentially we could make the per-vertex property internal and automatically make a weak pipeline whenever the attribute is bound. However we would then also need to automatically detect when an application is writing to cogl_point_size_out from a snippet. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 8495d9c1c15ce389885a9356d965eabd97758115) Conflicts: cogl/cogl-context.c cogl/cogl-pipeline-private.h cogl/cogl-pipeline.c cogl/cogl-private.h cogl/driver/gl/cogl-pipeline-progend-fixed.c cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c
2012-11-08 11:56:02 -05:00
#ifdef HAVE_COGL_GL
if ((ctx->private_feature_flags &
COGL_PRIVATE_FEATURE_ENABLE_PROGRAM_POINT_SIZE) &&
(pipelines_difference & COGL_PIPELINE_STATE_PER_VERTEX_POINT_SIZE))
{
unsigned long state = COGL_PIPELINE_STATE_PER_VERTEX_POINT_SIZE;
CoglPipeline *authority = _cogl_pipeline_get_authority (pipeline, state);
if (authority->big_state->per_vertex_point_size)
GE( ctx, glEnable (GL_PROGRAM_POINT_SIZE) );
else
GE( ctx, glDisable (GL_PROGRAM_POINT_SIZE) );
}
#endif
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->real_blend_enable != ctx->gl_blend_enable_cache)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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->real_blend_enable)
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glEnable (GL_BLEND));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
else
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glDisable (GL_BLEND));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* XXX: we shouldn't update any other blend state if blending
* is disabled! */
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
ctx->gl_blend_enable_cache = pipeline->real_blend_enable;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
static int
get_max_activateable_texture_units (void)
{
_COGL_GET_CONTEXT (ctx, 0);
if (G_UNLIKELY (ctx->max_activateable_texture_units == -1))
{
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
GLint values[3];
int n_values = 0;
int i;
#ifdef HAVE_COGL_GL
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (!(ctx->private_feature_flags & COGL_PRIVATE_FEATURE_GL_EMBEDDED))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
{
/* GL_MAX_TEXTURE_COORDS is provided for both GLSL and ARBfp. It
defines the number of texture coordinates that can be
uploaded (but doesn't necessarily relate to how many texture
images can be sampled) */
features: Support more than 32 features! Currently features are represented as bits in a 32bit mask so we obviously can't have more than 32 features with that approach. The new approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks without a size limit and we change the public api to accept individual feature enums instead of a mask. This way there is no limit on the number of features we can add to Cogl. Instead of using cogl_features_available() there is a new cogl_has_feature() function and for checking multiple features there is cogl_has_features() which takes a zero terminated vararg list of features. In addition to being able to check for individual features this also adds a way to query all the features currently available via cogl_foreach_feature() which will call a callback for each feature. Since the new functions take an explicit context pointer there is also no longer any ambiguity over when users can first start to query features. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-12 17:31:12 -04:00
if (cogl_has_feature (ctx, COGL_FEATURE_ID_GLSL) ||
cogl_has_feature (ctx, COGL_FEATURE_ID_ARBFP))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
/* Previously this code subtracted the value by one but there
was no explanation for why it did this and it doesn't seem
to make sense so it has been removed */
GE (ctx, glGetIntegerv (GL_MAX_TEXTURE_COORDS,
values + n_values++));
/* GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is defined for GLSL but
not ARBfp */
features: Support more than 32 features! Currently features are represented as bits in a 32bit mask so we obviously can't have more than 32 features with that approach. The new approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks without a size limit and we change the public api to accept individual feature enums instead of a mask. This way there is no limit on the number of features we can add to Cogl. Instead of using cogl_features_available() there is a new cogl_has_feature() function and for checking multiple features there is cogl_has_features() which takes a zero terminated vararg list of features. In addition to being able to check for individual features this also adds a way to query all the features currently available via cogl_foreach_feature() which will call a callback for each feature. Since the new functions take an explicit context pointer there is also no longer any ambiguity over when users can first start to query features. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-12 17:31:12 -04:00
if (cogl_has_feature (ctx, COGL_FEATURE_ID_GLSL))
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glGetIntegerv (GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS,
values + n_values++));
}
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
#endif /* HAVE_COGL_GL */
#ifdef HAVE_COGL_GLES2
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if (ctx->private_feature_flags & COGL_PRIVATE_FEATURE_GL_EMBEDDED &&
ctx->private_feature_flags & COGL_PRIVATE_FEATURE_GL_PROGRAMMABLE)
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
{
GE (ctx, glGetIntegerv (GL_MAX_VERTEX_ATTRIBS, values + n_values));
/* Two of the vertex attribs need to be used for the position
and color */
values[n_values++] -= 2;
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
GE (ctx, glGetIntegerv (GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS,
values + n_values++));
}
#endif
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
#if defined (HAVE_COGL_GL) || defined (HAVE_COGL_GLES)
if (ctx->private_feature_flags & COGL_PRIVATE_FEATURE_GL_FIXED)
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
{
/* GL_MAX_TEXTURE_UNITS defines the number of units that are
usable from the fixed function pipeline, therefore it isn't
available in GLES2. These are also tied to the number of
texture coordinates that can be uploaded so it should be less
than that available from the shader extensions */
GE (ctx, glGetIntegerv (GL_MAX_TEXTURE_UNITS,
values + n_values++));
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
}
#endif
cogl-pipeline-opengl: Don't use number of tex units on fixed-function The CoglPipeline code uses a combination of GL_MAX_TEXTURE_COORDS, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_UNITS to determine the maximum number of layers to allow in a pipeline. However on fixed function hardware that doesn't advertise either GLSL or ARBfp it was still using the first two enums which will probably just return 0 and set a GLerror. This meant that we effectively didn't support using any layers on purely fixed function hardware. This patch changes it to only use those two enums if the appropriate extensions are advertised and to always use GL_MAX_TEXTURE_UNITS except on GLES2 where there is no fixed function. https://bugzilla.gnome.org/show_bug.cgi?id=650966
2011-05-24 08:23:13 -04:00
g_assert (n_values <= G_N_ELEMENTS (values) &&
n_values > 0);
/* Use the maximum value */
ctx->max_activateable_texture_units = values[0];
for (i = 1; i < n_values; i++)
ctx->max_activateable_texture_units =
MAX (values[i], ctx->max_activateable_texture_units);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
return ctx->max_activateable_texture_units;
}
typedef struct
{
int i;
unsigned long *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
} CoglPipelineFlushLayerState;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
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
flush_layers_common_gl_state_cb (CoglPipelineLayer *layer, void *user_data)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
CoglPipelineFlushLayerState *flush_state = user_data;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
int unit_index = flush_state->i;
CoglTextureUnit *unit = _cogl_get_texture_unit (unit_index);
unsigned long layers_difference =
flush_state->layer_differences[unit_index];
cogl-pipeline: Use layer overrides as CoglHandles instead of GLuint Since d5634e37 the sliced texture backend now works in terms of CoglTexture2Ds so there's no need to have special casing for overriding the texture of a pipeline layer with a GL handle. Instead we can just use cogl_pipeline_set_layer_texture with the CoglHandle. The special _cogl_pipeline_set_layer_gl_texture_slice function has now been removed and parts of the code for comparing materials have been simplified.
2010-11-11 11:18:25 -05:00
_COGL_GET_CONTEXT (ctx, FALSE);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* There may not be enough texture units so we can bail out if
* that's the case...
*/
if (G_UNLIKELY (unit_index >= get_max_activateable_texture_units ()))
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool shown_warning = FALSE;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
if (!shown_warning)
{
g_warning ("Your hardware does not have enough texture units"
"to handle this many texture layers");
shown_warning = TRUE;
}
return FALSE;
}
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
if (layers_difference & COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
cogl-pipeline-layer: Use CoglTextureType instead of GL target enum Instead of storing the GLenum for the target of the last used texture for a layer it now stores the CoglTextureType instead. The state name has been renamed to 'texture type' instead of 'texture target'. Previously the default pipeline layer would store 0 here to represent that there is no texture. This has been changed to store COGL_TEXTURE_TYPE_2D instead which means that all pipeline layers always have a valid value for the texture type. Any places that were previously fetching the texture from a layer to determine the target (for example when generating shaders or when enabling a particular texture target) now use the texture type instead. This means they will work even for layers that don't have a texture. This also changes it so that when binding a fallback texture instead of always using a 2D texture it will now use the default texture corresponding to the texture type of the layer. That way when the generated shader tries to do a texture lookup for that type of texture it will get a valid texture object. To make this work the patch adds a default texture for 3D textures to the context and also makes the default rectangle texture actually be a rectangle texture instead of using a 2D texture. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-09 07:52:45 -05:00
CoglTexture *texture = _cogl_pipeline_layer_get_texture_real (layer);
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
GLuint gl_texture;
GLenum gl_target;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
cogl-pipeline-layer: Use CoglTextureType instead of GL target enum Instead of storing the GLenum for the target of the last used texture for a layer it now stores the CoglTextureType instead. The state name has been renamed to 'texture type' instead of 'texture target'. Previously the default pipeline layer would store 0 here to represent that there is no texture. This has been changed to store COGL_TEXTURE_TYPE_2D instead which means that all pipeline layers always have a valid value for the texture type. Any places that were previously fetching the texture from a layer to determine the target (for example when generating shaders or when enabling a particular texture target) now use the texture type instead. This means they will work even for layers that don't have a texture. This also changes it so that when binding a fallback texture instead of always using a 2D texture it will now use the default texture corresponding to the texture type of the layer. That way when the generated shader tries to do a texture lookup for that type of texture it will get a valid texture object. To make this work the patch adds a default texture for 3D textures to the context and also makes the default rectangle texture actually be a rectangle texture instead of using a 2D texture. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-09 07:52:45 -05:00
if (texture == NULL)
switch (_cogl_pipeline_layer_get_texture_type (layer))
{
case COGL_TEXTURE_TYPE_2D:
context: removes some uses of CoglHandle There were several members of the CoglContext struct using the CoglHandle type for things that now have replacement typedefs which this patch fixes. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-18 09:58:39 -05:00
texture = COGL_TEXTURE (ctx->default_gl_texture_2d_tex);
cogl-pipeline-layer: Use CoglTextureType instead of GL target enum Instead of storing the GLenum for the target of the last used texture for a layer it now stores the CoglTextureType instead. The state name has been renamed to 'texture type' instead of 'texture target'. Previously the default pipeline layer would store 0 here to represent that there is no texture. This has been changed to store COGL_TEXTURE_TYPE_2D instead which means that all pipeline layers always have a valid value for the texture type. Any places that were previously fetching the texture from a layer to determine the target (for example when generating shaders or when enabling a particular texture target) now use the texture type instead. This means they will work even for layers that don't have a texture. This also changes it so that when binding a fallback texture instead of always using a 2D texture it will now use the default texture corresponding to the texture type of the layer. That way when the generated shader tries to do a texture lookup for that type of texture it will get a valid texture object. To make this work the patch adds a default texture for 3D textures to the context and also makes the default rectangle texture actually be a rectangle texture instead of using a 2D texture. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-09 07:52:45 -05:00
break;
case COGL_TEXTURE_TYPE_3D:
context: removes some uses of CoglHandle There were several members of the CoglContext struct using the CoglHandle type for things that now have replacement typedefs which this patch fixes. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-18 09:58:39 -05:00
texture = COGL_TEXTURE (ctx->default_gl_texture_3d_tex);
cogl-pipeline-layer: Use CoglTextureType instead of GL target enum Instead of storing the GLenum for the target of the last used texture for a layer it now stores the CoglTextureType instead. The state name has been renamed to 'texture type' instead of 'texture target'. Previously the default pipeline layer would store 0 here to represent that there is no texture. This has been changed to store COGL_TEXTURE_TYPE_2D instead which means that all pipeline layers always have a valid value for the texture type. Any places that were previously fetching the texture from a layer to determine the target (for example when generating shaders or when enabling a particular texture target) now use the texture type instead. This means they will work even for layers that don't have a texture. This also changes it so that when binding a fallback texture instead of always using a 2D texture it will now use the default texture corresponding to the texture type of the layer. That way when the generated shader tries to do a texture lookup for that type of texture it will get a valid texture object. To make this work the patch adds a default texture for 3D textures to the context and also makes the default rectangle texture actually be a rectangle texture instead of using a 2D texture. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-09 07:52:45 -05:00
break;
case COGL_TEXTURE_TYPE_RECTANGLE:
context: removes some uses of CoglHandle There were several members of the CoglContext struct using the CoglHandle type for things that now have replacement typedefs which this patch fixes. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2012-02-18 09:58:39 -05:00
texture = COGL_TEXTURE (ctx->default_gl_texture_rect_tex);
cogl-pipeline-layer: Use CoglTextureType instead of GL target enum Instead of storing the GLenum for the target of the last used texture for a layer it now stores the CoglTextureType instead. The state name has been renamed to 'texture type' instead of 'texture target'. Previously the default pipeline layer would store 0 here to represent that there is no texture. This has been changed to store COGL_TEXTURE_TYPE_2D instead which means that all pipeline layers always have a valid value for the texture type. Any places that were previously fetching the texture from a layer to determine the target (for example when generating shaders or when enabling a particular texture target) now use the texture type instead. This means they will work even for layers that don't have a texture. This also changes it so that when binding a fallback texture instead of always using a 2D texture it will now use the default texture corresponding to the texture type of the layer. That way when the generated shader tries to do a texture lookup for that type of texture it will get a valid texture object. To make this work the patch adds a default texture for 3D textures to the context and also makes the default rectangle texture actually be a rectangle texture instead of using a 2D texture. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-02-09 07:52:45 -05:00
break;
}
cogl-pipeline: Use layer overrides as CoglHandles instead of GLuint Since d5634e37 the sliced texture backend now works in terms of CoglTexture2Ds so there's no need to have special casing for overriding the texture of a pipeline layer with a GL handle. Instead we can just use cogl_pipeline_set_layer_texture with the CoglHandle. The special _cogl_pipeline_set_layer_gl_texture_slice function has now been removed and parts of the code for comparing materials have been simplified.
2010-11-11 11:18:25 -05:00
cogl_texture_get_gl_texture (texture,
&gl_texture,
&gl_target);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
_cogl_set_active_texture_unit (unit_index);
/* NB: There are several Cogl components and some code in
* Clutter that will temporarily bind arbitrary GL textures to
* query and modify texture object parameters. If you look at
* _cogl_bind_gl_texture_transient() you can see we make sure
* that such code always binds to texture unit 1 which means we
* can't rely on the unit->gl_texture state if unit->index == 1.
*
* Because texture unit 1 is a bit special we actually defer any
* necessary glBindTexture for it until the end of
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_flush_gl_state().
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
* NB: we get notified whenever glDeleteTextures is used (see
* _cogl_delete_gl_texture()) where we invalidate
* unit->gl_texture references to deleted textures so it's safe
* to compare unit->gl_texture with gl_texture. (Without the
* hook it would be possible to delete a GL texture and create a
* new one with the same name and comparing unit->gl_texture and
* gl_texture wouldn't detect that.)
*
* NB: for foreign textures we don't know how the deletion of
* the GL texture objects correspond to the deletion of the
* CoglTextures so if there was previously a foreign texture
* associated with the texture unit then we can't assume that we
* aren't seeing a recycled texture name so we have to bind.
*/
if (unit->gl_texture != gl_texture || unit->is_foreign)
{
Always bind a new texture to unit 1 when necessary The special handling for texture unit 1 caught the case where unit 1 was changed for transient purposes, but didn't properly handle the case where the actual non-transient texture was different between two materials with no transient binding in between. If the actual texture has changed when flushing, mark unit 1 as dirty and needing a rebind. http://bugzilla.clutter-project.org/show_bug.cgi?id=2261
2010-08-09 15:06:35 -04:00
if (unit_index == 1)
unit->dirty_gl_texture = TRUE;
else
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindTexture (gl_target, gl_texture));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unit->gl_texture = gl_texture;
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
unit->gl_target = gl_target;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
unit->is_foreign = _cogl_texture_is_foreign (texture);
/* The texture_storage_changed boolean indicates if the
* CoglTexture's underlying GL texture storage has changed since
* it was flushed to the texture unit. We've just flushed the
* latest state so we can reset this. */
unit->texture_storage_changed = FALSE;
}
Use GL_ARB_sampler_objects GL_ARB_sampler_objects provides a GL object which overrides the sampler state part of a texture object with different values. The sampler state that Cogl currently exposes is the wrap modes and filters. Cogl exposes the state as part of the pipeline layer state but without this extension GL only exposes it as part of the texture object state. This means that it won't work to use a single texture multiple times in one primitive with different sampler states. It also makes switching between different sampler states with a single texture not terribly efficient because it has to change the texture object state every time. This patch adds a cache for sampler states in a shared hash table attached to the CoglContext. The entire set of parameters for the sampler state is used as the key for the hash table. When a unique state is encountered the sampler cache will create a new entry, otherwise it will return a const pointer to an existing entry. That means we can have a single pointer to represent any combination of sampler state. Pipeline layers now just store this single pointer rather than storing all of the sampler state. The two separate state flags for wrap modes and filters have now been combined into one. It should be faster to compare the sampler state now because instead of comparing each value it can just compare the pointers to the cached sampler entries. The hash table of cached sampler states should only need to perform its more expensive hash on the state when a property is changed on a pipeline, not every time it is flushed. When the sampler objects extension is available each cached sampler state will also get a sampler object to represent it. The common code to flush the GL state will now simply bind this object to a unit instead of flushing the state though the CoglTexture when possible. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-04-04 17:20:04 -04:00
if ((layers_difference & COGL_PIPELINE_LAYER_STATE_SAMPLER) &&
(ctx->private_feature_flags & COGL_PRIVATE_FEATURE_SAMPLER_OBJECTS))
{
const CoglSamplerCacheEntry *sampler_state;
sampler_state = _cogl_pipeline_layer_get_sampler_state (layer);
GE( ctx, glBindSampler (unit_index, sampler_state->sampler_object) );
}
Unify a lot of gles2 vs gl glsl code Since we used to support hybrid fixed-function + glsl pipelines when running with OpenGL there were numerous differences in how we handled codegen and uniform updates between GLES2 and full OpenGL. Now that we only support end-to-end glsl pipelines this patch can largely unify how we handle GLES2 and OpenGL. Most notably we now never use the builtin attribute names. This should also make it easy for us to support creating strict OpenGL 3.1 contexts where the builtin names have been removed. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 2701b93f159bf2d3387cedf2d06fe921ad5641f3)
2012-09-23 08:32:36 -04:00
/* FIXME: If using GLSL the progend we will use gl_PointCoord
* instead of us needing to replace the texture coordinates but at
* this point we can't currently tell if we are using the fixed or
* glsl progend.
*/
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#if defined (HAVE_COGL_GLES) || defined (HAVE_COGL_GL)
generalize driver description and selection This adds a table of driver descriptions to cogl-renderer.c in order of preference and when choosing what driver to use we now iterate the table instead of repeating boilerplate checks. For handling the "default driver" that can be specified when building cogl and handling driver overrides there is a foreach_driver_description() that will make sure to iterate the default driver first or if an override has been set then nothing but the override will be considered. This patch introduces some driver flags that let us broadly categorize what kind of GL driver we are currently running on. Since there are numerous OpenGL apis with different broad feature sets and new apis may be introduced in the future by Khronos then we should tend to avoid using the driver id to do runtime feature checking. These flags provide a more stable quantity for broad feature checks. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
2013-05-11 13:15:25 -04:00
if ((ctx->private_feature_flags & COGL_PRIVATE_FEATURE_GL_FIXED) &&
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
(layers_difference & COGL_PIPELINE_LAYER_STATE_POINT_SPRITE_COORDS))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
CoglPipelineState change = COGL_PIPELINE_LAYER_STATE_POINT_SPRITE_COORDS;
CoglPipelineLayer *authority =
_cogl_pipeline_layer_get_authority (layer, change);
CoglPipelineLayerBigState *big_state = authority->big_state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
_cogl_set_active_texture_unit (unit_index);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glTexEnvi (GL_POINT_SPRITE, GL_COORD_REPLACE,
big_state->point_sprite_coords));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#endif
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Removes all remaining use of CoglHandle Removing CoglHandle has been an on going goal for quite a long time now and finally this patch removes the last remaining uses of the CoglHandle type and the cogl_handle_ apis. Since the big remaining users of CoglHandle were the cogl_program_ and cogl_shader_ apis which have replaced with the CoglSnippets api this patch removes both of these apis. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6ed3aaf4be21d605a1ed3176b3ea825933f85cf0) Since the original patch was done after removing deprecated API this back ported patch doesn't affect deprecated API and so actually this cherry-pick doesn't remove all remaining use of CoglHandle as it did for the master branch of Cogl.
2012-04-16 09:14:10 -04:00
cogl_object_ref (layer);
if (unit->layer != NULL)
cogl_object_unref (unit->layer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unit->layer = layer;
unit->layer_changes_since_flush = 0;
flush_state->i++;
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
_cogl_pipeline_flush_common_gl_state (CoglPipeline *pipeline,
unsigned long pipelines_difference,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unsigned long *layer_differences,
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
CoglBool with_color_attrib)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
CoglPipelineFlushLayerState state;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
_cogl_pipeline_flush_color_blend_alpha_depth_state (pipeline,
pipelines_difference,
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
with_color_attrib);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
state.i = 0;
state.layer_differences = 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_foreach_layer_internal (pipeline,
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
flush_layers_common_gl_state_cb,
&state);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
/* Re-assert the layer's wrap modes on the given CoglTexture.
*
* Note: we don't simply forward the wrap modes to layer->texture
* since the actual texture being used may have been overridden.
*/
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_layer_forward_wrap_modes (CoglPipelineLayer *layer,
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *texture)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Use GL_ARB_sampler_objects GL_ARB_sampler_objects provides a GL object which overrides the sampler state part of a texture object with different values. The sampler state that Cogl currently exposes is the wrap modes and filters. Cogl exposes the state as part of the pipeline layer state but without this extension GL only exposes it as part of the texture object state. This means that it won't work to use a single texture multiple times in one primitive with different sampler states. It also makes switching between different sampler states with a single texture not terribly efficient because it has to change the texture object state every time. This patch adds a cache for sampler states in a shared hash table attached to the CoglContext. The entire set of parameters for the sampler state is used as the key for the hash table. When a unique state is encountered the sampler cache will create a new entry, otherwise it will return a const pointer to an existing entry. That means we can have a single pointer to represent any combination of sampler state. Pipeline layers now just store this single pointer rather than storing all of the sampler state. The two separate state flags for wrap modes and filters have now been combined into one. It should be faster to compare the sampler state now because instead of comparing each value it can just compare the pointers to the cached sampler entries. The hash table of cached sampler states should only need to perform its more expensive hash on the state when a property is changed on a pipeline, not every time it is flushed. When the sampler objects extension is available each cached sampler state will also get a sampler object to represent it. The common code to flush the GL state will now simply bind this object to a unit instead of flushing the state though the CoglTexture when possible. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-04-04 17:20:04 -04:00
CoglSamplerCacheWrapMode wrap_mode_s, wrap_mode_t, wrap_mode_p;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
GLenum gl_wrap_mode_s, gl_wrap_mode_t, gl_wrap_mode_p;
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
if (texture == NULL)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
_cogl_pipeline_layer_get_wrap_modes (layer,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
&wrap_mode_s,
&wrap_mode_t,
&wrap_mode_p);
/* Update the wrap mode on the texture object. The texture backend
should cache the value so that it will be a no-op if the object
already has the same wrap mode set. The backend is best placed to
do this because it knows how many of the coordinates will
actually be used (ie, a 1D texture only cares about the 's'
coordinate but a 3D texture would use all three). GL uses the
wrap mode as part of the texture object state but we are
pretending it's part of the per-layer environment state. This
will break if the application tries to use different modes in
different layers using the same texture. */
Use GL_ARB_sampler_objects GL_ARB_sampler_objects provides a GL object which overrides the sampler state part of a texture object with different values. The sampler state that Cogl currently exposes is the wrap modes and filters. Cogl exposes the state as part of the pipeline layer state but without this extension GL only exposes it as part of the texture object state. This means that it won't work to use a single texture multiple times in one primitive with different sampler states. It also makes switching between different sampler states with a single texture not terribly efficient because it has to change the texture object state every time. This patch adds a cache for sampler states in a shared hash table attached to the CoglContext. The entire set of parameters for the sampler state is used as the key for the hash table. When a unique state is encountered the sampler cache will create a new entry, otherwise it will return a const pointer to an existing entry. That means we can have a single pointer to represent any combination of sampler state. Pipeline layers now just store this single pointer rather than storing all of the sampler state. The two separate state flags for wrap modes and filters have now been combined into one. It should be faster to compare the sampler state now because instead of comparing each value it can just compare the pointers to the cached sampler entries. The hash table of cached sampler states should only need to perform its more expensive hash on the state when a property is changed on a pipeline, not every time it is flushed. When the sampler objects extension is available each cached sampler state will also get a sampler object to represent it. The common code to flush the GL state will now simply bind this object to a unit instead of flushing the state though the CoglTexture when possible. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-04-04 17:20:04 -04:00
if (wrap_mode_s == COGL_SAMPLER_CACHE_WRAP_MODE_AUTOMATIC)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
gl_wrap_mode_s = GL_CLAMP_TO_EDGE;
else
gl_wrap_mode_s = wrap_mode_s;
Use GL_ARB_sampler_objects GL_ARB_sampler_objects provides a GL object which overrides the sampler state part of a texture object with different values. The sampler state that Cogl currently exposes is the wrap modes and filters. Cogl exposes the state as part of the pipeline layer state but without this extension GL only exposes it as part of the texture object state. This means that it won't work to use a single texture multiple times in one primitive with different sampler states. It also makes switching between different sampler states with a single texture not terribly efficient because it has to change the texture object state every time. This patch adds a cache for sampler states in a shared hash table attached to the CoglContext. The entire set of parameters for the sampler state is used as the key for the hash table. When a unique state is encountered the sampler cache will create a new entry, otherwise it will return a const pointer to an existing entry. That means we can have a single pointer to represent any combination of sampler state. Pipeline layers now just store this single pointer rather than storing all of the sampler state. The two separate state flags for wrap modes and filters have now been combined into one. It should be faster to compare the sampler state now because instead of comparing each value it can just compare the pointers to the cached sampler entries. The hash table of cached sampler states should only need to perform its more expensive hash on the state when a property is changed on a pipeline, not every time it is flushed. When the sampler objects extension is available each cached sampler state will also get a sampler object to represent it. The common code to flush the GL state will now simply bind this object to a unit instead of flushing the state though the CoglTexture when possible. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-04-04 17:20:04 -04:00
if (wrap_mode_t == COGL_SAMPLER_CACHE_WRAP_MODE_AUTOMATIC)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
gl_wrap_mode_t = GL_CLAMP_TO_EDGE;
else
gl_wrap_mode_t = wrap_mode_t;
Use GL_ARB_sampler_objects GL_ARB_sampler_objects provides a GL object which overrides the sampler state part of a texture object with different values. The sampler state that Cogl currently exposes is the wrap modes and filters. Cogl exposes the state as part of the pipeline layer state but without this extension GL only exposes it as part of the texture object state. This means that it won't work to use a single texture multiple times in one primitive with different sampler states. It also makes switching between different sampler states with a single texture not terribly efficient because it has to change the texture object state every time. This patch adds a cache for sampler states in a shared hash table attached to the CoglContext. The entire set of parameters for the sampler state is used as the key for the hash table. When a unique state is encountered the sampler cache will create a new entry, otherwise it will return a const pointer to an existing entry. That means we can have a single pointer to represent any combination of sampler state. Pipeline layers now just store this single pointer rather than storing all of the sampler state. The two separate state flags for wrap modes and filters have now been combined into one. It should be faster to compare the sampler state now because instead of comparing each value it can just compare the pointers to the cached sampler entries. The hash table of cached sampler states should only need to perform its more expensive hash on the state when a property is changed on a pipeline, not every time it is flushed. When the sampler objects extension is available each cached sampler state will also get a sampler object to represent it. The common code to flush the GL state will now simply bind this object to a unit instead of flushing the state though the CoglTexture when possible. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-04-04 17:20:04 -04:00
if (wrap_mode_p == COGL_SAMPLER_CACHE_WRAP_MODE_AUTOMATIC)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
gl_wrap_mode_p = GL_CLAMP_TO_EDGE;
else
gl_wrap_mode_p = wrap_mode_p;
texture: rename texobj flush code as gl specific This renames the set_filters and set_wrap_mode_parameters texture virtual functions to gl_flush_legacy_texobj_filters and gl_flush_legacy_texobj_wrap_modes respectively to clarify that they are opengl driver specific and that they are only used to support the legacy opengl apis for setting filters and wrap modes where the state is associated with texture objects instead of being associated with sampler objects. This part of an effort to clearly delimit our abstraction over opengl so that we can start to consider non-opengl backends for Cogl. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6f78b8a613340d7c6b736e51a16c625f52154430)
2012-09-10 15:35:39 -04:00
_cogl_texture_gl_flush_legacy_texobj_wrap_modes (texture,
gl_wrap_mode_s,
gl_wrap_mode_t,
gl_wrap_mode_p);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
/* OpenGL associates the min/mag filters and repeat modes with the
* texture object not the texture unit so we always have to re-assert
* the filter and repeat modes whenever we use a texture since it may
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
* be referenced by multiple pipelines with different modes.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
Use GL_ARB_sampler_objects GL_ARB_sampler_objects provides a GL object which overrides the sampler state part of a texture object with different values. The sampler state that Cogl currently exposes is the wrap modes and filters. Cogl exposes the state as part of the pipeline layer state but without this extension GL only exposes it as part of the texture object state. This means that it won't work to use a single texture multiple times in one primitive with different sampler states. It also makes switching between different sampler states with a single texture not terribly efficient because it has to change the texture object state every time. This patch adds a cache for sampler states in a shared hash table attached to the CoglContext. The entire set of parameters for the sampler state is used as the key for the hash table. When a unique state is encountered the sampler cache will create a new entry, otherwise it will return a const pointer to an existing entry. That means we can have a single pointer to represent any combination of sampler state. Pipeline layers now just store this single pointer rather than storing all of the sampler state. The two separate state flags for wrap modes and filters have now been combined into one. It should be faster to compare the sampler state now because instead of comparing each value it can just compare the pointers to the cached sampler entries. The hash table of cached sampler states should only need to perform its more expensive hash on the state when a property is changed on a pipeline, not every time it is flushed. When the sampler objects extension is available each cached sampler state will also get a sampler object to represent it. The common code to flush the GL state will now simply bind this object to a unit instead of flushing the state though the CoglTexture when possible. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-04-04 17:20:04 -04:00
* This function is bypassed in favour of sampler objects if
* GL_ARB_sampler_objects is advertised. This fallback won't work if
* the same texture is bound to multiple layers with different sampler
* state.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*/
static void
foreach_texture_unit_update_filter_and_wrap_modes (void)
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
for (i = 0; i < ctx->texture_units->len; i++)
{
CoglTextureUnit *unit =
&g_array_index (ctx->texture_units, CoglTextureUnit, i);
if (unit->layer)
{
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
CoglTexture *texture = _cogl_pipeline_layer_get_texture (unit->layer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Add a strong CoglTexture type to replace CoglHandle As part of the on going, incremental effort to purge the non type safe CoglHandle type from the Cogl API this patch tackles most of the CoglHandle uses relating to textures. We'd postponed making this change for quite a while because we wanted to have a clearer understanding of how we wanted to evolve the texture APIs towards Cogl 2.0 before exposing type safety here which would be difficult to change later since it would imply breaking APIs. The basic idea that we are steering towards now is that CoglTexture can be considered to be the most primitive interface we have for any object representing a texture. The texture interface would provide roughly these methods: cogl_texture_get_width cogl_texture_get_height cogl_texture_can_repeat cogl_texture_can_mipmap cogl_texture_generate_mipmap; cogl_texture_get_format cogl_texture_set_region cogl_texture_get_region Besides the texture interface we will then start to expose types corresponding to specific texture types: CoglTexture2D, CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and CoglTexturePixmapX11. We will then also expose an interface for the high-level texture types we have (such as CoglTexture2DSlice, CoglSubTexture and CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an additional interface that lets you iterate a virtual region of a meta texture and get mappings of primitive textures to sub-regions of that virtual region. Internally we already have this kind of abstraction for dealing with sliced texture, sub-textures and atlas textures in a consistent way, so this will just make that abstraction public. The aim here is to clarify that there is a difference between primitive textures (CoglTexture2D/3D) and some of the other high-level textures, and also enable developers to implement primitives that can support meta textures since they can only be used with the cogl_rectangle API currently. The thing that's not so clean-cut with this are the texture constructors we have currently; such as cogl_texture_new_from_file which no longer make sense when CoglTexture is considered to be an interface. These will basically just become convenient factory functions and it's just a bit unusual that they are within the cogl_texture namespace. It's worth noting here that all the texture type APIs will also have their own type specific constructors so these functions will only be used for the convenience of being able to create a texture without really wanting to know the details of what type of texture you need. Longer term for 2.0 we may come up with replacement names for these factory functions or the other thing we are considering is designing some asynchronous factory functions instead since it's so often detrimental to application performance to be blocked waiting for a texture to be uploaded to the GPU. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-24 16:30:34 -04:00
if (texture != NULL)
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
{
CoglPipelineFilter min;
CoglPipelineFilter mag;
_cogl_pipeline_layer_get_filters (unit->layer, &min, &mag);
texture: rename texobj flush code as gl specific This renames the set_filters and set_wrap_mode_parameters texture virtual functions to gl_flush_legacy_texobj_filters and gl_flush_legacy_texobj_wrap_modes respectively to clarify that they are opengl driver specific and that they are only used to support the legacy opengl apis for setting filters and wrap modes where the state is associated with texture objects instead of being associated with sampler objects. This part of an effort to clearly delimit our abstraction over opengl so that we can start to consider non-opengl backends for Cogl. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6f78b8a613340d7c6b736e51a16c625f52154430)
2012-09-10 15:35:39 -04:00
_cogl_texture_gl_flush_legacy_texobj_filters (texture, min, mag);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
_cogl_pipeline_layer_forward_wrap_modes (unit->layer, texture);
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
}
}
typedef struct
{
int i;
unsigned long *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
} CoglPipelineCompareLayersState;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
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
compare_layer_differences_cb (CoglPipelineLayer *layer, void *user_data)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
CoglPipelineCompareLayersState *state = user_data;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
CoglTextureUnit *unit = _cogl_get_texture_unit (state->i);
if (unit->layer == layer)
state->layer_differences[state->i] = unit->layer_changes_since_flush;
else if (unit->layer)
{
state->layer_differences[state->i] = unit->layer_changes_since_flush;
state->layer_differences[state->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
_cogl_pipeline_layer_compare_differences (layer, unit->layer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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
state->layer_differences[state->i] = COGL_PIPELINE_LAYER_STATE_ALL_SPARSE;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* XXX: There is always a possibility that a CoglTexture's
* underlying GL texture storage has been changed since it was last
* bound to a texture unit which is why we have a callback into
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_texture_storage_change_notify whenever a textures
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* underlying GL texture storage changes which will set the
* unit->texture_intern_changed flag. If we see that's been set here
* then we force an update of the texture state...
*/
if (unit->texture_storage_changed)
pipeline: differentiate texture target and data state There are several places where we need to compare the texture state of a pipeline and sometimes we need to take into consideration if the underlying texture has changed but other times we may only care to know if the texture target has changed. For example the fragends typically generate programs that they want to share with all pipelines with equivalent fragment processing state, and in this case when comparing pipelines we only care about the texture targets since changes to the underlying texture won't affect the programs generated. Prior to this we had tried to handle this by passing around some special flags to various functions that evaluate pipeline state to say when we do/don't care about the texture data, but this wasn't working in all cases and was more awkward to manage than the new approach. Now we simply have two state bits: COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an additional target member. Since all the appropriate code takes masks of these state bits to determine what to evaluate we don't need any extra magic flags.
2011-01-11 11:02:06 -05:00
state->layer_differences[state->i] |=
COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
state->i++;
return TRUE;
}
typedef struct
{
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
CoglFramebuffer *framebuffer;
const CoglPipelineVertend *vertend;
Rename CoglPipelineBackend to CoglPipelineFragend The current Cogl pipeline backends are entirely concerned with the fragment processing state. We also want to eventually have separate backends to generate shaders for the vertex processing state so we need to rename the fragment backends. 'Fragend' is a somewhat weird name but we wanted to avoid ending up with illegible symbols like CoglPipelineFragmentBackendGlslPrivate.
2010-11-29 11:56:41 -05:00
const CoglPipelineFragend *fragend;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *pipeline;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unsigned long *layer_differences;
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
CoglBool error_adding_layer;
CoglBool added_layer;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
} CoglPipelineAddLayerState;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
vertend_add_layer_cb (CoglPipelineLayer *layer,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
void *user_data)
{
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
CoglPipelineAddLayerState *state = user_data;
const CoglPipelineVertend *vertend = state->vertend;
cogl: rename CoglMaterial -> CoglPipeline This applies an API naming change that's been deliberated over for a while now which is to rename CoglMaterial to CoglPipeline. For now the new pipeline API is marked as experimental and public headers continue to talk about materials not pipelines. The CoglMaterial API is now maintained in terms of the cogl_pipeline API internally. Currently this API is targeting Cogl 2.0 so we will have time to integrate it properly with other upcoming Cogl 2.0 work. The basic reasons for the rename are: - That the term "material" implies to many people that they are constrained to fragment processing; perhaps as some kind of high-level texture abstraction. - In Clutter they get exposed by ClutterTexture actors which may be re-inforcing this misconception. - When comparing how other frameworks use the term material, a material sometimes describes a multi-pass fragment processing technique which isn't the case in Cogl. - In code, "CoglPipeline" will hopefully be a much more self documenting summary of what these objects represent; a full GPU pipeline configuration including, for example, vertex processing, fragment processing and blending. - When considering the API documentation story, at some point we need a document introducing developers to how the "GPU pipeline" works so it should become intuitive that CoglPipeline maps back to that description of the GPU pipeline. - This is consistent in terminology and concept to OpenGL 4's new pipeline object which is a container for program objects. Note: The cogl-material.[ch] files have been renamed to cogl-material-compat.[ch] because otherwise git doesn't seem to treat the change as a moving the old cogl-material.c->cogl-pipeline.c and so we loose all our git-blame history.
2010-10-27 13:54:57 -04:00
CoglPipeline *pipeline = state->pipeline;
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* Either generate per layer code snippets or setup the
* fixed function glTexEnv for each layer... */
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
if (G_LIKELY (vertend->add_layer (pipeline,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
layer,
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
state->layer_differences[unit_index],
state->framebuffer)))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
state->added_layer = TRUE;
else
{
state->error_adding_layer = TRUE;
return FALSE;
}
return TRUE;
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
fragend_add_layer_cb (CoglPipelineLayer *layer,
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
void *user_data)
{
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
CoglPipelineAddLayerState *state = user_data;
const CoglPipelineFragend *fragend = state->fragend;
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
CoglPipeline *pipeline = state->pipeline;
int unit_index = _cogl_pipeline_layer_get_unit_index (layer);
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
/* Either generate per layer code snippets or setup the
* fixed function glTexEnv for each layer... */
if (G_LIKELY (fragend->add_layer (pipeline,
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
layer,
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
state->layer_differences[unit_index])))
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
state->added_layer = TRUE;
else
{
state->error_adding_layer = TRUE;
return FALSE;
}
return TRUE;
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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_flush_gl_state:
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
* Details of override options:
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
* ->fallback_mask: is a bitmask of the pipeline layers that need to be
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* replaced with the default, fallback textures. The fallback textures are
* fully transparent textures so they hopefully wont contribute to the
* texture combining.
*
* The intention of fallbacks is to try and preserve
* the number of layers the user is expecting so that texture coordinates
* they gave will mostly still correspond to the textures they intended, and
* have a fighting chance of looking close to their originally intended
* result.
*
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
* ->disable_mask: is a bitmask of the pipeline layers that will simply have
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* texturing disabled. It's only really intended for disabling all layers
* > X; i.e. we'd expect to see a contiguous run of 0 starting from the LSB
* and at some point the remaining bits flip to 1. It might work to disable
* arbitrary layers; though I'm not sure a.t.m how OpenGL would take to
* that.
*
* The intention of the disable_mask is for emitting geometry when the user
* hasn't supplied enough texture coordinates for all the layers and it's
* not possible to auto generate default texture coordinates for those
* layers.
*
* ->layer0_override_texture: forcibly tells us to bind this GL texture name for
* layer 0 instead of plucking the gl_texture from the CoglTexture of layer
* 0.
*
* The intention of this is for any primitives that supports sliced textures.
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 code will can iterate each of the slices and re-flush the pipeline
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* forcing the GL texture of each slice in turn.
*
* ->wrap_mode_overrides: overrides the wrap modes set on each
* layer. This is used to implement the automatic wrap mode.
*
* XXX: It might also help if we could specify a texture matrix for code
* dealing with slicing that would be multiplied with the users own matrix.
*
* Normaly texture coords in the range [0, 1] refer to the extents of the
* texture, but when your GL texture represents a slice of the real texture
* (from the users POV) then a texture matrix would be a neat way of
* transforming the mapping for each slice.
*
* Currently for textured rectangles we manually calculate the texture
* coords for each slice based on the users given coords, but this solution
* isn't ideal, and can't be used with CoglVertexBuffers.
*/
void
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
_cogl_pipeline_flush_gl_state (CoglContext *ctx,
CoglPipeline *pipeline,
Re-design the matrix stack using a graph of ops This re-designs the matrix stack so we now keep track of each separate operation such as rotating, scaling, translating and multiplying as immutable, ref-counted nodes in a graph. Being a "graph" here means that different transformations composed of a sequence of linked operation nodes may share nodes. The first node in a matrix-stack is always a LOAD_IDENTITY operation. As an example consider if an application where to draw three rectangles A, B and C something like this: cogl_framebuffer_scale (fb, 2, 2, 2); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_translate (fb, 10, 0, 0); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_rotate (fb, 45, 0, 0, 1); cogl_framebuffer_draw_rectangle (...); /* A */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_draw_rectangle (...); /* B */ cogl_framebuffer_pop_matrix(fb); cogl_framebuffer_push_matrix(fb); cogl_framebuffer_set_modelview_matrix (fb, &mv); cogl_framebuffer_draw_rectangle (...); /* C */ cogl_framebuffer_pop_matrix(fb); That would result in a graph of nodes like this: LOAD_IDENTITY | SCALE / \ SAVE LOAD | | TRANSLATE RECTANGLE(C) | \ SAVE RECTANGLE(B) | ROTATE | RECTANGLE(A) Each push adds a SAVE operation which serves as a marker to rewind too when a corresponding pop is issued and also each SAVE node may also store a cached matrix representing the composition of all its ancestor nodes. This means if we repeatedly need to resolve a real CoglMatrix for a given node then we don't need to repeat the composition. Some advantages of this design are: - A single pointer to any node in the graph can now represent a complete, immutable transformation that can be logged for example into a journal. Previously we were storing a full CoglMatrix in each journal entry which is 16 floats for the matrix itself as well as space for flags and another 16 floats for possibly storing a cache of the inverse. This means that we significantly reduce the size of the journal when drawing lots of primitives and we also avoid copying over 128 bytes per entry. - It becomes much cheaper to check for equality. In cases where some (unlikely) false negatives are allowed simply comparing the pointers of two matrix stack graph entries is enough. Previously we would use memcmp() to compare matrices. - It becomes easier to do comparisons of transformations. By looking for the common ancestry between nodes we can determine the operations that differentiate the transforms and use those to gain a high level understanding of the differences. For example we use this in the journal to be able to efficiently determine when two rectangle transforms only differ by some translation so that we can perform software clipping. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f75aee93f6b293ca7a7babbd8fcc326ee6bf7aef)
2012-02-20 10:59:48 -05:00
CoglFramebuffer *framebuffer,
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
CoglBool with_color_attrib,
CoglBool unknown_color_alpha)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
CoglPipeline *current_pipeline = ctx->current_pipeline;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
unsigned long pipelines_difference;
int n_layers;
unsigned long *layer_differences;
int i;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
CoglTextureUnit *unit1;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
const CoglPipelineProgend *progend;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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_STATIC_TIMER (pipeline_flush_timer,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
"Mainloop", /* parent */
"Material Flush",
"The time spent flushing material state",
0 /* no application private data */);
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_TIMER_START (_cogl_uprof_context, pipeline_flush_timer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
/* Bail out asap if we've been asked to re-flush the already current
* pipeline and we can see the pipeline hasn't changed */
if (current_pipeline == pipeline &&
ctx->current_pipeline_age == pipeline->age &&
ctx->current_pipeline_with_color_attrib == with_color_attrib &&
ctx->current_pipeline_unknown_color_alpha == unknown_color_alpha)
goto done;
else
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
{
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
/* Update derived state (currently just the 'real_blend_enable'
* state) and determine a mask of state that differs between the
* current pipeline and the one we are flushing.
*
* Note updating the derived state is done before doing any
* pipeline comparisons so that we can correctly compare the
* 'real_blend_enable' state itself.
*/
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
if (current_pipeline == pipeline)
{
pipelines_difference = ctx->current_pipeline_changes_since_flush;
if (pipelines_difference & COGL_PIPELINE_STATE_AFFECTS_BLENDING ||
pipeline->unknown_color_alpha != unknown_color_alpha)
{
CoglBool save_real_blend_enable = pipeline->real_blend_enable;
_cogl_pipeline_update_real_blend_enable (pipeline,
unknown_color_alpha);
if (save_real_blend_enable != pipeline->real_blend_enable)
pipelines_difference |= COGL_PIPELINE_STATE_REAL_BLEND_ENABLE;
}
}
else if (current_pipeline)
{
pipelines_difference = ctx->current_pipeline_changes_since_flush;
_cogl_pipeline_update_real_blend_enable (pipeline,
unknown_color_alpha);
pipelines_difference |=
_cogl_pipeline_compare_differences (ctx->current_pipeline,
pipeline);
}
else
{
_cogl_pipeline_update_real_blend_enable (pipeline,
unknown_color_alpha);
pipelines_difference = COGL_PIPELINE_STATE_ALL;
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
/* Get a layer_differences mask for each layer to be flushed */
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
n_layers = cogl_pipeline_get_n_layers (pipeline);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
if (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
CoglPipelineCompareLayersState state;
Fix a clear of an array allocated with alloca which had the wrong size The array allocated for storing the difference flags for each layer in cogl-pipeline-opengl.c was being cleared with the size of a pointer instead of the size actually allocated for the array. Presumably this would mean that if there is more than one layer it wouldn't clear the array properly. Also the size of the array was slightly wrong because it was allocating the size of a pointer for each layer instead of the size of an unsigned long. This was originally reported by Jasper St. Pierre on #clutter. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 1e134dd7cd5317651be158a483c7cb2723ce8869)
2013-02-06 06:34:42 -05:00
layer_differences = g_alloca (sizeof (unsigned long) * n_layers);
memset (layer_differences, 0, sizeof (unsigned long) * n_layers);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
state.i = 0;
state.layer_differences = 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_foreach_layer_internal (pipeline,
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
compare_layer_differences_cb,
&state);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
else
layer_differences = NULL;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* First flush everything that's the same regardless of which
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 is being used...
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
* 1) top level state:
* glColor (or skip if a vertex attribute is being used for color)
* blend state
* alpha test state (except for GLES 2.0)
*
* 2) then foreach layer:
* determine gl_target/gl_texture
* bind 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
* Note: After _cogl_pipeline_flush_common_gl_state you can expect
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* all state of the layers corresponding texture unit to be
* updated.
*/
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_flush_common_gl_state (pipeline,
pipelines_difference,
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
layer_differences,
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
with_color_attrib);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
/* Now flush the fragment, vertex and program state according to the
* current progend backend.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
* Note: Some backends may not support the current pipeline
* configuration and in that case it will report and error and we
* will look for a different backend.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
* NB: if pipeline->progend != COGL_PIPELINE_PROGEND_UNDEFINED then
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 have previously managed to successfully flush this pipeline
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
* with the given progend so we will simply use that to avoid
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* fallback code paths.
*/
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
if (pipeline->progend == COGL_PIPELINE_PROGEND_UNDEFINED)
_cogl_pipeline_set_progend (pipeline, COGL_PIPELINE_PROGEND_DEFAULT);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
for (i = pipeline->progend;
i < COGL_PIPELINE_N_PROGENDS;
i++, _cogl_pipeline_set_progend (pipeline, i))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
const CoglPipelineVertend *vertend;
const CoglPipelineFragend *fragend;
CoglPipelineAddLayerState state;
progend = _cogl_pipeline_progends[i];
if (G_UNLIKELY (!progend->start (pipeline)))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
continue;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
vertend = _cogl_pipeline_vertends[progend->vertend];
vertend->start (pipeline,
n_layers,
Remove the varying array for tex_coords This removes the need to maintain an array of tex_coord varyings and instead we now just emit a varying per-layer uniquely named using a layer_number infix like cogl_tex_coord0_out and cogl_tex_coord0_in. Notable this patch also had to change the journal flushing code to use pipeline layer numbers to determine the name of texture coordinate attributes. We now also break batches by using a deeper comparison of layers so such that two pipelines with the same number of layers can now cause a batch break if they use different layer numbers. This adds an internal _cogl_pipeline_layer_numbers_equal() function that takes two pipelines and returns TRUE if they have the same number of layers and all the layer numbers are the same too, otherwise it returns FALSE. Where we used to break batches based on changes to the number of layers we now break according to the status of _cogl_pipeline_layer_numbers_equal Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e55b64a9cdc93285049d9b969bef67484c2d9fb3) Note: this will cause a temporary regression for the Cogl 1.x CoglShader api since it will break compatibility with existing shaders that reference the texture varyings from the fragment shader. The intention is to follow up with another patch to add back CoglShader compatibility.
2012-09-27 06:06:16 -04:00
pipelines_difference);
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
state.framebuffer = framebuffer;
state.vertend = vertend;
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
state.pipeline = pipeline;
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
state.layer_differences = layer_differences;
state.error_adding_layer = FALSE;
state.added_layer = FALSE;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -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_foreach_layer_internal (pipeline,
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
vertend_add_layer_cb,
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
&state);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
if (G_UNLIKELY (state.error_adding_layer))
continue;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
if (G_UNLIKELY (!vertend->end (pipeline, pipelines_difference)))
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
continue;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
/* Now prepare the fragment processing state (fragend)
*
* NB: We can't combine the setup of the vertend and fragend
* since the backends that do code generation share
* ctx->codegen_source_buffer as a scratch buffer.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
*/
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
fragend = _cogl_pipeline_fragends[progend->fragend];
state.fragend = fragend;
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
fragend->start (pipeline,
n_layers,
Remove the varying array for tex_coords This removes the need to maintain an array of tex_coord varyings and instead we now just emit a varying per-layer uniquely named using a layer_number infix like cogl_tex_coord0_out and cogl_tex_coord0_in. Notable this patch also had to change the journal flushing code to use pipeline layer numbers to determine the name of texture coordinate attributes. We now also break batches by using a deeper comparison of layers so such that two pipelines with the same number of layers can now cause a batch break if they use different layer numbers. This adds an internal _cogl_pipeline_layer_numbers_equal() function that takes two pipelines and returns TRUE if they have the same number of layers and all the layer numbers are the same too, otherwise it returns FALSE. Where we used to break batches based on changes to the number of layers we now break according to the status of _cogl_pipeline_layer_numbers_equal Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e55b64a9cdc93285049d9b969bef67484c2d9fb3) Note: this will cause a temporary regression for the Cogl 1.x CoglShader api since it will break compatibility with existing shaders that reference the texture varyings from the fragment shader. The intention is to follow up with another patch to add back CoglShader compatibility.
2012-09-27 06:06:16 -04:00
pipelines_difference);
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
_cogl_pipeline_foreach_layer_internal (pipeline,
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
fragend_add_layer_cb,
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
&state);
if (G_UNLIKELY (state.error_adding_layer))
continue;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
if (!state.added_layer)
{
if (fragend->passthrough &&
G_UNLIKELY (!fragend->passthrough (pipeline)))
continue;
}
if (G_UNLIKELY (!fragend->end (pipeline, pipelines_difference)))
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
continue;
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
if (progend->end)
Remove the varying array for tex_coords This removes the need to maintain an array of tex_coord varyings and instead we now just emit a varying per-layer uniquely named using a layer_number infix like cogl_tex_coord0_out and cogl_tex_coord0_in. Notable this patch also had to change the journal flushing code to use pipeline layer numbers to determine the name of texture coordinate attributes. We now also break batches by using a deeper comparison of layers so such that two pipelines with the same number of layers can now cause a batch break if they use different layer numbers. This adds an internal _cogl_pipeline_layer_numbers_equal() function that takes two pipelines and returns TRUE if they have the same number of layers and all the layer numbers are the same too, otherwise it returns FALSE. Where we used to break batches based on changes to the number of layers we now break according to the status of _cogl_pipeline_layer_numbers_equal Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit e55b64a9cdc93285049d9b969bef67484c2d9fb3) Note: this will cause a temporary regression for the Cogl 1.x CoglShader api since it will break compatibility with existing shaders that reference the texture varyings from the fragment shader. The intention is to follow up with another patch to add back CoglShader compatibility.
2012-09-27 06:06:16 -04:00
progend->end (pipeline, pipelines_difference);
cogl: Add a fixed function vertend The vertends are intended to flush state that would be represented in a vertex program. Code to handle the layer matrix, lighting and point size has now been moved from the common cogl-pipeline-opengl backend to the fixed vertend.
2010-11-29 13:32:21 -05:00
break;
}
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* FIXME: This reference is actually resulting in lots of
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
* copy-on-write reparenting because one-shot pipelines end up
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* living for longer than necessary and so any later modification of
* the parent will cause a copy-on-write.
*
* XXX: The issue should largely go away when we switch to using
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
* weak pipelines for overrides.
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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_object_ref (pipeline);
if (ctx->current_pipeline != NULL)
cogl_object_unref (ctx->current_pipeline);
ctx->current_pipeline = pipeline;
ctx->current_pipeline_changes_since_flush = 0;
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
ctx->current_pipeline_with_color_attrib = with_color_attrib;
ctx->current_pipeline_unknown_color_alpha = unknown_color_alpha;
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
ctx->current_pipeline_age = pipeline->age;
material: Bail out faster if re-flushing unchanged material This allows _cogl_material_flush_gl_state to bail out faster if repeatedly asked to flush the same material and we can see the material hasn't changed. Since we can rely on the material age incrementing when any material property changes or any associated layer property changes then we can track the age of the material after flushing so it can be compared with the age of the material if it is subsequently re-flushed. If the age is the same we only have to re-assert the texture object state.
2010-10-26 14:02:04 -04:00
done:
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
progend = _cogl_pipeline_progends[pipeline->progend];
Unify a lot of gles2 vs gl glsl code Since we used to support hybrid fixed-function + glsl pipelines when running with OpenGL there were numerous differences in how we handled codegen and uniform updates between GLES2 and full OpenGL. Now that we only support end-to-end glsl pipelines this patch can largely unify how we handle GLES2 and OpenGL. Most notably we now never use the builtin attribute names. This should also make it easy for us to support creating strict OpenGL 3.1 contexts where the builtin names have been removed. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 2701b93f159bf2d3387cedf2d06fe921ad5641f3)
2012-09-23 08:32:36 -04:00
/* We can't assume the color will be retained between flushes when
* using the glsl progend because the generic attribute values are
* not stored as part of the program object so they could be
* overridden by any attribute changes in another program */
pipeline: improve real_blend_enable checks Since _cogl_pipeline_update_blend_enable() can sometimes show up quite high in profiles; instead of calling _cogl_pipeline_update_blend_enable() whenever we change pipeline state that may affect blending we now just set a dirty flag and when we flush a pipeline we check this dirty flag and lazily calculate whether blender really needs to be enabled if it's set. Since it turns out we were too optimistic in assuming most GL drivers would recognize blending with ADD(src,0) is equivalent to disabling GL_BLEND we now check this case ourselves so we can always explicitly disable GL_BLEND if we know we don't need blending. This introduces the idea of an 'unknown_color_alpha' boolean to the pipeline flush code which is set whenever we can't guarantee that the color attribute is opaque. For example this is set whenever a user specifies a color attribute with 4 components when drawing a primitive. This boolean needs to be cached along with every pipeline because pipeline::real_blend_enabled depends on this and so we need to also call _cogl_pipeline_update_blend_enable() if the status of this changes. Incidentally with this patch we now no longer ever use _cogl_pipeline_set_blend_enable() internally. For now the internal api hasn't been removed though since we might want to consider re-purposing it as a public api since it will now not conflict with our own internal state tracking and could provide a more convenient way to disable blending than setting a blend string. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit ab2ae18f3207514c91fa6fd9f2d3f2ed93a86497)
2013-05-16 10:19:30 -04:00
if (pipeline->progend == COGL_PIPELINE_PROGEND_GLSL && !with_color_attrib)
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
{
int attribute;
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_COLOR);
rework enabling of attributes, removing _cogl_enable() This removes the limited caching of enabled attributes done by _cogl_enable() and replaces it with a more generalized set of bitmasks associated with the context that allow us to efficiently compare the set of attribute locations that are currently enabled vs the new locations that need enabling so we only have to inform OpenGL of the changes in which locations are enabled/disabled. This also adds a per-context hash table for mapping attribute names to global name-state structs which includes a unique name-index for any name as well as pre-validated information about builtin "cogl_" attribute names including whether the attribute is normalized and what texture unit a texture attribute corresponds too. The name-state hash table means that cogl_attribute_new() now only needs to validate names the first time they are seen. CoglAttributes now reference a name-state structure instead of just the attribute name, so now we can efficiently get the name-index for any attribute and we can use that to index into a per-glsl-program cache that maps name indices to real GL attribute locations so when we get asked to draw a set of attributes we can very quickly determine what GL attributes need to be setup and enabled. If we don't have a cached location though we can still quickly access the string name so we can query OpenGL. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-11-24 13:09:53 -05:00
int name_index = COGL_ATTRIBUTE_COLOR_NAME_INDEX;
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
rework enabling of attributes, removing _cogl_enable() This removes the limited caching of enabled attributes done by _cogl_enable() and replaces it with a more generalized set of bitmasks associated with the context that allow us to efficiently compare the set of attribute locations that are currently enabled vs the new locations that need enabling so we only have to inform OpenGL of the changes in which locations are enabled/disabled. This also adds a per-context hash table for mapping attribute names to global name-state structs which includes a unique name-index for any name as well as pre-validated information about builtin "cogl_" attribute names including whether the attribute is normalized and what texture unit a texture attribute corresponds too. The name-state hash table means that cogl_attribute_new() now only needs to validate names the first time they are seen. CoglAttributes now reference a name-state structure instead of just the attribute name, so now we can efficiently get the name-index for any attribute and we can use that to index into a per-glsl-program cache that maps name indices to real GL attribute locations so when we get asked to draw a set of attributes we can very quickly determine what GL attributes need to be setup and enabled. If we don't have a cached location though we can still quickly access the string name so we can query OpenGL. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-11-24 13:09:53 -05:00
attribute =
_cogl_pipeline_progend_glsl_get_attrib_location (pipeline, name_index);
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
if (attribute != -1)
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx,
glVertexAttrib4f (attribute,
cogl-vertex-attribute: Use glVertexAttribPointer on GLES2 When the GLES2 wrapper is removed we can't use the fixed function API such as glColorPointer to set the builtin attributes. Instead the GLSL progend now maintains a cache of attribute locations that are queried with glGetAttribLocation. The code that previously maintained a cache of the enabled texture coord arrays has been modified to also cache the enabled vertex attributes under GLES2. The vertex attribute API is now the only place that is using this cache so it has been moved into cogl-vertex-attribute.c
2010-12-03 12:46:16 -05:00
cogl_color_get_red_float (&authority->color),
cogl_color_get_green_float (&authority->color),
cogl_color_get_blue_float (&authority->color),
cogl_color_get_alpha_float (&authority->color)));
}
Clearly define 3 progends that own the frag+vertends This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of setting up the state of a pipeline: » fixed; where the vertex and fragment processing are implemented using fixed function opengl apis. » fixed-arbfp; where vertex processing is implemented using fixed function opengl apis but fragment processing is implemented using the ARB Fragment Processing language. » glsl; there vertex and fragment processing are both implemented using glsl. This means we avoid unusual, combinations such as glsl for vertex processing and arbfp for fragment processing, and also avoid pairing fixed-function vertex processing with glsl fragment processing which we happen to know hits some awkward code paths in Mesa that lead to poor performance. As part of this change, the progend now implies specific vertend and fragend choices so instead of associating a vertend and fragend with a pipeline we now just associate a progend choice. When flushing a pipeline and choosing what progend to use, we now call a progend->start() method that is able to determine if the vertend and fragend together will be able to handle the given pipeline so the vertend and fragend ->start() methods no longer need to return a boolean status. Since we now don't need to support glsl used in conjunction with fixed function this will allow us to avoid ever using OpenGL builtin attribute names, though this patch doesn't change that yet. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
2012-09-25 16:08:10 -04:00
/* Give the progend a chance to update any uniforms that might not
* depend on the material state. This is used on GLES2 to update the
* matrices */
if (progend->pre_paint)
progend->pre_paint (pipeline, framebuffer);
cogl: upload matrices with uniforms on GLES2 Once the GLES2 wrapper is removed we won't be able to upload the matrices with the fixed function API any more. The fixed function API gives a global state for setting the matrix but if a custom shader uniform is used for the matrices then the state is per program. _cogl_matrix_stack_flush_to_gl is called in a few places and it is assumed the current pipeline doesn't need to be flushed before it is called. To allow these semantics to continue to work, on GLES2 the matrix flush now just stores a reference to the matrix stack in the CoglContext. A pre_paint virtual is added to the progend which is called whenever a pipeline is flushed, even if the same pipeline was flushed already. This gives the GLSL progend a chance to upload the matrices to the uniforms. The combined modelview/projection matrix is only calculated if it is used. The generated programs end up never using the modelview or projection matrix so it usually only has to upload the combined matrix. When a matrix stack is flushed a reference is taked to it by the pipeline progend and the age is stored so that if the same state is used with the same program again then we don't need to reupload the uniform.
2010-12-06 07:31:51 -05:00
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
/* Handle the fact that OpenGL associates texture filter and wrap
* modes with the texture objects not the texture units... */
Use GL_ARB_sampler_objects GL_ARB_sampler_objects provides a GL object which overrides the sampler state part of a texture object with different values. The sampler state that Cogl currently exposes is the wrap modes and filters. Cogl exposes the state as part of the pipeline layer state but without this extension GL only exposes it as part of the texture object state. This means that it won't work to use a single texture multiple times in one primitive with different sampler states. It also makes switching between different sampler states with a single texture not terribly efficient because it has to change the texture object state every time. This patch adds a cache for sampler states in a shared hash table attached to the CoglContext. The entire set of parameters for the sampler state is used as the key for the hash table. When a unique state is encountered the sampler cache will create a new entry, otherwise it will return a const pointer to an existing entry. That means we can have a single pointer to represent any combination of sampler state. Pipeline layers now just store this single pointer rather than storing all of the sampler state. The two separate state flags for wrap modes and filters have now been combined into one. It should be faster to compare the sampler state now because instead of comparing each value it can just compare the pointers to the cached sampler entries. The hash table of cached sampler states should only need to perform its more expensive hash on the state when a property is changed on a pipeline, not every time it is flushed. When the sampler objects extension is available each cached sampler state will also get a sampler object to represent it. The common code to flush the GL state will now simply bind this object to a unit instead of flushing the state though the CoglTexture when possible. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-04-04 17:20:04 -04:00
if (!(ctx->private_feature_flags & COGL_PRIVATE_FEATURE_SAMPLER_OBJECTS))
foreach_texture_unit_update_filter_and_wrap_modes ();
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -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 this pipeline has more than one layer then we always need
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* to make sure we rebind the texture for unit 1.
*
* NB: various components of Cogl may temporarily bind arbitrary
* textures to texture unit 1 so they can query and modify 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
* object parameters. cogl-pipeline.c (See
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
* _cogl_bind_gl_texture_transient)
*/
unit1 = _cogl_get_texture_unit (1);
cogl-pipeline: Move texture enabling/disabling to fixed fragend Previously enabling and disabling textures was done whatever the backend in cogl-pipeline-opengl. However enabling and disabling texture targets only has any meaning if no fragment shaders are being used so this patch moves the code to cogl-pipeline-fragend-fixed. The GLES2 wrapper has also been changed to ignore enabledness when deciding whether to update texture coordinate attribute pointers.
2010-11-30 07:48:27 -05:00
if (cogl_pipeline_get_n_layers (pipeline) > 1 && unit1->dirty_gl_texture)
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
{
_cogl_set_active_texture_unit (1);
Use all core GL functions through indirect pointers cogl-ext-functions.h now contains definitions for all of the core GL and GLES functions that we would normally link to directly. All of the code has changed to access them through the cogl context pointer. The GE macro now takes an extra parameter to specify the context because the macro itself needs to make GL calls but various points in the Cogl source use different names for the context variable.
2011-07-06 16:51:00 -04:00
GE (ctx, glBindTexture (unit1->gl_target, unit1->gl_texture));
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
unit1->dirty_gl_texture = 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
COGL_TIMER_STOP (_cogl_uprof_context, pipeline_flush_timer);
material: splits out all the state flushing code This moves the code supporting _cogl_material_flush_gl_state into cogl-material-opengl.c as part of an effort to reduce the size of cogl-material.c to keep it manageable.
2010-07-09 22:40:47 -04:00
}
material: split the texture unit management out In general cogl-material.c has become far to large to manage in one source file. As one of the ways to try and break it down this patch starts to move some of lower level texture unit state management out into cogl-material-opengl.c. The naming is such because the plan is to follow up and migrate the very GL specific state flushing code into the same file.
2010-07-09 21:53:38 -04:00
Reference in New Issue Copy Permalink