Instead of storing the GLenum for the target of the last used texture
for a layer it now stores the CoglTextureType instead. The state name
has been renamed to 'texture type' instead of 'texture target'.
Previously the default pipeline layer would store 0 here to represent
that there is no texture. This has been changed to store
COGL_TEXTURE_TYPE_2D instead which means that all pipeline layers
always have a valid value for the texture type. Any places that were
previously fetching the texture from a layer to determine the target
(for example when generating shaders or when enabling a particular
texture target) now use the texture type instead. This means they will
work even for layers that don't have a texture.
This also changes it so that when binding a fallback texture instead
of always using a 2D texture it will now use the default texture
corresponding to the texture type of the layer. That way when the
generated shader tries to do a texture lookup for that type of texture
it will get a valid texture object. To make this work the patch adds a
default texture for 3D textures to the context and also makes the
default rectangle texture actually be a rectangle texture instead of
using a 2D texture.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Previously the function containing the default texture lookup is
always generated regardless of whether there is a snippet with a
replace string which would cause it not be used. Now this snippets are
all scanned to check for replace strings before generating the texture
lookup.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The variables caching the result of texture lookups and layer
calculations are now stored in global variables so that when a hook
for the layer processing is added the variables can still be accessed
even if the generated code is within a separate function.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Instead of specifying the hook point when adding to the pipeline using
a separate function for each hook, the hook is now a property of the
snippet. The hook is set on construction and is then read-only.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds a per-layer snippet hook for the texure lookup. Here the
snippet can modify the texture coordinates used for the lookup or
modify the texel resulting from the lookup. This is the first
per-layer hook so this also adds the
COGL_PIPELINE_LAYER_STATE_FRAGMENT_SNIPPETS state and all of the
boilerplate needed to make that work.
Most of the functions used by the pipeline state to manage the snippet
list has been moved into cogl-pipeline-snippet.c so that it can be
shared with the layer state.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The two loops that generate the functions for the snippets in the
fragend and vertend are very similar so to avoid code duplication this
patch moves the logic to its own function in a new
cogl-pipeline-snippet.c file.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
If present, the 'replace' string will be used instead of whatever code
would normally be invoked for that hook point. It will also replace
any previous snippets.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Each snippet is now given its own function which contains the pre and
post strings. Between these strings the function will chain on to
another function. The generated cogl source is now stored in a
function called cogl_generated_source() which the last snippet will
chain on to. This should make it so that each snippet has its own
namespace for local variables and it can share variables declared in
the pre string in the post string. Hopefully the GLSL compiler will
just inline all of the functions so it shouldn't make much difference
to the compiled output.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds two new public experimental functions for attaching
CoglSnippets to two hook points on a CoglPipeline:
void cogl_pipeline_add_vertex_hook (CoglPipeline *, CoglSnippet *)
void cogl_pipeline_add_fragment_hook (CoglPipeline *, CoglSnippet *)
The hooks are intended to be around the entire vertex or fragment
processing. That means the pre string in the snippet will be inserted
at the very top of the main function and the post function will be
inserted at the very end. The declarations get inserted in the global
scope.
The snippets are stored in two separate linked lists with a structure
containing an enum representing the hook point and a pointer to the
snippet. The lists are meant to be for hooks that affect the vertex
shader and fragment shader respectively. Although there are currently
only two hooks and the names match these two lists, the intention is
*not* that each new hook will be in a separate list. The separation of
the lists is just to make it easier to determine which shader needs to
be regenerated when a new snippet is added.
When a pipeline becomes the authority for either the vertex or
fragment snipper state, it simply copies the entire list from the
previous authority (although of course the shader snippet objects are
referenced instead of copied so it doesn't duplicate the source
strings).
Each string is inserted into its own block in the shader. This means
that each string has its own scope so it doesn't need to worry about
name collisions with variables in other snippets. However it does mean
that the pre and post strings can't share variables. It could be
possible to wrap both parts in one block and then wrap the actual
inner hook code in another block, however this would mean that any
further snippets within the outer snippet would be able to see those
variables. Perhaps something to consider would be to put each snippet
into its own function which calls another function between the pre and
post strings to do further processing.
The pipeline cache for generated programs was previously shared with
the fragment shader cache because the state that affects vertex
shaders was a subset of the state that affects fragment shaders. This
is no longer the case because there is a separate state mask for
vertex snippets so the program cache now has its own hash table.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
On GLES2, we need to specify an array size for the texture coord
varying array. Previously this size would be decided in one of the
following ways:
- For generated vertex shaders it is always the number of layers in
the pipeline.
- For generated fragment shaders it is the highest sampled texture
unit in the pipeline or the number of attributes supplied by the
primitive, whichever is higher.
- For user shaders it is usually the number of attributes supplied by
the primitive. However, if the application tries to compile the
shader and query the result before using it, it will always be at
least 4.
These shaders can quite easily end up with different values for the
declaration which makes it fail to link. This patch changes it so that
all of the shaders are generated with the maximum of the number of
texture attributes supplied by the primitive and the number of layers
in the pipeline. If this value changes then the shaders are
regenerated, including user shaders. That way all of the shaders will
always have the same value.
https://bugzilla.gnome.org/show_bug.cgi?id=662184
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Currently features are represented as bits in a 32bit mask so we
obviously can't have more than 32 features with that approach. The new
approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks
without a size limit and we change the public api to accept individual
feature enums instead of a mask. This way there is no limit on the
number of features we can add to Cogl.
Instead of using cogl_features_available() there is a new
cogl_has_feature() function and for checking multiple features there is
cogl_has_features() which takes a zero terminated vararg list of
features.
In addition to being able to check for individual features this also
adds a way to query all the features currently available via
cogl_foreach_feature() which will call a callback for each feature.
Since the new functions take an explicit context pointer there is also
no longer any ambiguity over when users can first start to query
features.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
It seems that cogl-context-private.h needs to be included before including
any of the pipeline-related stuff to avoid build errors on C89 compilers.
This is due to the recent cogl-pipeline decoupling, seems like.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This splits out the core CoglPipelineLayer support code from
cogl-pipeline.c into cogl-pipeline-layer.c; it splits out the debugging
code for dumping a pipeline to a .dot file into cogl-pipeline-debug.c
and it splits the CoglPipelineNode support which is shared between
CoglPipeline and CoglPipelineLayer into cogl-node.c.
Note: cogl-pipeline-layer.c only contains the layer code directly
relating to CoglPipelineLayer objects; it does not contain any
_cogl_pipeline API relating to how CoglPipeline tracks and manipulates
layers.
As part of the on going, incremental effort to purge the non type safe
CoglHandle type from the Cogl API this patch tackles most of the
CoglHandle uses relating to textures.
We'd postponed making this change for quite a while because we wanted to
have a clearer understanding of how we wanted to evolve the texture APIs
towards Cogl 2.0 before exposing type safety here which would be
difficult to change later since it would imply breaking APIs.
The basic idea that we are steering towards now is that CoglTexture
can be considered to be the most primitive interface we have for any
object representing a texture. The texture interface would provide
roughly these methods:
cogl_texture_get_width
cogl_texture_get_height
cogl_texture_can_repeat
cogl_texture_can_mipmap
cogl_texture_generate_mipmap;
cogl_texture_get_format
cogl_texture_set_region
cogl_texture_get_region
Besides the texture interface we will then start to expose types
corresponding to specific texture types: CoglTexture2D,
CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and
CoglTexturePixmapX11.
We will then also expose an interface for the high-level texture types
we have (such as CoglTexture2DSlice, CoglSubTexture and
CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an
additional interface that lets you iterate a virtual region of a meta
texture and get mappings of primitive textures to sub-regions of that
virtual region. Internally we already have this kind of abstraction for
dealing with sliced texture, sub-textures and atlas textures in a
consistent way, so this will just make that abstraction public. The aim
here is to clarify that there is a difference between primitive textures
(CoglTexture2D/3D) and some of the other high-level textures, and also
enable developers to implement primitives that can support meta textures
since they can only be used with the cogl_rectangle API currently.
The thing that's not so clean-cut with this are the texture constructors
we have currently; such as cogl_texture_new_from_file which no longer
make sense when CoglTexture is considered to be an interface. These
will basically just become convenient factory functions and it's just a
bit unusual that they are within the cogl_texture namespace. It's worth
noting here that all the texture type APIs will also have their own type
specific constructors so these functions will only be used for the
convenience of being able to create a texture without really wanting to
know the details of what type of texture you need. Longer term for 2.0
we may come up with replacement names for these factory functions or the
other thing we are considering is designing some asynchronous factory
functions instead since it's so often detrimental to application
performance to be blocked waiting for a texture to be uploaded to the
GPU.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Whenever a texture lookup is performed for a layer the result is now
stored in a variable and used repeatedly instead of generating the
code for the lookup every time it is accessed. This means for example
when using the INTERPOLATE function with a texture lookup for the
third parameter it will only generate one texture lookup instead of
two.
https://bugzilla.gnome.org/show_bug.cgi?id=656426
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This patch changes it so that code for each layer is generated on
demand instead of directly in the add_layer implementation. The
pipeline only explicitly generates code for the last layer. If this
layer references the result from any other layers, these will also be
recursively generated. This means that if a layer is using 'REPLACE'
then it won't redundantly generate the code for the previous
layers.
The result for each layer is generated into a variable called layer%i
where %i is the layer index (not the unit index). Therefore to get the
result from layer n we just have to refer to the varible layern.
https://bugzilla.gnome.org/show_bug.cgi?id=656426
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The CoglPipelineCache is now extended to store templates for state
affecting vertex shaders and combined programs. The GLSL fragend,
vertend and progend now uses this to get cached shaders and a program.
When a new pipeline is created it will now get hashed three times if
the GLSL backends are in use (once for the fragend, once for the
vertend and once for the progend). Ideally we should add some way for
the progend to check its cache before the fragends and vertends are
checked so that it can bypass them entirely if it can find a cached
combined program.
Previously the fragends had a separate private data pointer which was
used by the GLSL and ARBfp fragends to store a tiny struct containing
a single pointer to the ref-counted shader state. The space for the
private data pointer is reserved in all of the pipelines for all of
the potential backends. The vertends and progends however did this
differently by directly storing the pointer to the ref counted data
using cogl_object_set_user_data. This patch unifies the different
methods so that they all use cogl_object_set_user_data and the
fragends don't bother with the separate tiny allocation for the
private data. The private data pointer array has been removed from
CoglPipeline and the corresponding fragend virtual to free the private
data has also been removed because this can instead be done with the
destroy notify from the object user data.
The variable names used have been unified so that all of the vertends
and fragends name their data struct CoglPipelineShaderState and use a
variable called shader_state to refer to it. The progend uses
CoglPipelineProgramState and a variable called program_state.
This should also fix two potential bugs. the ARBfp fragend was
apprently leaking a reference to the private state when it creates the
private data because it was adding a reference before stroring the
pointer to the newly allocated data but the ref count is already set
to 1 on creation. The other potential bug is that the free function
for CoglPipeline was only calling the free_priv virtual for the
currently used fragend of the pipeline. The design of the fragends is
meant to allow a pipeline to have multiple fragend priv datas because
a child pipeline could be attaching its fragend data to the ancestor
and its allowed to pick a different fragend.
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
cogl-ext-functions.h now contains definitions for all of the core GL
and GLES functions that we would normally link to directly. All of the
code has changed to access them through the cogl context pointer. The
GE macro now takes an extra parameter to specify the context because
the macro itself needs to make GL calls but various points in the Cogl
source use different names for the context variable.
Instead of storing all of the feature function pointers in the driver
specific data of the CoglContext they are now all stored directly in
CoglContext. There is a single header containing the description of
the functions which gets included by cogl-context.h. There is a single
function in cogl-feature-private.c to check for all of these
functions.
The name of the function pointer variables have been changed from
ctx->drv.pf_glWhatever to just ctx->glWhatever.
The feature flags that get set when an extension is available are now
separated from the table of extensions. This is necessary because
different extensions can mean different things on GLES and GL. For
example, having access to glMapBuffer implies read and write support
on GL but only write support on GLES. The flags are instead set in the
driver specific init function by checking whether the function
pointers were successfully resolved.
_cogl_feature_check has been changed to assume the feature is
supported if any of the listed extensions are available instead of
requiring all of them. This makes it more convenient to specify
alternate names for the extension. Nothing else had previously listed
more than one name for an extension so this shouldn't cause any
problems.
The COGL_DEBUG=disable-texturing debug variable disables texturing in
the fixed function fragend by not bothering to enable the texture
targets. This wasn't working for the programmable fragends because the
texture targets don't need to be enabled to use them. This patch
modifies the two programmable backends to generate a constant value
for the texture lookups in the shader when the debug variable is
given.
There are several places where we need to compare the texture state of a
pipeline and sometimes we need to take into consideration if the
underlying texture has changed but other times we may only care to know
if the texture target has changed.
For example the fragends typically generate programs that they want to
share with all pipelines with equivalent fragment processing state, and
in this case when comparing pipelines we only care about the texture
targets since changes to the underlying texture won't affect the
programs generated.
Prior to this we had tried to handle this by passing around some special
flags to various functions that evaluate pipeline state to say when we
do/don't care about the texture data, but this wasn't working in all
cases and was more awkward to manage than the new approach.
Now we simply have two state bits:
COGL_PIPELINE_LAYER_STATE_TEXTURE_TARGET and
COGL_PIPELINE_LAYER_STATE_TEXTURE_DATA and CoglPipelineLayer has an
additional target member. Since all the appropriate code takes masks of
these state bits to determine what to evaluate we don't need any extra
magic flags.
The GLES2 wrapper is no longer needed because the shader generation is
done within the GLSL fragend and vertend and any functions that are
different for GLES2 are now guarded by #ifdefs.
Once the GLES2 wrapper is removed then we won't have the GLenums
needed for setting up the layer combine state. This adds Cogl enums
instead which have the same values as the corresponding GLenums. The
enums are:
CoglPipelineCombineFunc
CoglPipelineCombineSource
and
CoglPipelineCombineOp
The code to display the source when the show-source debug option is
given has been moved to _cogl_shader_set_source_with_boilerplate so
that it will show both user shaders and generated shaders. It also
shows the code with the full boilerplate. To make it the same for
ARBfp, cogl_shader_compile_real now also dumps user ARBfp shaders.
The GLSL vertend is mostly only useful for GLES2. The fixed function
vertend is kept at higher priority than the GLSL vertend so it is
unlikely to be used in any other circumstances.
'progend' is short for 'program backend'. The progend is intended to
operate on combined state from a fragment backend and a vertex
backend. The progend has an 'end' function which is run whenever the
pipeline is flushed and the two pipeline change notification
functions. All of the progends are run whenever the pipeline is
flushed instead of selecting a single one because it is possible that
multiple progends may be in use for example if the vertends and
fragends are different. The GLSL progend will take the shaders
generated by the fragend and vertend and link them into a single
program. The fragend code has been changed to only generate the shader
and not the program. The idea is that pipelines can share fragment
shader objects even if their vertex state is different. The authority
for the progend needs to be the combined authority on the vertend and
fragend state.
The pipeline function _cogl_pipeline_find_codegen_authority has been
renamed to _cogl_pipeline_find_equivalent_parent and it now takes a
set of flags for the pipeline and layer state that affects the
authority. This is needed so that we can reuse the same code in the
vertend and progends.
Previously enabling and disabling textures was done whatever the
backend in cogl-pipeline-opengl. However enabling and disabling
texture targets only has any meaning if no fragment shaders are being
used so this patch moves the code to cogl-pipeline-fragend-fixed.
The GLES2 wrapper has also been changed to ignore enabledness when
deciding whether to update texture coordinate attribute pointers.
The current Cogl pipeline backends are entirely concerned with the
fragment processing state. We also want to eventually have separate
backends to generate shaders for the vertex processing state so we
need to rename the fragment backends. 'Fragend' is a somewhat weird
name but we wanted to avoid ending up with illegible symbols like
CoglPipelineFragmentBackendGlslPrivate.
