Some tests sadly behaves differently depending on the driver in use.
While this shouldn't happen we can't block on these driver issues, so
add a test utils private function to get the driver information so that
we can adapt test behavior depending on this.
This will allow to disable / enable tests at runtime instead of failing
in all the implementations, which is still better for catching
regressions in the parts we may be ignoring otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3793>
Don't expose its headers, remove all getters, and move the rest to
cogl-output-private.h. Next commits will clean it up even more, but
for now, just make it private.
This will help next commits remove CoglOutput.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3792>
We were leaking one instance because _cogl_winsys_egl_context_created()
could be potentially be called twice (via cogl_display_setup() one as
part of cogl_renderer_check_onscreen_template() and the other when
called from clutter_backend_do_real_create_context()), and so we'd ended
up overwriting the reference we had.
However, we really didn't use it anywhere and once used to call the
relevant functions it's just useless.
So let's just keep it as local variable
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
Move the code out of cogl_onscreen_egl_swap_buffers_with_damage, and
call the new function from callers of the former.
v2:
* Use early return if the cogl context doesn't support timestamp
queries. (Sebastian Wick)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3689>
This keeps an internal sync_fd for the latest work submitted to
the GPU. This can then be fetched with cogl_context_get_latest_sync_fd
for use. This is intended for use with linux-drm-syncobj-v1
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300>
`eglGetProcAddress()` used to not work for core API in EGL versions
below 1.5. The workaround in place in turn can fail - notably for setups
with a local Mesa build in /usr/local.
EGL 1.5 is almost 10 years old and similar workarounds don't seem to be
in place for toolkits we rely on, notably GTK4. Thus remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
Since commit e30eb78891 `ClutterFrameClock` assumes that a valid CPU time
implies timestamp query support, which is also checked in
`cogl_onscreen_egl_swap_buffers_with_damage()`.
Unconditionally setting the CPU time on direct scanout meant that the
compositing path would be stuck on the last (direct scanout optimized)
result on GL implementations without timestamp query support since.
be0aa2976e (clutter/frame-clock: Avoid rapidly toggling dynamic max render time)
Fix that by explicitly marking the gpu rendering duration as valid when
querying the GPU timestamps is supported and check for it ClutterFrameClock.
Fixes: 56580ea7c9 ("backends/native: Assume zero rendering time for direct scanout buffers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
Upstream the annotations used in Gala, make more Cogl methods available since
things got moved to a GObject base and thus works natively with the introspection.
Add all the public API to the introspection.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3619>
Do not include it at header side as it is not part of the installed headers.
Only keep it in cogl-gl-headers.h as it is a private header.
Add it to all the source files that depend on it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3593>
meta_render_device_gbm_allocate_dma_buf() function is updated to take a
list of modifiers. If no modifiers are specified, the modifier is
selected by the allocator, and implicit modifiers are used to import the
created DMA-BUF.
Co-authored-by: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3537>
We need an object to hold additional scanout related information, such
as scaling and positioning data. Turn CoglScanout into such an object,
moving the interface into CoglScanoutBuffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
I haven't seen this cause a problem but it looks like the worst case is
that it would have put the wrong refresh rate value in CoglFrameInfo
for multi-monitor systems of differing frequencies. But even that seems
unlikely given `_cogl_xlib_renderer_output_for_rectangle` chooses the
output with the greatest overlap of the partially-correct rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3569>
COGL_DEBUG_ENABLED is a macro to check if a debug flag is set.
COGL_ENABLE_DEBUG is set by the build system if it's a debug build. The
check `#ifdef COGL_DEBUG_ENABLED` always evaluates to true. Use the
appropriate macro to guard some debugging code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3446>
The slightly different styles in the different build files make it
harder to reason about or share c_args.
This notably ensures we never set any extra c_args for plain builds and
fixes the cc.get_supported_arguments() check in Cogl, Clutter and Mtk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3333>
Simply reinterpreting the bytes differently is a strict-aliasing
violation if the type of the object isn't char or the target type of the
reinterpretation. None of that is the case here, so we have to resort to
a memcpy.
Fixes: 60c082caa ("cogl/bitmap-conversion: Support packing fp16 formats")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3499>
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>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
