When we use perfetto, we'll want to enable the renderer timepoints, which
are currently gated behind weston_log_scope_is_enabled(). So let's make a
function that checks if either the timeline scope or perfetto is enabled.
We do not yet process these timepoints, that comes in a future commit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Just pepper some perfetto tracing about.
These functions are picked mostly to provide some visibility into repaint,
but in the future we might want to add more sites, such as input
processing.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This borrows heavily from the Mesa project's perfetto instrumentation, and
for now just adds perfetto to the build and a collection of useful macros
for adding trace points.
The atomics have been cargo culted in - Weston currently has no need of
such things, but I guess they're harmless for now and could be useful if
we consider threads in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
I'll be adding perfetto instrumentation, which will want to know the
timepoint name without having to parse it.
For now, just pass an enum and add a helper function to convert to strings.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Weston seems quite ready for that so let us do it!
This makes the winpr3 Static assert warning message go away, allowing us
to perform a build (as we fail with any type of warnings).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Add asserts ensuring that outputs aren't created or destroyed twice
and that a valid pair of output/renderbuffer is passed to
repaint_output().
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Accumulate renderbuffer damages and select a GL renderbuffer for
repaint in a dedicated function.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Coalesce gl_renderer_create_renderbuffer_window() and
output_get_window_renderbuffer() into a single
gl_renderer_get_renderbuffer_window() function.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Use the term window instead of dummy to make it clear we're dealing
with buffers allocated by the window-system.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
renderbuffer_get_image() is only used by the X11 backend to retrieve
the size of the renderbuffer. The previous commit assumes that
renderbuffers are created at the size of the associated output so the
renderbuffer size can now be retrieved from the output.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Although backends can create renderbuffers of any size, they always
request the output's current mode size (including decorations).
Letting backends ask for a different size than the output has a few
read-back related design issues like for instance weston_renderer's
read_pixels() API users, currently assuming the output size and
without knowledge of renderbuffers, can retrieve cropped images if a
backend asks for a smaller size. Same issue for the output capture
subsystem.
This commit proposes to fix these issues by simply, albeit perhaps
radically, removing the width and height parameters from
create_renderbuffer(), enforcing the current mode's size of the
associated output.
The VNC and PipeWire backends now also access the output size via the
current mode, not through the width and height variables. This has the
benefit of unifying the backends, as well as the renderers, in their
use of output sizes.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
The Pixman renderer creates renderbuffers with the create_image() and
create_image_from_ptr() functions. The recent addition of the GL
renderer's create_fbo() function, which is pretty similar to the
Pixman ones, brings the opportunity to unify Pixman and GL renderers.
This commit proposes a common renderer function create_renderbuffer()
to create a renderbuffer of the specified format with an optional user
provided destination buffer.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This avoids having to re-bind them in functions that reuse them
immediately afterwards and does not affect any other parts of code.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This commit makes gl_fbo_texture_init() and gl_fbo_texture_fini()
consistent with the new FBO handling utilities by using the same
conventions: output parameters, variable names, descriptions.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Remove the glGetError() check from gl_fbo_image_init() after the call
to glEGLImageTargetRenderbufferStorageOES(). It would probably just
return a previous error queued by an unrelated GL call because the
error flags aren't cleared. So instead of obfuscating the code, this
commit removes that check and relies instead on the framebuffer
completeness check which will better report issues.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Add generic gl_fbo_init(), gl_fbo_image_init() and gl_fbo_fini()
utilities to the GL renderer and make use of these in the renderbuffer
creation functions.
This also fixes a framebuffer object leak on dma-buf renderbuffer
creation when the EGLImageTargetRenderbufferStorageOES() call fails.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
There's no need to render the surface content to a GL texture so make
it render to a GL renderbuffer instead.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Move gl_renderer_create_renderuffer_dmabuf() along with the other
renderbuffer creation functions, using a common naming pattern.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This makes type specific accesses more explicit and less verbose than
the container_of/base alternative which was needed when the base
renderbuffer type was exposed in libweston-internal.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
No backends currently create FBO or dma-buf renderbuffers on outputs
associated to a window. This is theoretically possible though and
should be allowed by the GL renderer. This commit prevents
output_get_dummy_renderbuffer() from mixing up renderbuffer types.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Stale renderbuffers are kept in the renderbuffer list until they're
destroyed by the backend. In the meantime, they shouldn't accumulate
damages since they won't be used anymore.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
The output doesn't get finalised and initialised again on resizes
anymore with the Pixman renderer. Only the current dumb and render
buffers get reallocated.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
It's currently assumed by backends that renderers discard
renderbuffers on resize. This commit introduces a new
weston_renderbuffer_discarded_func callback that must be passed at
renderbuffer creation in order to be notified of discarded events from
the renderer. This discarded event could potentially be reused later
by renderers on other occasions without having to change backends once
they get proper support for that.
On output resize, once a discarded event handler fails (returns false)
on a renderbuffer, all the remaining renderbuffers in the output list
go stale and weston_renderer_resize_output() ultimately returns false
for backends to be notified of the failure.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Renderbuffers currently have a libweston-internal base data structure
with a ref-counting system to handle their lifetime. The problem is
that renderers keep a ref to all renderbuffers in a list per output
(to deal with damages) and that it prevents backends from releasing
renderbuffer resources when not needed anymore. Renderbuffers are then
only released (last ref removed) when the output is destroyed or
resized. dma-buf renderbuffers even expose a dedicated function
remove_renderbuffer_dmabuf() to explictly request the release of their
resources.
This commit proposes to get rid of the ref-counting system by exposing
a single entry point to explicitly destroy all types of renderbuffers
from the renderer.
Instead of removing a renderbuffer from its output list and dropping
its ref when the output is resized, this commit also introduces the
concept of stale renderbuffers which consists in releasing the
resources of a renderbuffer when it's discarded by the renderer while
keeping it in the output list, with a stale state, until it's
explicitly destroyed.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Move the responsibility for damaging the entire area of new
renderbuffers from backends to renderers.
There's one little drawback: VNC damage logging can't log the
accumulated renderbuffer damage anymore, but I guess this should
somehow be done as an option in the renderers.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This adds tests to create image descriptions through color parameters
using the CM&HDR protocol extension.
The code for that was added in commit "color: allow clients to create
image description from parameters".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Start to print the parameters from struct cmlcms_color_profile::params
in cmlcms_color_profile_print(). This will be useful for the next
commit, in which we add tests that craft parametric color profiles.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
A counter instead of a boolean should be useful when we add code
printing the parameters. This should help us to avoid printing unused
parameters.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Commit "color: add support to the color-management protocol" added
support for the majority of the interfaces from the color-management
protocol.
The missing part was the interface that allows clients to create image
descriptions from parameters. In this patch we do that.
For now this just exercises the mechanical aspects of the protocol, we
still need to write the code to create proper color profiles from that
and make use of them in our codebase.
In the next commits we add a new test file with lots of tests exercising
the creation of image descriptions through parameters.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If a certain feature is unsupported, return UNSUPPORTED instead of
BAD_TF, BAD_PRIMARIES, etc.
Also, up to now cm->get_color_profile_from_params() would return
UNSUPPORTED. But this is different from the other UNSUPPORTED usages, so
return a new error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the parametric builder API, which is used by our color management
protocol implementation, we have errors that may be translated to
protocol errors or graceful failures. As we return a single err code
to the protocol implementation, let's prioritize the protocol error.
We do that by inverting the order of checks, as the first error code
caught is the one prioritized.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This follows a recent change in the CM&HDR protocol (more specifically,
v4 of the experimental version). Now users of the API can set luminance
parameters for the primary color volume.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This follows a recent change in the CM&HDR protocol (more specifically,
v4 of the experimental version). Now clients can use the protocol to set
luminance parameters for the primary color volume.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The CM&HDR protocol extension spec relaxed the requirements for the
max_fall and max_cll setters. Now we accept such values even when the
transfer function is not PQ.
This also fixes an issue in which we'd not accept target_luminance
for transfer function different from PQ, which was not on the spec.
INCONSISTENT_SET is not being used in any other errors, so remove that
from enum weston_color_profile_param_builder_error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the experimental color-management protocol v3
(xx-color-management-v3), we had only the luminance parameters that were
defining the luminance range targeted by the image description. But in
v4 a way to specify luminance parameters for the primary color volume
has been added.
In order to avoid confusion, rename existent luminance variables to
target luminance.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
While choosing a name for file color-properties.h, I've had originally
opted for color-characteristics.h. But we already have some other stuff
named color characteristics in the code, so I've changed that to
color-properties.h.
This fixes a leftover from that. Rename WESTON_COLOR_CHARACTERISTICS_H
to WESTON_COLOR_PROPERTIES_H.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We need this common helper as we don't have access to shared helper, so
just define one in-situ.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This is problematic as we don't have namespacing for these and some of
the macros can interfere with other defines.
This reverts commit 8634c7e349.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
