brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
5c12c36c58
mutter/cogl/cogl-program-private.h

83 lines
2.5 KiB
C
Raw Normal View History

Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 17:00:29 +00:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2008,2009 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/>.
*
*
*/
#ifndef __COGL_PROGRAM_H
#define __COGL_PROGRAM_H
Removes all remaining use of CoglHandle Removing CoglHandle has been an on going goal for quite a long time now and finally this patch removes the last remaining uses of the CoglHandle type and the cogl_handle_ apis. Since the big remaining users of CoglHandle were the cogl_program_ and cogl_shader_ apis which have replaced with the CoglSnippets api this patch removes both of these apis. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 6ed3aaf4be21d605a1ed3176b3ea825933f85cf0) Since the original patch was done after removing deprecated API this back ported patch doesn't affect deprecated API and so actually this cherry-pick doesn't remove all remaining use of CoglHandle as it did for the master branch of Cogl.
2012-04-16 13:14:10 +00:00
#include "cogl-object-private.h"
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 17:00:29 +00:00
#include "cogl-internal.h"
#include "cogl-shader-private.h"
typedef struct _CoglProgram CoglProgram;
struct _CoglProgram
{
CoglHandleObject _parent;
GSList *attached_shaders;
GArray *custom_uniforms;
/* An age counter that changes whenever the list of shaders is modified */
unsigned int age;
};
typedef struct _CoglProgramUniform CoglProgramUniform;
struct _CoglProgramUniform
{
char *name;
CoglBoxedValue value;
/* The cached GL location for this uniform. This is only valid
between calls to _cogl_program_dirty_all_uniforms */
GLint location;
/* Whether we have a location yet */
unsigned int location_valid : 1;
/* Whether the uniform value has changed since the last time the
uniforms were flushed */
unsigned int dirty : 1;
};
/* Internal function to flush the custom uniforms for the given use
program. This assumes the target GL program is already bound. The
gl_program still needs to be passed so that CoglProgram can query
the uniform locations. gl_program_changed should be set to TRUE if
we are flushing the uniforms against a different GL program from
the last time it was flushed. This will cause it to requery all of
the locations and assume that all uniforms are dirty */
void
_cogl_program_flush_uniforms (CoglProgram *program,
GLuint gl_program,
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 20:56:40 +00:00
CoglBool gl_program_changed);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 17:00:29 +00:00
CoglShaderLanguage
_cogl_program_get_language (CoglHandle handle);
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 20:56:40 +00:00
CoglBool
cogl-program: Add private functions to check if have each shader type This adds two internal functions: gboolean _cogl_program_has_fragment_shader (CoglHandle handle); gboolean _cogl_program_has_vertex_shader (CoglHandle handle); They just check whether any of the contained shaders are of that type.
2010-12-02 13:54:15 +00:00
_cogl_program_has_fragment_shader (CoglHandle handle);
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 20:56:40 +00:00
CoglBool
cogl-program: Add private functions to check if have each shader type This adds two internal functions: gboolean _cogl_program_has_fragment_shader (CoglHandle handle); gboolean _cogl_program_has_vertex_shader (CoglHandle handle); They just check whether any of the contained shaders are of that type.
2010-12-02 13:54:15 +00:00
_cogl_program_has_vertex_shader (CoglHandle handle);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 17:00:29 +00:00
#endif /* __COGL_PROGRAM_H */
Reference in New Issue Copy Permalink