mutter/cogl/cogl-program.c

497 lines
14 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 13:00:29 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2008,2009,2010 Intel Corporation.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
*
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "cogl-util.h"
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
#include "cogl-internal.h"
#include "cogl-context-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 13:00:29 -04:00
#include "cogl-handle.h"
#include "cogl-shader-private.h"
#include "cogl-program-private.h"
#include <string.h>
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
static void _cogl_program_free (CoglProgram *program);
COGL_HANDLE_DEFINE (Program, program);
COGL_OBJECT_DEFINE_DEPRECATED_REF_COUNTING (program);
/* A CoglProgram is effectively just a list of shaders that will be
used together and a set of values for the custom uniforms. No
actual GL program is created - instead this is the responsibility
of the GLSL material backend. The uniform values are collected in
an array and then flushed whenever the material backend requests
it. */
static void
_cogl_program_free (CoglProgram *program)
{
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
/* Unref all of the attached shaders */
g_slist_foreach (program->attached_shaders, (GFunc) cogl_handle_unref, NULL);
/* Destroy the list */
g_slist_free (program->attached_shaders);
for (i = 0; i < program->custom_uniforms->len; i++)
{
CoglProgramUniform *uniform =
&g_array_index (program->custom_uniforms, CoglProgramUniform, i);
g_free (uniform->name);
if (uniform->value.count > 1)
g_free (uniform->value.v.array);
}
g_array_free (program->custom_uniforms, TRUE);
g_slice_free (CoglProgram, program);
}
CoglHandle
cogl_create_program (void)
{
CoglProgram *program;
program = g_slice_new0 (CoglProgram);
program->custom_uniforms =
g_array_new (FALSE, FALSE, sizeof (CoglProgramUniform));
program->age = 0;
return _cogl_program_handle_new (program);
}
void
cogl_program_attach_shader (CoglHandle program_handle,
CoglHandle shader_handle)
{
CoglProgram *program;
CoglShader *shader;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (!cogl_is_program (program_handle) || !cogl_is_shader (shader_handle))
return;
program = _cogl_program_pointer_from_handle (program_handle);
shader = _cogl_shader_pointer_from_handle (shader_handle);
/* Only one shader is allowed if the type is ARBfp */
if (shader->language == COGL_SHADER_LANGUAGE_ARBFP)
_COGL_RETURN_IF_FAIL (program->attached_shaders == NULL);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
else if (shader->language == COGL_SHADER_LANGUAGE_GLSL)
_COGL_RETURN_IF_FAIL (_cogl_program_get_language (program) ==
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
COGL_SHADER_LANGUAGE_GLSL);
program->attached_shaders
= g_slist_prepend (program->attached_shaders,
cogl_handle_ref (shader_handle));
program->age++;
}
void
cogl_program_link (CoglHandle handle)
{
/* There's no point in linking the program here because it will have
to be relinked with a different fixed functionality shader
whenever the settings change */
}
void
cogl_program_use (CoglHandle handle)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
_COGL_RETURN_IF_FAIL (handle == COGL_INVALID_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 13:00:29 -04:00
cogl_is_program (handle));
if (ctx->current_program == 0 && handle != 0)
ctx->legacy_state_set++;
else if (handle == 0 && ctx->current_program != 0)
ctx->legacy_state_set--;
if (handle != COGL_INVALID_HANDLE)
cogl_handle_ref (handle);
if (ctx->current_program != COGL_INVALID_HANDLE)
cogl_handle_unref (ctx->current_program);
ctx->current_program = handle;
}
int
cogl_program_get_uniform_location (CoglHandle handle,
const char *uniform_name)
{
int i;
CoglProgram *program;
CoglProgramUniform *uniform;
if (!cogl_is_program (handle))
return -1;
program = _cogl_program_pointer_from_handle (handle);
/* We can't just ask the GL program object for the uniform location
directly because it will change every time the program is linked
with a different shader. Instead we make our own mapping of
uniform numbers and cache the names */
for (i = 0; i < program->custom_uniforms->len; i++)
{
uniform = &g_array_index (program->custom_uniforms,
CoglProgramUniform, i);
if (!strcmp (uniform->name, uniform_name))
return i;
}
/* Create a new uniform with the given name */
g_array_set_size (program->custom_uniforms,
program->custom_uniforms->len + 1);
uniform = &g_array_index (program->custom_uniforms,
CoglProgramUniform,
program->custom_uniforms->len - 1);
uniform->name = g_strdup (uniform_name);
memset (&uniform->value, 0, sizeof (CoglBoxedValue));
uniform->dirty = TRUE;
uniform->location_valid = FALSE;
return program->custom_uniforms->len - 1;
}
static CoglProgramUniform *
cogl_program_modify_uniform (CoglProgram *program,
int uniform_no)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
CoglProgramUniform *uniform;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_RETURN_VAL_IF_FAIL (cogl_is_program (program), NULL);
_COGL_RETURN_VAL_IF_FAIL (uniform_no >= 0 &&
uniform_no < program->custom_uniforms->len,
NULL);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
uniform = &g_array_index (program->custom_uniforms,
CoglProgramUniform, uniform_no);
uniform->dirty = TRUE;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
return uniform;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_uniform_1f (int uniform_no,
float value)
{
CoglProgramUniform *uniform;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
uniform = cogl_program_modify_uniform (ctx->current_program, uniform_no);
_cogl_boxed_value_set_1f (&uniform->value, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_set_uniform_1f (CoglHandle handle,
int uniform_location,
float value)
{
CoglProgramUniform *uniform;
uniform = cogl_program_modify_uniform (handle, uniform_location);
_cogl_boxed_value_set_1f (&uniform->value, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_uniform_1i (int uniform_no,
int value)
{
CoglProgramUniform *uniform;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
uniform = cogl_program_modify_uniform (ctx->current_program, uniform_no);
_cogl_boxed_value_set_1i (&uniform->value, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_set_uniform_1i (CoglHandle handle,
int uniform_location,
int value)
{
CoglProgramUniform *uniform;
uniform = cogl_program_modify_uniform (handle, uniform_location);
_cogl_boxed_value_set_1i (&uniform->value, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_uniform_float (int uniform_no,
int size,
int count,
const float *value)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
CoglProgramUniform *uniform;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
uniform = cogl_program_modify_uniform (ctx->current_program, uniform_no);
_cogl_boxed_value_set_float (&uniform->value, size, count, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_set_uniform_float (CoglHandle handle,
int uniform_location,
int n_components,
int count,
const float *value)
{
CoglProgramUniform *uniform;
uniform = cogl_program_modify_uniform (handle, uniform_location);
_cogl_boxed_value_set_float (&uniform->value, n_components, count, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_uniform_int (int uniform_no,
int size,
int count,
const int *value)
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
{
CoglProgramUniform *uniform;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
uniform = cogl_program_modify_uniform (ctx->current_program, uniform_no);
_cogl_boxed_value_set_int (&uniform->value, size, count, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_set_uniform_int (CoglHandle handle,
int uniform_location,
int n_components,
int count,
const int *value)
{
CoglProgramUniform *uniform;
uniform = cogl_program_modify_uniform (handle, uniform_location);
_cogl_boxed_value_set_int (&uniform->value, n_components, count, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_set_uniform_matrix (CoglHandle handle,
int uniform_location,
int dimensions,
int count,
gboolean transpose,
const float *value)
{
CoglProgramUniform *uniform;
uniform = cogl_program_modify_uniform (handle, uniform_location);
_cogl_boxed_value_set_matrix (&uniform->value,
dimensions,
count,
transpose,
value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
void
cogl_program_uniform_matrix (int uniform_no,
int size,
int count,
gboolean transpose,
const float *value)
{
CoglProgramUniform *uniform;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
uniform = cogl_program_modify_uniform (ctx->current_program, uniform_no);
_cogl_boxed_value_set_matrix (&uniform->value, size, count, transpose, value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
/* ARBfp local parameters can be referenced like:
*
* "program.local[5]"
* ^14char offset (after whitespace is stripped)
*/
static int
get_local_param_index (const char *uniform_name)
{
char *input = g_strdup (uniform_name);
int i;
char *p = input;
char *endptr;
int _index;
for (i = 0; input[i] != '\0'; i++)
if (input[i] != '_' && input[i] != '\t')
*p++ = input[i];
input[i] = '\0';
_COGL_RETURN_VAL_IF_FAIL (strncmp ("program.local[", input, 14) == 0, -1);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_index = g_ascii_strtoull (input + 14, &endptr, 10);
_COGL_RETURN_VAL_IF_FAIL (endptr != input + 14, -1);
_COGL_RETURN_VAL_IF_FAIL (*endptr == ']', -1);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_COGL_RETURN_VAL_IF_FAIL (_index >= 0, -1);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
g_free (input);
return _index;
}
#ifdef HAVE_COGL_GL
static void
_cogl_program_flush_uniform_arbfp (GLint location,
CoglBoxedValue *value)
{
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
if (value->type != COGL_BOXED_NONE)
{
_COGL_RETURN_IF_FAIL (value->type == COGL_BOXED_FLOAT);
_COGL_RETURN_IF_FAIL (value->size == 4);
_COGL_RETURN_IF_FAIL (value->count == 1);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
GE( ctx, glProgramLocalParameter4fv (GL_FRAGMENT_PROGRAM_ARB, location,
value->v.float_value) );
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
}
#endif /* HAVE_COGL_GL */
void
_cogl_program_flush_uniforms (CoglProgram *program,
GLuint gl_program,
gboolean gl_program_changed)
{
CoglProgramUniform *uniform;
int i;
_COGL_GET_CONTEXT (ctx, NO_RETVAL);
_COGL_RETURN_IF_FAIL (ctx->driver != COGL_DRIVER_GLES1);
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
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
for (i = 0; i < program->custom_uniforms->len; i++)
{
uniform = &g_array_index (program->custom_uniforms,
CoglProgramUniform, i);
if (gl_program_changed || uniform->dirty)
{
if (gl_program_changed || !uniform->location_valid)
{
if (_cogl_program_get_language (program) ==
COGL_SHADER_LANGUAGE_GLSL)
uniform->location =
ctx->glGetUniformLocation (gl_program, uniform->name);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
else
uniform->location =
get_local_param_index (uniform->name);
uniform->location_valid = TRUE;
}
/* If the uniform isn't really in the program then there's
no need to actually set it */
if (uniform->location != -1)
{
switch (_cogl_program_get_language (program))
{
case COGL_SHADER_LANGUAGE_GLSL:
_cogl_boxed_value_set_uniform (ctx,
uniform->location,
&uniform->value);
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
break;
case COGL_SHADER_LANGUAGE_ARBFP:
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
#ifdef HAVE_COGL_GL
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
_cogl_program_flush_uniform_arbfp (uniform->location,
&uniform->value);
#endif
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
break;
Merge cogl-program-{gl,gles}.c into one cogl-program.c This merges the two implementations of CoglProgram for the GLES2 and GL backends into one. The implementation is more like the GLES2 version which would track the uniform values and delay sending them to GL. CoglProgram is now effectively just a GList of CoglShaders along with an array of stored uniform values. CoglProgram never actually creates a GL program, instead this is left up to the GLSL material backend. This is necessary on GLES2 where we may need to relink the user's program with different generated shaders depending on the other emulated fixed function state. It will also be necessary in the future GLSL backends for regular OpenGL. The GLSL and ARBfp material backends are now the ones that create and link the GL program from the list of shaders. The linked program is attached to the private material state so that it can be reused if the CoglProgram is used again with the same material. This does mean the program will get relinked if the shader is used with multiple materials. This will be particularly bad if the legacy cogl_program_use function is used because that effectively always makes one-shot materials. This problem will hopefully be alleviated if we make a hash table with a cache of generated programs. The cogl program would then need to become part of the hash lookup. Each CoglProgram now has an age counter which is incremented every time a shader is added. This is used by the material backends to detect when we need to create a new GL program for the user program. The internal _cogl_use_program function now takes a GL program handle rather than a CoglProgram. It no longer needs any special differences for GLES2. The GLES2 wrapper function now also uses this function to bind its generated shaders. The ARBfp shaders no longer store a copy of the program source but instead just directly create a program object when cogl_shader_source is called. This avoids having to reupload the source if the same shader is used in multiple materials. There are currently a few gross hacks to get the GLES2 backend to work with this. The problem is that the GLSL material backend is now generating a complete GL program but the GLES2 wrapper still needs to add its fixed function emulation shaders if the program doesn't provide either a vertex or fragment shader. There is a new function in the GLES2 wrapper called _cogl_gles2_use_program which replaces the previous cogl_program_use implementation. It extracts the GL shaders from the GL program object and creates a new GL program containing all of the shaders plus its fixed function emulation. This new program is returned to the GLSL material backend so that it can still flush the custom uniforms using it. The user_program is attached to the GLES2 settings struct as before but its stored using a GL program handle rather than a CoglProgram pointer. This hack will go away once the GLSL material backend replaces the GLES2 wrapper by generating the code itself. Under Mesa this currently generates some GL errors when glClear is called in test-cogl-shader-glsl. I think this is due to a bug in Mesa however. When the user program on the material is changed the GLSL backend gets notified and deletes the GL program that it linked from the user shaders. The program will still be bound in GL however. Leaving a deleted shader bound exposes a bug in Mesa's glClear implementation. More details are here: https://bugs.freedesktop.org/show_bug.cgi?id=31194
2010-10-15 13:00:29 -04:00
}
}
uniform->dirty = FALSE;
}
}
}
CoglShaderLanguage
_cogl_program_get_language (CoglHandle handle)
{
CoglProgram *program = handle;
/* Use the language of the first shader */
if (program->attached_shaders)
{
CoglShader *shader = program->attached_shaders->data;
return shader->language;
}
else
return COGL_SHADER_LANGUAGE_GLSL;
}
static gboolean
_cogl_program_has_shader_type (CoglProgram *program,
CoglShaderType type)
{
GSList *l;
for (l = program->attached_shaders; l; l = l->next)
{
CoglShader *shader = l->data;
if (shader->type == type)
return TRUE;
}
return FALSE;
}
gboolean
_cogl_program_has_fragment_shader (CoglHandle handle)
{
return _cogl_program_has_shader_type (handle, COGL_SHADER_TYPE_FRAGMENT);
}
gboolean
_cogl_program_has_vertex_shader (CoglHandle handle)
{
return _cogl_program_has_shader_type (handle, COGL_SHADER_TYPE_VERTEX);
}