The commit also moves certain functions from the private header
as they are not used anywhere else and removes COGL_EXPORT
when the function is supposed to be private and is not used outside of
cogl
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3437>
We will also require GL_OES_texture_half_float and GLES 3.0 to enable
COGL_FEATURE_ID_TEXTURE_HALF_FLOAT. This gives us float types and makes
it possible to read pixels from framebuffers with internal floating
point formats (into float, half is never supported).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
This implementation is copied from mesa.
It uses x86_64 assembler on CPUs where it's supported, otherwise falls
back on a software implementation (cogl-soft-float.c). It's intended to
be used for packing and unpacking f16 format bitmaps.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
The implementation comes from mesa, which came from Berkeley SoftFloat
3e Library.
The software float implementation will be used to convert from and to
half floating point pixel format bitmaps, when no the CPU isn't capable
of the conversion.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
The type of the intermediate medium for storing pixel channels is
changed from "is 8 or 16 bit" to an enum, and switch cases. This doesn't
add support for anything, but will make adding a "float" medium type
less intrusive.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
There is no internal fp16 format which has no alpha which means we would
get garbage alpha when reading the framebuffer directly. We have to use
the packing/unpacking to always get the alpha of 1.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
Which gltype and glformat are allowed for a given gl framebuffer depends
on the internal gl framebuffer format. Either the format we want to read
into matches the gltype, glformat and doesn't need CPU packing from
another format or we have to use a tmp buffer with a format that matches
the GL requirements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
Sometimes it's useful to combine the description from multiple places.
For example, a subsequent commit will add the output name as the first
thing to the frame clock span descriptions, leaving the rest of the
description with complex checks unchanged.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3417>
Using sized internal formats is required to make sure we actually get
the precision that we want.
The formats should also be renderable, otherwise they can not be used as
a framebuffer attachment. For GLES we have to check for a bunch of
extensions and fall back to internal formats with more bits when they
are not available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
In GLES 2.0 the required color-renderable formats to support to not
include 8bpc RGB/RGBA formats. The extension adds this requirement and
makes GLES 2.0 actually useable. Not specifying a gl internal format in
Cogl so far has hidden the problem and let the implementation fall back
to RGB585 for example.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
Also be more strict about what we consider RGBA1010102 support. Before
GLES 3.0, using ReadPixels on a framebuffers with format RGB10_A2 was
not possible with type GL_UNSIGNED_INT_2_10_10_10_REV_EXT and thus our
code to read back pixels could fail.
Users of cogl should check those feature flags before using FP16 and
RGBA1010102 pixel formats via CoglFeatureIDs:
* COGL_FEATURE_ID_TEXTURE_RGBA1010102
* COGL_FEATURE_ID_TEXTURE_HALF_FLOAT
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
If the EGL_KHR_no_config_context extension is supported, use it to
choose a format per onscreen which is compatible with the scanout CRTC
and the GL rendering API used.
Suggested by Jonas Ådahl.
v2:
* Drop code which checked for GLES3 renderability. Makes no sense for
various reasons, in particular that EGLconfigs are about EGLSurfaces,
whereas secondary GPU contexts use an FBO for blitting.
* Use error parameter directly for meta_renderer_native_choose_gbm_format
call (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
If the EGL_KHR_no_config_context extension is supported, pass
EGL_NO_CONFIG_KHR to eglCreateContext. This will allow binding the
context to surfaces created with different configs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
Scoped traces are less error prone, and they can still be ended
prematurely if needed (this commit makes that work). The only case this
doesn't support is starting a trace inside a scope but ending outside,
but this is pretty unusual, plus we have anchored traces for a limited
variation of that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3396>
