mutter/cogl/driver/gl/cogl-pipeline-vertend-glsl.c

675 lines
23 KiB
C
Raw Normal View History

/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2010,2013 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:
* Neil Roberts <neil@linux.intel.com>
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <string.h>
Don't generate GLSL for the point size for default pipelines Previously on GLES2 where there is no builtin point size uniform then we would always add a line to the vertex shader to write to the builtin point size output because when generating the shader it is not possible to determine if the pipeline will be used to draw points or not. This patch changes it so that the default point size is 0.0f which is documented to have undefined results when drawing points. That way we can avoid adding the point size code to the shader in that case. The assumption is that any application that is drawing points will probably have explicitly set the point size on the pipeline anyway so it is not a big deal to change the default size from 1.0f. This adds a new pipeline state flag to track whether the point size is non-zero. This needs to be its own state because altering it needs to cause a different shader to be added to the pipeline cache. The state flags that affect the vertex shader have been changed from a constant to a runtime function because they will be different depending on whether there is a builtin point size uniform. There is also a unit test to ensure that changing the point size does or doesn't generate a new shader depending on the values. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b2eba06e16b587acbf5c57944a70ceccecb4f175) Conflicts: cogl/cogl-pipeline-private.h cogl/cogl-pipeline-state-private.h cogl/cogl-pipeline-state.c cogl/cogl-pipeline.c
2013-06-20 08:25:49 -04:00
#include <test-fixtures/test-unit.h>
#include "cogl-context-private.h"
#include "cogl-util-gl-private.h"
#include "cogl-pipeline-private.h"
#include "cogl-pipeline-opengl-private.h"
#ifdef COGL_PIPELINE_VERTEND_GLSL
#include "cogl-context-private.h"
#include "cogl-object-private.h"
#include "cogl-program-private.h"
#include "cogl-pipeline-vertend-glsl-private.h"
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
#include "cogl-pipeline-state-private.h"
#include "cogl-glsl-shader-private.h"
const CoglPipelineVertend _cogl_pipeline_glsl_vertend;
typedef struct
{
unsigned int ref_count;
GLuint gl_shader;
GString *header, *source;
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
CoglPipelineCacheEntry *cache_entry;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
} CoglPipelineShaderState;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
static CoglUserDataKey shader_state_key;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
static CoglPipelineShaderState *
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
shader_state_new (CoglPipelineCacheEntry *cache_entry)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state;
shader_state = g_slice_new0 (CoglPipelineShaderState);
shader_state->ref_count = 1;
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
shader_state->cache_entry = cache_entry;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
return shader_state;
}
static CoglPipelineShaderState *
get_shader_state (CoglPipeline *pipeline)
{
return cogl_object_get_user_data (COGL_OBJECT (pipeline), &shader_state_key);
}
static void
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
destroy_shader_state (void *user_data,
void *instance)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = user_data;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
if (shader_state->cache_entry &&
shader_state->cache_entry->pipeline != instance)
shader_state->cache_entry->usage_count--;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (--shader_state->ref_count == 0)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state->gl_shader)
GE( ctx, glDeleteShader (shader_state->gl_shader) );
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_slice_free (CoglPipelineShaderState, shader_state);
}
}
static void
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
set_shader_state (CoglPipeline *pipeline,
CoglPipelineShaderState *shader_state)
{
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
if (shader_state)
{
shader_state->ref_count++;
/* If we're not setting the state on the template pipeline then
* mark it as a usage of the pipeline cache entry */
if (shader_state->cache_entry &&
shader_state->cache_entry->pipeline != pipeline)
shader_state->cache_entry->usage_count++;
}
_cogl_object_set_user_data (COGL_OBJECT (pipeline),
&shader_state_key,
shader_state,
destroy_shader_state);
}
static void
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
dirty_shader_state (CoglPipeline *pipeline)
{
cogl_object_set_user_data (COGL_OBJECT (pipeline),
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
&shader_state_key,
NULL,
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
NULL);
}
GLuint
_cogl_pipeline_vertend_glsl_get_shader (CoglPipeline *pipeline)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state = get_shader_state (pipeline);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state)
return shader_state->gl_shader;
else
return 0;
}
cogl-pipeline: Add two hook points for adding shader snippets This adds two new public experimental functions for attaching CoglSnippets to two hook points on a CoglPipeline: void cogl_pipeline_add_vertex_hook (CoglPipeline *, CoglSnippet *) void cogl_pipeline_add_fragment_hook (CoglPipeline *, CoglSnippet *) The hooks are intended to be around the entire vertex or fragment processing. That means the pre string in the snippet will be inserted at the very top of the main function and the post function will be inserted at the very end. The declarations get inserted in the global scope. The snippets are stored in two separate linked lists with a structure containing an enum representing the hook point and a pointer to the snippet. The lists are meant to be for hooks that affect the vertex shader and fragment shader respectively. Although there are currently only two hooks and the names match these two lists, the intention is *not* that each new hook will be in a separate list. The separation of the lists is just to make it easier to determine which shader needs to be regenerated when a new snippet is added. When a pipeline becomes the authority for either the vertex or fragment snipper state, it simply copies the entire list from the previous authority (although of course the shader snippet objects are referenced instead of copied so it doesn't duplicate the source strings). Each string is inserted into its own block in the shader. This means that each string has its own scope so it doesn't need to worry about name collisions with variables in other snippets. However it does mean that the pre and post strings can't share variables. It could be possible to wrap both parts in one block and then wrap the actual inner hook code in another block, however this would mean that any further snippets within the outer snippet would be able to see those variables. Perhaps something to consider would be to put each snippet into its own function which calls another function between the pre and post strings to do further processing. The pipeline cache for generated programs was previously shared with the fragment shader cache because the state that affects vertex shaders was a subset of the state that affects fragment shaders. This is no longer the case because there is a separate state mask for vertex snippets so the program cache now has its own hash table. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-17 11:52:21 -05:00
static CoglPipelineSnippetList *
get_vertex_snippets (CoglPipeline *pipeline)
{
pipeline =
_cogl_pipeline_get_authority (pipeline,
COGL_PIPELINE_STATE_VERTEX_SNIPPETS);
return &pipeline->big_state->vertex_snippets;
}
static CoglPipelineSnippetList *
get_layer_vertex_snippets (CoglPipelineLayer *layer)
{
unsigned long state = COGL_PIPELINE_LAYER_STATE_VERTEX_SNIPPETS;
layer = _cogl_pipeline_layer_get_authority (layer, state);
return &layer->big_state->vertex_snippets;
}
static CoglBool
add_layer_declaration_cb (CoglPipelineLayer *layer,
void *user_data)
{
CoglPipelineShaderState *shader_state = user_data;
CoglTextureType texture_type =
_cogl_pipeline_layer_get_texture_type (layer);
const char *target_string;
_cogl_gl_util_get_texture_target_string (texture_type, &target_string, NULL);
g_string_append_printf (shader_state->header,
"uniform sampler%s cogl_sampler%i;\n",
target_string,
layer->index);
return TRUE;
}
static void
add_layer_declarations (CoglPipeline *pipeline,
CoglPipelineShaderState *shader_state)
{
/* We always emit sampler uniforms in case there will be custom
* layer snippets that want to sample arbitrary layers. */
_cogl_pipeline_foreach_layer_internal (pipeline,
add_layer_declaration_cb,
shader_state);
}
static void
add_global_declarations (CoglPipeline *pipeline,
CoglPipelineShaderState *shader_state)
{
CoglSnippetHook hook = COGL_SNIPPET_HOOK_VERTEX_GLOBALS;
CoglPipelineSnippetList *snippets = get_vertex_snippets (pipeline);
/* Add the global data hooks. All of the code in these snippets is
* always added and only the declarations data is used */
_cogl_pipeline_snippet_generate_declarations (shader_state->header,
hook,
snippets);
}
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
static void
_cogl_pipeline_vertend_glsl_start (CoglPipeline *pipeline,
int n_layers,
unsigned long pipelines_difference)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state;
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
CoglPipelineCacheEntry *cache_entry = NULL;
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
CoglProgram *user_program = cogl_pipeline_get_user_program (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
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* Now lookup our glsl backend private state (allocating if
* necessary) */
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = get_shader_state (pipeline);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state == NULL)
{
CoglPipeline *authority;
/* Get the authority for anything affecting vertex shader
state */
authority = _cogl_pipeline_find_equivalent_parent
(pipeline,
Don't generate GLSL for the point size for default pipelines Previously on GLES2 where there is no builtin point size uniform then we would always add a line to the vertex shader to write to the builtin point size output because when generating the shader it is not possible to determine if the pipeline will be used to draw points or not. This patch changes it so that the default point size is 0.0f which is documented to have undefined results when drawing points. That way we can avoid adding the point size code to the shader in that case. The assumption is that any application that is drawing points will probably have explicitly set the point size on the pipeline anyway so it is not a big deal to change the default size from 1.0f. This adds a new pipeline state flag to track whether the point size is non-zero. This needs to be its own state because altering it needs to cause a different shader to be added to the pipeline cache. The state flags that affect the vertex shader have been changed from a constant to a runtime function because they will be different depending on whether there is a builtin point size uniform. There is also a unit test to ensure that changing the point size does or doesn't generate a new shader depending on the values. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b2eba06e16b587acbf5c57944a70ceccecb4f175) Conflicts: cogl/cogl-pipeline-private.h cogl/cogl-pipeline-state-private.h cogl/cogl-pipeline-state.c cogl/cogl-pipeline.c
2013-06-20 08:25:49 -04:00
_cogl_pipeline_get_state_for_vertex_codegen (ctx) &
~COGL_PIPELINE_STATE_LAYERS,
COGL_PIPELINE_LAYER_STATE_AFFECTS_VERTEX_CODEGEN);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = get_shader_state (authority);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state == NULL)
{
/* Check if there is already a similar cached pipeline whose
shader state we can share */
if (G_LIKELY (!(COGL_DEBUG_ENABLED
(COGL_DEBUG_DISABLE_PROGRAM_CACHES))))
{
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
cache_entry =
_cogl_pipeline_cache_get_vertex_template (ctx->pipeline_cache,
authority);
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
shader_state = get_shader_state (cache_entry->pipeline);
}
if (shader_state)
shader_state->ref_count++;
else
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
shader_state = shader_state_new (cache_entry);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
set_shader_state (authority, shader_state);
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
shader_state->ref_count--;
if (cache_entry)
set_shader_state (cache_entry->pipeline, shader_state);
}
if (authority != pipeline)
pipeline-cache: Prune old unused pipelines when the cache gets too big Previously when a pipeline is added to the cache it would never be removed. If the application is generating a lot of unique pipelines this can end up effectively leaking a large number of resources including the GL program objects. Arguably this isn't really a problem because if the application is generating that many unique pipelines then it is doing something wrong anyway. It also implies that it will be recompiling shaders very often so the cache leaking will likely be the least of the problems. This patch makes it keep track of which pipelines in the cache are in use. The cache now returns a struct representing the entry instead of directly returning the pipeline. This entry contains a usage counter which the pipeline backends can use to mark when there is a pipeline alive that is using the cache entry. When the hash table decides that it's a good time to prune some entries, it will make a list of all of the pipelines that are not in use and then remove the least recently used half of the pipelines. That way it is less likely to remove pipelines that the application is actually regenerating often even if they aren't in use all of the time. When the cache is pruned the hash table makes a note of how small the cache could be if it removed all of the unused pipelines. The hash table starts pruning when there are more entries than twice this minimum expected size. The idea is that if that case it hit then the hash table is more than half full of useless pipelines so the application is generating lots of redundant pipelines and it is a good time to remove them. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb) Conflicts: cogl/driver/gl/cogl-pipeline-fragend-glsl.c cogl/driver/gl/cogl-pipeline-progend-glsl.c cogl/driver/gl/cogl-pipeline-vertend-glsl.c cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
2013-12-18 10:18:39 -05:00
set_shader_state (pipeline, shader_state);
}
if (user_program)
{
/* If the user program contains a vertex shader then we don't need
to generate one */
if (_cogl_program_has_vertex_shader (user_program))
{
if (shader_state->gl_shader)
{
GE( ctx, glDeleteShader (shader_state->gl_shader) );
shader_state->gl_shader = 0;
}
return;
}
}
if (shader_state->gl_shader)
return;
/* If we make it here then we have a shader_state struct without a gl_shader
either because this is the first time we've encountered it or
because the user program has changed */
/* We reuse two grow-only GStrings for code-gen. One string
contains the uniform and attribute declarations while the
other contains the main function. We need two strings
because we need to dynamically declare attributes as the
add_layer callback is invoked */
g_string_set_size (ctx->codegen_header_buffer, 0);
g_string_set_size (ctx->codegen_source_buffer, 0);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->header = ctx->codegen_header_buffer;
shader_state->source = ctx->codegen_source_buffer;
add_layer_declarations (pipeline, shader_state);
add_global_declarations (pipeline, shader_state);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append (shader_state->source,
"void\n"
"cogl_generated_source ()\n"
"{\n");
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
if (cogl_pipeline_get_per_vertex_point_size (pipeline))
g_string_append (shader_state->header,
"attribute float cogl_point_size_in;\n");
else if (!_cogl_has_private_feature
(ctx, COGL_PRIVATE_FEATURE_BUILTIN_POINT_SIZE_UNIFORM))
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
{
/* There is no builtin uniform for the point size on GLES2 so we
Don't generate GLSL for the point size for default pipelines Previously on GLES2 where there is no builtin point size uniform then we would always add a line to the vertex shader to write to the builtin point size output because when generating the shader it is not possible to determine if the pipeline will be used to draw points or not. This patch changes it so that the default point size is 0.0f which is documented to have undefined results when drawing points. That way we can avoid adding the point size code to the shader in that case. The assumption is that any application that is drawing points will probably have explicitly set the point size on the pipeline anyway so it is not a big deal to change the default size from 1.0f. This adds a new pipeline state flag to track whether the point size is non-zero. This needs to be its own state because altering it needs to cause a different shader to be added to the pipeline cache. The state flags that affect the vertex shader have been changed from a constant to a runtime function because they will be different depending on whether there is a builtin point size uniform. There is also a unit test to ensure that changing the point size does or doesn't generate a new shader depending on the values. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b2eba06e16b587acbf5c57944a70ceccecb4f175) Conflicts: cogl/cogl-pipeline-private.h cogl/cogl-pipeline-state-private.h cogl/cogl-pipeline-state.c cogl/cogl-pipeline.c
2013-06-20 08:25:49 -04:00
need to copy it from the custom uniform in the vertex shader
if we're not using per-vertex point sizes, however we'll only
do this if the point-size is non-zero. Toggle the point size
between zero and non-zero causes a state change which
generates a new program */
if (cogl_pipeline_get_point_size (pipeline) > 0.0f)
{
g_string_append (shader_state->header,
"uniform float cogl_point_size_in;\n");
g_string_append (shader_state->source,
" cogl_point_size_out = cogl_point_size_in;\n");
}
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
}
}
static CoglBool
_cogl_pipeline_vertend_glsl_add_layer (CoglPipeline *pipeline,
CoglPipelineLayer *layer,
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
unsigned long layers_difference,
CoglFramebuffer *framebuffer)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state;
CoglPipelineSnippetData snippet_data;
int layer_index = layer->index;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
_COGL_GET_CONTEXT (ctx, FALSE);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = get_shader_state (pipeline);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state->source == NULL)
return TRUE;
/* Transform the texture coordinates by the layer's user matrix.
*
* FIXME: this should avoid doing the transform if there is no user
* matrix set. This might need a separate layer state flag for
* whether there is a user matrix
*
* FIXME: we could be more clever here and try to detect if the
* fragment program is going to use the texture coordinates and
* avoid setting them if not
*/
g_string_append_printf (shader_state->header,
"vec4\n"
"cogl_real_transform_layer%i (mat4 matrix, "
"vec4 tex_coord)\n"
"{\n"
" return matrix * tex_coord;\n"
"}\n",
layer_index);
/* Wrap the layer code in any snippets that have been hooked */
memset (&snippet_data, 0, sizeof (snippet_data));
snippet_data.snippets = get_layer_vertex_snippets (layer);
snippet_data.hook = COGL_SNIPPET_HOOK_TEXTURE_COORD_TRANSFORM;
snippet_data.chain_function = g_strdup_printf ("cogl_real_transform_layer%i",
layer_index);
snippet_data.final_name = g_strdup_printf ("cogl_transform_layer%i",
layer_index);
snippet_data.function_prefix = g_strdup_printf ("cogl_transform_layer%i",
layer_index);
snippet_data.return_type = "vec4";
snippet_data.return_variable = "cogl_tex_coord";
snippet_data.return_variable_is_argument = TRUE;
snippet_data.arguments = "cogl_matrix, cogl_tex_coord";
snippet_data.argument_declarations = "mat4 cogl_matrix, vec4 cogl_tex_coord";
snippet_data.source_buf = shader_state->header;
_cogl_pipeline_snippet_generate_code (&snippet_data);
g_free ((char *) snippet_data.chain_function);
g_free ((char *) snippet_data.final_name);
g_free ((char *) snippet_data.function_prefix);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
g_string_append_printf (shader_state->source,
" cogl_tex_coord%i_out = "
"cogl_transform_layer%i (cogl_texture_matrix%i,\n"
" "
" cogl_tex_coord%i_in);\n",
layer_index,
layer_index,
layer_index,
layer_index);
return TRUE;
}
static CoglBool
_cogl_pipeline_vertend_glsl_end (CoglPipeline *pipeline,
unsigned long pipelines_difference)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state;
_COGL_GET_CONTEXT (ctx, FALSE);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = get_shader_state (pipeline);
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
if (shader_state->source)
{
const char *source_strings[2];
GLint lengths[2];
GLint compile_status;
GLuint shader;
CoglPipelineSnippetData snippet_data;
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
CoglPipelineSnippetList *vertex_snippets;
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
CoglBool has_per_vertex_point_size =
cogl_pipeline_get_per_vertex_point_size (pipeline);
COGL_STATIC_COUNTER (vertend_glsl_compile_counter,
"glsl vertex compile counter",
"Increments each time a new GLSL "
"vertex shader is compiled",
0 /* no application private data */);
COGL_COUNTER_INC (_cogl_uprof_context, vertend_glsl_compile_counter);
g_string_append (shader_state->header,
"void\n"
"cogl_real_vertex_transform ()\n"
"{\n"
" cogl_position_out = "
"cogl_modelview_projection_matrix * "
"cogl_position_in;\n"
"}\n");
g_string_append (shader_state->source,
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
" cogl_vertex_transform ();\n");
if (has_per_vertex_point_size)
{
g_string_append (shader_state->header,
"void\n"
"cogl_real_point_size_calculation ()\n"
"{\n"
" cogl_point_size_out = cogl_point_size_in;\n"
"}\n");
g_string_append (shader_state->source,
" cogl_point_size_calculation ();\n");
}
g_string_append (shader_state->source,
" cogl_color_out = cogl_color_in;\n"
"}\n");
cogl-pipeline: Add two hook points for adding shader snippets This adds two new public experimental functions for attaching CoglSnippets to two hook points on a CoglPipeline: void cogl_pipeline_add_vertex_hook (CoglPipeline *, CoglSnippet *) void cogl_pipeline_add_fragment_hook (CoglPipeline *, CoglSnippet *) The hooks are intended to be around the entire vertex or fragment processing. That means the pre string in the snippet will be inserted at the very top of the main function and the post function will be inserted at the very end. The declarations get inserted in the global scope. The snippets are stored in two separate linked lists with a structure containing an enum representing the hook point and a pointer to the snippet. The lists are meant to be for hooks that affect the vertex shader and fragment shader respectively. Although there are currently only two hooks and the names match these two lists, the intention is *not* that each new hook will be in a separate list. The separation of the lists is just to make it easier to determine which shader needs to be regenerated when a new snippet is added. When a pipeline becomes the authority for either the vertex or fragment snipper state, it simply copies the entire list from the previous authority (although of course the shader snippet objects are referenced instead of copied so it doesn't duplicate the source strings). Each string is inserted into its own block in the shader. This means that each string has its own scope so it doesn't need to worry about name collisions with variables in other snippets. However it does mean that the pre and post strings can't share variables. It could be possible to wrap both parts in one block and then wrap the actual inner hook code in another block, however this would mean that any further snippets within the outer snippet would be able to see those variables. Perhaps something to consider would be to put each snippet into its own function which calls another function between the pre and post strings to do further processing. The pipeline cache for generated programs was previously shared with the fragment shader cache because the state that affects vertex shaders was a subset of the state that affects fragment shaders. This is no longer the case because there is a separate state mask for vertex snippets so the program cache now has its own hash table. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-17 11:52:21 -05:00
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
vertex_snippets = get_vertex_snippets (pipeline);
/* Add hooks for the vertex transform part */
memset (&snippet_data, 0, sizeof (snippet_data));
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
snippet_data.snippets = vertex_snippets;
snippet_data.hook = COGL_SNIPPET_HOOK_VERTEX_TRANSFORM;
snippet_data.chain_function = "cogl_real_vertex_transform";
snippet_data.final_name = "cogl_vertex_transform";
snippet_data.function_prefix = "cogl_vertex_transform";
snippet_data.source_buf = shader_state->header;
_cogl_pipeline_snippet_generate_code (&snippet_data);
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
/* Add hooks for the point size calculation part */
if (has_per_vertex_point_size)
{
memset (&snippet_data, 0, sizeof (snippet_data));
snippet_data.snippets = vertex_snippets;
snippet_data.hook = COGL_SNIPPET_HOOK_POINT_SIZE;
snippet_data.chain_function = "cogl_real_point_size_calculation";
snippet_data.final_name = "cogl_point_size_calculation";
snippet_data.function_prefix = "cogl_point_size_calculation";
snippet_data.source_buf = shader_state->header;
_cogl_pipeline_snippet_generate_code (&snippet_data);
}
/* Add all of the hooks for vertex processing */
memset (&snippet_data, 0, sizeof (snippet_data));
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
snippet_data.snippets = vertex_snippets;
snippet_data.hook = COGL_SNIPPET_HOOK_VERTEX;
snippet_data.chain_function = "cogl_generated_source";
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
snippet_data.final_name = "cogl_vertex_hook";
snippet_data.function_prefix = "cogl_vertex_hook";
snippet_data.source_buf = shader_state->source;
_cogl_pipeline_snippet_generate_code (&snippet_data);
Flush matrices in the progend and flip with a vector Previously flushing the matrices was performed as part of the framebuffer state. When on GLES2 this matrix flushing is actually diverted so that it only keeps a reference to the intended matrix stack. This is necessary because on GLES2 there are no builtin uniforms so it can't actually flush the matrices until the program for the pipeline is generated. When the matrices are flushed it would store the age of modifications on the matrix stack so that it could detect when the matrix hasn't changed and avoid flushing it. This patch changes it so that the pipeline is responsible for flushing the matrices even when we are using the GL builtins. The same mechanism for detecting unmodified matrix stacks is used in all cases. There is a new CoglMatrixStackCache type which is used to store a reference to the intended matrix stack along with its last flushed age. There are now two of these attached to the CoglContext to track the flushed state for the global matrix builtins and also two for each glsl progend program state to track the flushed state for a program. The framebuffer matrix flush now just updates the intended matrix stacks without actually trying to flush. When a vertex snippet is attached to the pipeline, the GLSL vertend will now avoid using the projection matrix to flip the rendering. This is necessary because any vertex snippet may cause the projection matrix not to be used. Instead the flip is done as a forced final step by multiplying cogl_position_out by a vec4 uniform. This uniform is updated as part of the progend pre_paint depending on whether the framebuffer is offscreen or not. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-11-29 09:21:07 -05:00
g_string_append (shader_state->source,
"void\n"
"main ()\n"
"{\n"
" cogl_vertex_hook ();\n");
/* If there are any snippets then we can't rely on the
projection matrix to flip the rendering for offscreen buffers
so we'll need to flip it using an extra statement and a
uniform */
if (_cogl_pipeline_has_vertex_snippets (pipeline))
{
g_string_append (shader_state->header,
"uniform vec4 _cogl_flip_vector;\n");
g_string_append (shader_state->source,
" cogl_position_out *= _cogl_flip_vector;\n");
}
g_string_append (shader_state->source,
"}\n");
GE_RET( shader, ctx, glCreateShader (GL_VERTEX_SHADER) );
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
lengths[0] = shader_state->header->len;
source_strings[0] = shader_state->header->str;
lengths[1] = shader_state->source->len;
source_strings[1] = shader_state->source->str;
_cogl_glsl_shader_set_source_with_boilerplate (ctx,
shader, GL_VERTEX_SHADER,
pipeline,
2, /* count */
source_strings, lengths);
GE( ctx, glCompileShader (shader) );
GE( ctx, glGetShaderiv (shader, GL_COMPILE_STATUS, &compile_status) );
if (!compile_status)
{
GLint len = 0;
char *shader_log;
GE( ctx, glGetShaderiv (shader, GL_INFO_LOG_LENGTH, &len) );
shader_log = g_alloca (len);
GE( ctx, glGetShaderInfoLog (shader, len, &len, shader_log) );
g_warning ("Shader compilation failed:\n%s", shader_log);
}
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state->header = NULL;
shader_state->source = NULL;
shader_state->gl_shader = shader;
}
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 (_cogl_has_private_feature
(ctx, COGL_PRIVATE_FEATURE_BUILTIN_POINT_SIZE_UNIFORM) &&
(pipelines_difference & COGL_PIPELINE_STATE_POINT_SIZE))
{
CoglPipeline *authority =
_cogl_pipeline_get_authority (pipeline, COGL_PIPELINE_STATE_POINT_SIZE);
Don't generate GLSL for the point size for default pipelines Previously on GLES2 where there is no builtin point size uniform then we would always add a line to the vertex shader to write to the builtin point size output because when generating the shader it is not possible to determine if the pipeline will be used to draw points or not. This patch changes it so that the default point size is 0.0f which is documented to have undefined results when drawing points. That way we can avoid adding the point size code to the shader in that case. The assumption is that any application that is drawing points will probably have explicitly set the point size on the pipeline anyway so it is not a big deal to change the default size from 1.0f. This adds a new pipeline state flag to track whether the point size is non-zero. This needs to be its own state because altering it needs to cause a different shader to be added to the pipeline cache. The state flags that affect the vertex shader have been changed from a constant to a runtime function because they will be different depending on whether there is a builtin point size uniform. There is also a unit test to ensure that changing the point size does or doesn't generate a new shader depending on the values. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b2eba06e16b587acbf5c57944a70ceccecb4f175) Conflicts: cogl/cogl-pipeline-private.h cogl/cogl-pipeline-state-private.h cogl/cogl-pipeline-state.c cogl/cogl-pipeline.c
2013-06-20 08:25:49 -04:00
if (authority->big_state->point_size > 0.0f)
GE( ctx, glPointSize (authority->big_state->point_size) );
}
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
#endif /* HAVE_COGL_GL */
return TRUE;
}
static void
_cogl_pipeline_vertend_glsl_pre_change_notify (CoglPipeline *pipeline,
CoglPipelineState change,
const CoglColor *new_color)
{
Don't generate GLSL for the point size for default pipelines Previously on GLES2 where there is no builtin point size uniform then we would always add a line to the vertex shader to write to the builtin point size output because when generating the shader it is not possible to determine if the pipeline will be used to draw points or not. This patch changes it so that the default point size is 0.0f which is documented to have undefined results when drawing points. That way we can avoid adding the point size code to the shader in that case. The assumption is that any application that is drawing points will probably have explicitly set the point size on the pipeline anyway so it is not a big deal to change the default size from 1.0f. This adds a new pipeline state flag to track whether the point size is non-zero. This needs to be its own state because altering it needs to cause a different shader to be added to the pipeline cache. The state flags that affect the vertex shader have been changed from a constant to a runtime function because they will be different depending on whether there is a builtin point size uniform. There is also a unit test to ensure that changing the point size does or doesn't generate a new shader depending on the values. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b2eba06e16b587acbf5c57944a70ceccecb4f175) Conflicts: cogl/cogl-pipeline-private.h cogl/cogl-pipeline-state-private.h cogl/cogl-pipeline-state.c cogl/cogl-pipeline.c
2013-06-20 08:25:49 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if ((change & _cogl_pipeline_get_state_for_vertex_codegen (ctx)))
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
dirty_shader_state (pipeline);
}
/* NB: layers are considered immutable once they have any dependants
* so although multiple pipelines can end up depending on a single
* static layer, we can guarantee that if a layer is being *changed*
* then it can only have one pipeline depending on it.
*
* XXX: Don't forget this is *pre* change, we can't read the new value
* yet!
*/
static void
_cogl_pipeline_vertend_glsl_layer_pre_change_notify (
CoglPipeline *owner,
CoglPipelineLayer *layer,
CoglPipelineLayerState change)
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
CoglPipelineShaderState *shader_state;
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
shader_state = get_shader_state (owner);
if (!shader_state)
return;
if ((change & COGL_PIPELINE_LAYER_STATE_AFFECTS_VERTEX_CODEGEN))
{
pipeline: Unify how the backends store private data Previously the fragends had a separate private data pointer which was used by the GLSL and ARBfp fragends to store a tiny struct containing a single pointer to the ref-counted shader state. The space for the private data pointer is reserved in all of the pipelines for all of the potential backends. The vertends and progends however did this differently by directly storing the pointer to the ref counted data using cogl_object_set_user_data. This patch unifies the different methods so that they all use cogl_object_set_user_data and the fragends don't bother with the separate tiny allocation for the private data. The private data pointer array has been removed from CoglPipeline and the corresponding fragend virtual to free the private data has also been removed because this can instead be done with the destroy notify from the object user data. The variable names used have been unified so that all of the vertends and fragends name their data struct CoglPipelineShaderState and use a variable called shader_state to refer to it. The progend uses CoglPipelineProgramState and a variable called program_state. This should also fix two potential bugs. the ARBfp fragend was apprently leaking a reference to the private state when it creates the private data because it was adding a reference before stroring the pointer to the newly allocated data but the ref count is already set to 1 on creation. The other potential bug is that the free function for CoglPipeline was only calling the free_priv virtual for the currently used fragend of the pipeline. The design of the fragends is meant to allow a pipeline to have multiple fragend priv datas because a child pipeline could be attaching its fragend data to the ancestor and its allowed to pick a different fragend.
2011-06-30 08:39:48 -04:00
dirty_shader_state (owner);
return;
}
/* TODO: we could be saving snippets of texture combine code along
* with each layer and then when a layer changes we would just free
* the snippet. */
}
const CoglPipelineVertend _cogl_pipeline_glsl_vertend =
{
_cogl_pipeline_vertend_glsl_start,
_cogl_pipeline_vertend_glsl_add_layer,
_cogl_pipeline_vertend_glsl_end,
_cogl_pipeline_vertend_glsl_pre_change_notify,
_cogl_pipeline_vertend_glsl_layer_pre_change_notify
};
Don't generate GLSL for the point size for default pipelines Previously on GLES2 where there is no builtin point size uniform then we would always add a line to the vertex shader to write to the builtin point size output because when generating the shader it is not possible to determine if the pipeline will be used to draw points or not. This patch changes it so that the default point size is 0.0f which is documented to have undefined results when drawing points. That way we can avoid adding the point size code to the shader in that case. The assumption is that any application that is drawing points will probably have explicitly set the point size on the pipeline anyway so it is not a big deal to change the default size from 1.0f. This adds a new pipeline state flag to track whether the point size is non-zero. This needs to be its own state because altering it needs to cause a different shader to be added to the pipeline cache. The state flags that affect the vertex shader have been changed from a constant to a runtime function because they will be different depending on whether there is a builtin point size uniform. There is also a unit test to ensure that changing the point size does or doesn't generate a new shader depending on the values. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b2eba06e16b587acbf5c57944a70ceccecb4f175) Conflicts: cogl/cogl-pipeline-private.h cogl/cogl-pipeline-state-private.h cogl/cogl-pipeline-state.c cogl/cogl-pipeline.c
2013-06-20 08:25:49 -04:00
UNIT_TEST (check_point_size_shader,
0 /* no requirements */,
0 /* no failure cases */)
{
CoglPipeline *pipelines[4];
CoglPipelineShaderState *shader_states[G_N_ELEMENTS (pipelines)];
int i;
/* Default pipeline with zero point size */
pipelines[0] = cogl_pipeline_new (test_ctx);
/* Point size 1 */
pipelines[1] = cogl_pipeline_new (test_ctx);
cogl_pipeline_set_point_size (pipelines[1], 1.0f);
/* Point size 2 */
pipelines[2] = cogl_pipeline_new (test_ctx);
cogl_pipeline_set_point_size (pipelines[2], 2.0f);
/* Same as the first pipeline, but reached by restoring the old
* state from a copy */
pipelines[3] = cogl_pipeline_copy (pipelines[1]);
cogl_pipeline_set_point_size (pipelines[3], 0.0f);
/* Draw something with all of the pipelines to make sure their state
* is flushed */
for (i = 0; i < G_N_ELEMENTS (pipelines); i++)
cogl_framebuffer_draw_rectangle (test_fb,
pipelines[i],
0.0f, 0.0f,
10.0f, 10.0f);
cogl_framebuffer_finish (test_fb);
/* Get all of the shader states. These might be NULL if the driver
* is not using GLSL */
for (i = 0; i < G_N_ELEMENTS (pipelines); i++)
shader_states[i] = get_shader_state (pipelines[i]);
/* If the first two pipelines are using GLSL then they should have
* the same shader unless there is no builtin uniform for the point
* size */
if (shader_states[0])
{
if (_cogl_has_private_feature
(test_ctx, COGL_PRIVATE_FEATURE_BUILTIN_POINT_SIZE_UNIFORM))
Don't generate GLSL for the point size for default pipelines Previously on GLES2 where there is no builtin point size uniform then we would always add a line to the vertex shader to write to the builtin point size output because when generating the shader it is not possible to determine if the pipeline will be used to draw points or not. This patch changes it so that the default point size is 0.0f which is documented to have undefined results when drawing points. That way we can avoid adding the point size code to the shader in that case. The assumption is that any application that is drawing points will probably have explicitly set the point size on the pipeline anyway so it is not a big deal to change the default size from 1.0f. This adds a new pipeline state flag to track whether the point size is non-zero. This needs to be its own state because altering it needs to cause a different shader to be added to the pipeline cache. The state flags that affect the vertex shader have been changed from a constant to a runtime function because they will be different depending on whether there is a builtin point size uniform. There is also a unit test to ensure that changing the point size does or doesn't generate a new shader depending on the values. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit b2eba06e16b587acbf5c57944a70ceccecb4f175) Conflicts: cogl/cogl-pipeline-private.h cogl/cogl-pipeline-state-private.h cogl/cogl-pipeline-state.c cogl/cogl-pipeline.c
2013-06-20 08:25:49 -04:00
g_assert (shader_states[0] == shader_states[1]);
else
g_assert (shader_states[0] != shader_states[1]);
}
/* The second and third pipelines should always have the same shader
* state because only toggling between zero and non-zero should
* change the shader */
g_assert (shader_states[1] == shader_states[2]);
/* The fourth pipeline should be exactly the same as the first */
g_assert (shader_states[0] == shader_states[3]);
}
#endif /* COGL_PIPELINE_VERTEND_GLSL */