Since the Cogl 1.18 branch is actively maintained in parallel with the
master branch; this is a counter part to commit 1b83ef938fc16b which
re-licensed the master branch to use the MIT license.
This re-licensing is a follow up to the proposal that was sent to the
Cogl mailing list:
http://lists.freedesktop.org/archives/cogl/2013-December/001465.html
Note: there was a copyright assignment policy in place for Clutter (and
therefore Cogl which was part of Clutter at the time) until the 11th of
June 2010 and so we only checked the details after that point (commit
0bbf50f905)
For each file, authors were identified via this Git command:
$ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD
We received blanket approvals for re-licensing all Red Hat and Collabora
contributions which reduced how many people needed to be contacted
individually:
- http://lists.freedesktop.org/archives/cogl/2013-December/001470.html
- http://lists.freedesktop.org/archives/cogl/2014-January/001536.html
Individual approval requests were sent to all the other identified authors
who all confirmed the re-license on the Cogl mailinglist:
http://lists.freedesktop.org/archives/cogl/2014-January
As well as updating the copyright header in all sources files, the
COPYING file has been updated to reflect the license change and also
document the other licenses used in Cogl such as the SGI Free Software
License B, version 2.0 and the 3-clause BSD license.
This patch was not simply cherry-picked from master; but the same
methodology was used to check the source files.
Previously the private feature flags were stored in an enum and we
already had 31 flags. Adding the 32nd flag would presumably make it
add -2³¹ as one of the values which might cause problems. To avoid
this we'll just use an fixed-size array of longs and use indices for
the enum values like we do for the public features.
A slight complication with this is in the CoglDriverDescription where
we were previously using a static intialised value to describe the set
of features that the driver supports. We can't easily do this with the
flags array so instead the features are stored in a fixed-size array
of indices.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3)
Conflicts:
cogl/cogl-context-private.h
cogl/cogl-context.c
cogl/cogl-private.h
cogl/cogl-renderer.c
cogl/driver/gl/cogl-pipeline-opengl.c
cogl/driver/gl/gl/cogl-driver-gl.c
cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c
cogl/driver/gl/gles/cogl-driver-gles.c
cogl/driver/nop/cogl-driver-nop.c
This adds a table of driver descriptions to cogl-renderer.c in order of
preference and when choosing what driver to use we now iterate the table
instead of repeating boilerplate checks. For handling the "default driver"
that can be specified when building cogl and handling driver overrides
there is a foreach_driver_description() that will make sure to iterate
the default driver first or if an override has been set then nothing but
the override will be considered.
This patch introduces some driver flags that let us broadly categorize
what kind of GL driver we are currently running on. Since there are
numerous OpenGL apis with different broad feature sets and new apis
may be introduced in the future by Khronos then we should tend to
avoid using the driver id to do runtime feature checking. These flags
provide a more stable quantity for broad feature checks.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
This adds a new function to enable per-vertex point size on a
pipeline. This can be set with
cogl_pipeline_set_per_vertex_point_size(). Once enabled the point size
can be set either by drawing with an attribute named
'cogl_point_size_in' or by writing to the 'cogl_point_size_out'
builtin from a snippet.
There is a feature flag which must be checked for before using
per-vertex point sizes. This will only be set on GL >= 2.0 or on GLES
2.0. GL will only let you set a per-vertex point size from GLSL by
writing to gl_PointSize. This is only available in GL2 and not in the
older GLSL extensions.
The per-vertex point size has its own pipeline state flag so that it
can be part of the state that affects vertex shader generation.
Having to enable the per vertex point size with a separate function is
a bit awkward. Ideally it would work like the color attribute where
you can just set it for every vertex in your primitive with
cogl_pipeline_set_color or set it per-vertex by just using the
attribute. This is harder to get working with the point size because
we need to generate a different vertex shader depending on what
attributes are bound. I think if we wanted to make this work
transparently we would still want to internally have a pipeline
property describing whether the shader was generated with per-vertex
support so that it would work with the shader cache correctly.
Potentially we could make the per-vertex property internal and
automatically make a weak pipeline whenever the attribute is bound.
However we would then also need to automatically detect when an
application is writing to cogl_point_size_out from a snippet.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 8495d9c1c15ce389885a9356d965eabd97758115)
Conflicts:
cogl/cogl-context.c
cogl/cogl-pipeline-private.h
cogl/cogl-pipeline.c
cogl/cogl-private.h
cogl/driver/gl/cogl-pipeline-progend-fixed.c
cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c
This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When
requested, the GLX, EGL and SDL2 winsyss will set the necessary
attributes to request a forward-compatible core profile 3.1 context.
That means it will have no deprecated features.
To simplify the explosion of checks for specific combinations of
context->driver, many of these conditionals have now been replaced
with private feature flags that are checked instead. The GL and GLES
drivers now initialise these private feature flags depending on which
driver is used.
The fixed function backends now explicitly check whether the fixed
function private feature is available which means the GL3 driver will
fall back to always using the GLSL progend. Since Rob's latest patches
the GLSL progend no longer uses any fixed function API anyway so it
should just work.
The driver is currently lower priority than COGL_DRIVER_GL so it will
not be used unless it is specificly requested. We may want to change
this priority at some point because apparently Mesa can make some
memory savings if a core profile context is used.
In GL 3, getting the combined extensions string with glGetString is
deprecated so this patch changes it to use glGetStringi to build up an
array of extensions instead. _cogl_context_get_gl_extensions now
returns this array instead of trying to return a const string. The
caller is expected to free the array.
Some issues with this patch:
• GL 3 does not support GL_ALPHA format textures. We should probably
make this a feature flag or something. Cogl uses this to render text
which currently just throws a GL error and breaks so it's pretty
important to do something about this before considering the GL3
driver to be stable.
• GL 3 doesn't support client side vertex buffers. This probably
doesn't matter because CoglBuffer won't normally use malloc'd
buffers if VBOs are available, but it might but worth making
malloc'd buffers a private feature and forcing it not to use them.
• GL 3 doesn't support the default vertex array object. This patch
just makes it create and bind a single non-default vertex array
object which gets used just like the normal default object. Ideally
it would be good to use vertex array objects properly and attach
them to a CoglPrimitive to cache the state.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
This adds a new "fixed-arbfp" progend so we now have 3 distinct ways of
setting up the state of a pipeline:
» fixed; where the vertex and fragment processing are implemented
using fixed function opengl apis.
» fixed-arbfp; where vertex processing is implemented using fixed
function opengl apis but fragment processing is implemented
using the ARB Fragment Processing language.
» glsl; there vertex and fragment processing are both implemented
using glsl.
This means we avoid unusual, combinations such as glsl for vertex
processing and arbfp for fragment processing, and also avoid pairing
fixed-function vertex processing with glsl fragment processing which we
happen to know hits some awkward code paths in Mesa that lead to poor
performance.
As part of this change, the progend now implies specific vertend and
fragend choices so instead of associating a vertend and fragend with a
pipeline we now just associate a progend choice.
When flushing a pipeline and choosing what progend to use, we now call a
progend->start() method that is able to determine if the vertend and
fragend together will be able to handle the given pipeline so the
vertend and fragend ->start() methods no longer need to return a boolean
status.
Since we now don't need to support glsl used in conjunction with fixed
function this will allow us to avoid ever using OpenGL builtin attribute
names, though this patch doesn't change that yet.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit cec381f50c7a2f2186bd4a8c5f38fecd5f099075)
As part of an effort towards being able to write non-opengl based
backends for Cogl this moves most of the opengl specific code under
drivers/gl. drivers/gl and drivers/gles have been moved to
drivers/gl/gl and drivers/gl/es respectively.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 7dc482facb0a265c7f48660079e7e12dd7a2813e)
