brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
66c75f9a9d
mutter/cogl/cogl-pipeline-cache.c

283 lines
8.9 KiB
C
Raw Normal View History

fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2011 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>
* Robert Bragg <robert@linux.intel.com>
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
cogl-pipeline/cogl-pango: Added forgotten includes It seems that cogl-context-private.h needs to be included before including any of the pipeline-related stuff to avoid build errors on C89 compilers. This is due to the recent cogl-pipeline decoupling, seems like. Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-09-23 04:43:05 -04:00
#include "cogl-context-private.h"
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
#include "cogl-pipeline-private.h"
#include "cogl-pipeline-cache.h"
struct _CoglPipelineCache
{
GHashTable *fragment_hash;
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
GHashTable *vertex_hash;
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
GHashTable *combined_hash;
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
};
static unsigned int
pipeline_fragment_hash (const void *data)
{
unsigned int fragment_state;
unsigned int layer_fragment_state;
_COGL_GET_CONTEXT (ctx, 0);
fragment_state =
_cogl_pipeline_get_state_for_fragment_codegen (ctx);
layer_fragment_state =
_cogl_pipeline_get_layer_state_for_fragment_codegen (ctx);
return _cogl_pipeline_hash ((CoglPipeline *)data,
fragment_state, layer_fragment_state,
0);
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
pipeline_fragment_equal (const void *a, const void *b)
{
unsigned int fragment_state;
unsigned int layer_fragment_state;
_COGL_GET_CONTEXT (ctx, 0);
fragment_state =
_cogl_pipeline_get_state_for_fragment_codegen (ctx);
layer_fragment_state =
_cogl_pipeline_get_layer_state_for_fragment_codegen (ctx);
return _cogl_pipeline_equal ((CoglPipeline *)a, (CoglPipeline *)b,
fragment_state, layer_fragment_state,
0);
}
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
static unsigned int
pipeline_vertex_hash (const void *data)
{
unsigned long vertex_state =
COGL_PIPELINE_STATE_AFFECTS_VERTEX_CODEGEN;
unsigned long layer_vertex_state =
COGL_PIPELINE_LAYER_STATE_AFFECTS_VERTEX_CODEGEN;
return _cogl_pipeline_hash ((CoglPipeline *)data,
vertex_state, layer_vertex_state,
0);
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
pipeline_vertex_equal (const void *a, const void *b)
{
unsigned long vertex_state =
COGL_PIPELINE_STATE_AFFECTS_VERTEX_CODEGEN;
unsigned long layer_vertex_state =
COGL_PIPELINE_LAYER_STATE_AFFECTS_VERTEX_CODEGEN;
return _cogl_pipeline_equal ((CoglPipeline *)a, (CoglPipeline *)b,
vertex_state, layer_vertex_state,
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 unsigned int
pipeline_combined_hash (const void *data)
{
unsigned int combined_state;
unsigned int layer_combined_state;
_COGL_GET_CONTEXT (ctx, 0);
combined_state =
_cogl_pipeline_get_state_for_fragment_codegen (ctx) |
COGL_PIPELINE_STATE_AFFECTS_VERTEX_CODEGEN;
layer_combined_state =
_cogl_pipeline_get_layer_state_for_fragment_codegen (ctx) |
COGL_PIPELINE_LAYER_STATE_AFFECTS_VERTEX_CODEGEN;
return _cogl_pipeline_hash ((CoglPipeline *)data,
combined_state, layer_combined_state,
0);
}
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool
cogl-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
pipeline_combined_equal (const void *a, const void *b)
{
unsigned int combined_state;
unsigned int layer_combined_state;
_COGL_GET_CONTEXT (ctx, 0);
combined_state =
_cogl_pipeline_get_state_for_fragment_codegen (ctx) |
COGL_PIPELINE_STATE_AFFECTS_VERTEX_CODEGEN;
layer_combined_state =
_cogl_pipeline_get_layer_state_for_fragment_codegen (ctx) |
COGL_PIPELINE_LAYER_STATE_AFFECTS_VERTEX_CODEGEN;
return _cogl_pipeline_equal ((CoglPipeline *)a, (CoglPipeline *)b,
combined_state, layer_combined_state,
0);
}
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
CoglPipelineCache *
build: Hide cogl_pipeline_cache_{new,free}() Those symbols should not be public and were exported as they started with cogl_. (cherry picked from commit 68a55f1dc70ea60fcccbe226029e585886feddc2)
2013-01-01 09:15:25 -05:00
_cogl_pipeline_cache_new (void)
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
{
CoglPipelineCache *cache = g_new (CoglPipelineCache, 1);
cache->fragment_hash = g_hash_table_new_full (pipeline_fragment_hash,
pipeline_fragment_equal,
cogl_object_unref,
cogl_object_unref);
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
cache->vertex_hash = g_hash_table_new_full (pipeline_vertex_hash,
pipeline_vertex_equal,
cogl_object_unref,
cogl_object_unref);
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
cache->combined_hash = g_hash_table_new_full (pipeline_combined_hash,
pipeline_combined_equal,
cogl_object_unref,
cogl_object_unref);
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
return cache;
}
void
build: Hide cogl_pipeline_cache_{new,free}() Those symbols should not be public and were exported as they started with cogl_. (cherry picked from commit 68a55f1dc70ea60fcccbe226029e585886feddc2)
2013-01-01 09:15:25 -05:00
_cogl_pipeline_cache_free (CoglPipelineCache *cache)
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
{
g_hash_table_destroy (cache->fragment_hash);
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
g_hash_table_destroy (cache->vertex_hash);
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
g_hash_table_destroy (cache->combined_hash);
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
g_free (cache);
}
CoglPipeline *
_cogl_pipeline_cache_get_fragment_template (CoglPipelineCache *cache,
CoglPipeline *key_pipeline)
{
CoglPipeline *template =
g_hash_table_lookup (cache->fragment_hash, key_pipeline);
if (template == NULL)
{
/* XXX: I wish there was a way to insert into a GHashTable with
* a pre-calculated hash value since there is a cost to
* calculating the hash of a CoglPipeline and in this case we
* know we have already called _cogl_pipeline_hash during the
* lookup so we could pass the value through to here to avoid
* hashing it again.
*/
/* XXX: Any keys referenced by the hash table need to remain
* valid all the while that there are corresponding values,
* so for now we simply make a copy of the current authority
* pipeline.
*
* FIXME: A problem with this is that our key into the cache may
* hold references to some arbitrary user textures which will
* now be kept alive indefinitly which is a shame. A better
* solution will be to derive a special "key pipeline" from the
* authority which derives from the base Cogl pipeline (to avoid
* affecting the lifetime of any other pipelines) and only takes
* a copy of the state that relates to the fragment shader and
* references small dummy textures instead of potentially large
* user textures. */
template = cogl_pipeline_copy (key_pipeline);
g_hash_table_insert (cache->fragment_hash,
template,
cogl_object_ref (template));
if (G_UNLIKELY (g_hash_table_size (cache->fragment_hash) > 50))
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool seen = FALSE;
fragend-arbfp: Move the pipeline cache to a separate file The pipeline cache is now handled in CoglPipelineCache instead of directly in the ARBfp fragend. The flags needed to hash a pipeline should be exactly the same for the ARBfp and GLSL fragends so it's convenient to share the code. The hash table now stores the actual pipeline as the value instead of the private data so that the two fragends can attach their data to it. That way it's possible to use the same pipeline key with ancestors that are using different fragends. The hash table is created with g_hash_table_new_full to set a destructor for the key and value and there is a destructor for CoglPipelineCache that gets called when the CoglContext is destroyed. That way we no longer leak the pipelines and shader state when the context is desroyed.
2011-06-30 10:55:56 -04:00
if (!seen)
g_warning ("Over 50 separate fragment shaders have been "
"generated which is very unusual, so something "
"is probably wrong!\n");
seen = TRUE;
}
}
return template;
}
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
CoglPipeline *
_cogl_pipeline_cache_get_vertex_template (CoglPipelineCache *cache,
CoglPipeline *key_pipeline)
{
CoglPipeline *template =
g_hash_table_lookup (cache->vertex_hash, key_pipeline);
if (template == NULL)
{
template = cogl_pipeline_copy (key_pipeline);
g_hash_table_insert (cache->vertex_hash,
template,
cogl_object_ref (template));
if (G_UNLIKELY (g_hash_table_size (cache->vertex_hash) > 50))
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool seen = FALSE;
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
if (!seen)
g_warning ("Over 50 separate vertex shaders have been "
"generated which is very unusual, so something "
"is probably wrong!\n");
seen = TRUE;
}
}
return template;
}
CoglPipeline *
_cogl_pipeline_cache_get_combined_template (CoglPipelineCache *cache,
CoglPipeline *key_pipeline)
{
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
CoglPipeline *template =
g_hash_table_lookup (cache->combined_hash, key_pipeline);
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
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
if (template == NULL)
{
template = cogl_pipeline_copy (key_pipeline);
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
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
g_hash_table_insert (cache->combined_hash,
template,
cogl_object_ref (template));
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
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
if (G_UNLIKELY (g_hash_table_size (cache->combined_hash) > 50))
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 16:56:40 -04:00
static CoglBool seen = FALSE;
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
if (!seen)
g_warning ("Over 50 separate programs have been "
"generated which is very unusual, so something "
"is probably wrong!\n");
seen = TRUE;
}
}
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
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
return template;
cogl-pipeline: Use the pipeline cache for the GLSL backends The CoglPipelineCache is now extended to store templates for state affecting vertex shaders and combined programs. The GLSL fragend, vertend and progend now uses this to get cached shaders and a program. When a new pipeline is created it will now get hashed three times if the GLSL backends are in use (once for the fragend, once for the vertend and once for the progend). Ideally we should add some way for the progend to check its cache before the fragends and vertends are checked so that it can bypass them entirely if it can find a cached combined program.
2011-06-30 13:34:05 -04:00
}
Reference in New Issue Copy Permalink