[libcamera-devel] [PATCH v3 03/11] libcamera: fence: Introduce Fence
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Wed Dec 1 02:33:37 CET 2021
Hi Jacopo,
Thank you for the patch.
On Wed, Dec 01, 2021 at 12:36:26AM +0100, Jacopo Mondi wrote:
> Introduce a Fence class which models a synchronization primitive that
> allows to notify the availability of a resource.
>
> The Fence is modeled as a wrapper of a UniqueFD instance where
> read events are used to signal the Fence. The class can be later
> extended to support additional signalling mechanisms.
>
> Signed-off-by: Jacopo Mondi <jacopo at jmondi.org>
> ---
> include/libcamera/fence.h | 31 ++++++++++
> include/libcamera/meson.build | 1 +
> src/libcamera/fence.cpp | 108 ++++++++++++++++++++++++++++++++++
> src/libcamera/meson.build | 1 +
> 4 files changed, 141 insertions(+)
> create mode 100644 include/libcamera/fence.h
> create mode 100644 src/libcamera/fence.cpp
>
> diff --git a/include/libcamera/fence.h b/include/libcamera/fence.h
> new file mode 100644
> index 000000000000..95f2dd07f10b
> --- /dev/null
> +++ b/include/libcamera/fence.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: LGPL-2.1-or-later */
> +/*
> + * Copyright (C) 2021, Google Inc.
> + *
> + * internal/fence.h - Synchronization fence
> + */
> +
> +#pragma once
> +
> +#include <libcamera/base/class.h>
> +#include <libcamera/base/unique_fd.h>
> +
> +namespace libcamera {
> +
> +class Fence
> +{
> +public:
> + Fence(UniqueFD fd);
> +
> + bool isValid() const { return fd_.isValid(); }
> + const UniqueFD *fd() const { return &fd_; }
> +
> + UniqueFD reset() { return std::move(fd_); }
This should be called release(), and should return fd_.release().
> +
> +private:
> + LIBCAMERA_DISABLE_COPY_AND_MOVE(Fence)
> +
> + UniqueFD fd_;
> +};
> +
> +} /* namespace libcamera */
> diff --git a/include/libcamera/meson.build b/include/libcamera/meson.build
> index 5f42977c034b..8c2cae00d877 100644
> --- a/include/libcamera/meson.build
> +++ b/include/libcamera/meson.build
> @@ -6,6 +6,7 @@ libcamera_public_headers = files([
> 'camera.h',
> 'camera_manager.h',
> 'controls.h',
> + 'fence.h',
> 'framebuffer.h',
> 'framebuffer_allocator.h',
> 'geometry.h',
> diff --git a/src/libcamera/fence.cpp b/src/libcamera/fence.cpp
> new file mode 100644
> index 000000000000..2bab8d7de76a
> --- /dev/null
> +++ b/src/libcamera/fence.cpp
> @@ -0,0 +1,108 @@
> +/* SPDX-License-Identifier: LGPL-2.1-or-later */
> +/*
> + * Copyright (C) 2021, Google Inc.
> + *
> + * fence.cpp - Synchronization fence
> + */
> +
> +#include "libcamera/fence.h"
> +
> +namespace libcamera {
> +
> +/**
> + *
> + * \file libcamera/fence.h
> + * \brief Synchronization fence
> + */
> +
> +/**
> + * \class Fence
> + * \brief Synchronization fence class
Sweet, documentation :-)
I'm not sure I like the name "synchronization fence". The "fence" is a
synchronization primitive, so "synchronization fence" sounds a bit
redundant. Maybe
* \brief Synchronization primitive to manage resources
or something similar ? Same through the file.
> + *
> + * The Fence class is a thin abstraction around a UniqueFD which simply allows
> + * to access it as a const pointer or to move its ownership to the caller.
I've noticed many times a tendency (not just from you, it's general) to
focus on how a class or function is implemented, instead of what it
represents, what it does, and how it should be used. Here, I would start
with
* The Fence class models a synchronization primitive that can be used by
* applications to explicitly synchronize resource usage, and can be shared by
* multiple processes.
> + *
> + * Synchronization fences are most commonly used in association with frame
> + * buffers. A FrameBuffer can be associated with a Fence (\sa
> + * Request::addBuffer()) so that the library can wait for the Fence to be
> + * signalled before allowing the camera device to actually access the memory
> + * area described by the FrameBuffer.
> + *
> + * By using synchronization fences, application can then synchronize between
> + * frame buffer consumers and produces, as in example a video output device and
s/produces/producers/
s/in example/for example/
s/video output device/display device/
> + * camera, to gurantee that new data transfers only happen once the existing
s/camera/a camera/
s/gurantee/guarantee/
> + * frames have been displayed.
> + *
As the next paragraph is about internal usage of the Fence class, and
not about the application-facing API, I would move it to an \internal
block at the end. The rest of the documentation should be refactored a
bit to separate public and internal documentation.
> + * The Fence class only abstracts the underlying mechanism used by libcamera to
> + * implement synchronization primitives and allow to wait until an event is
s/allow/allows/
> + * signalled, but does not implement event notification itself which is instead
> + * implemented by the core library.
> + *
> + * \sa Request::prepare()
> + *
> + * A Fence can be realized by different event notification primitives, the most
> + * common of which is represented by waiting for read events to happen on a
> + * file descriptor. This is currently the only mechanism supported by libcamera,
> + * but others can be implemented by extending or subclassing this class and
> + * implementing opportune handling in the core library.
I think we should be a bit more precise here. It's not any file
descriptor, it's a handle to a kernel sync file (see sync_file.rst and
dma-buf.rst in Documentation/driver-api/).
> + *
> + * The usage of the Fence class allows to abstract the underlying
> + * synchronization mechanism in use and implement an interface towards other
> + * library components that will not change when new synchronization primitives
> + * will be added as fences.
> + *
> + * A Fence is contructed with a UniqueFD whose ownship is moved in the Fence. A
> + * FrameBuffer can be associated with a Fence by passing it to the
> + * Request::addBuffer() function, which will move the Fence into the FrameBuffer
> + * itself. Once a Request is queued to the Camera, a preparation phase gurantees
> + * that before actually applying the Request to the hardware, all the valid
> + * fences of the frame buffers in a Request are correctly signalled. Once a
> + * Fence has completed, the library will reset the FrameBuffer fence so that
> + * application won't be allowed to access it.
> + *
> + * An optional timeout can be started while waiting for a fence to complete. If
> + * waiting on a Fence fails for whatever reason, the FrameBuffer's fence is not
> + * reset and is made available to application for them to handle it, by
> + * resetting the Fence to correctly close the underlying UniqueFD.
> + *
> + * A failure in waiting for a Fence to complete will result in the Request to
> + * complete in failed state.
> + */
> +
> +/**
> + * \brief Create a synchronization fence
> + * \param[in] fd The synchronization fence unique file descriptor
s/unique //
The fact that we manage the fd through a UniqueFD is more of an
implementation detail, I would just write "file descriptor" through the
documentation here and below.
> + *
> + * The unique file descriptor ownership is moved to the Fence.
> + */
> +Fence::Fence(UniqueFD fd)
> + : fd_(std::move(fd))
> +{
> +}
> +
> +/**
> + * \fn Fence::isValid()
> + * \brief Retrieve if a Fence is valid
"Check if a Fence is valid" maybe ?
> + *
> + * A Fence is valid if the UniqueFD it wraps is valid
s/$/./
> + *
> + * \return True if the Fence is valid, false otherwise
> + */
> +
> +/**
> + * \fn Fence::fd()
> + * \brief Retrieve a constant pointer to the UniqueFD
> + * \return A const pointer to the UniqueFD
Could this be a reference instead of a pointer ? Looking at the
implementation, it can never be null.
> + */
> +
> +/**
> + * \fn Fence::reset()
> + * \brief Reset the Fence by moving the UniqueFD ownership to the caller
> + *
> + * Reset the Fence by releasing the wrapped UniqueFD. Ownership of the UniqueFD
> + * is moved to the caller.
Calling this release(), it should read
* \brief Release the ownership of the file descriptor
*
* Release the ownership of the wrapped UniqueFD and return it to the caller.
> + *
> + * \return The UniqueFD
> + */
> +
> +} /* namespace libcamera */
> diff --git a/src/libcamera/meson.build b/src/libcamera/meson.build
> index b763110e74a6..b4882a2577f5 100644
> --- a/src/libcamera/meson.build
> +++ b/src/libcamera/meson.build
> @@ -14,6 +14,7 @@ libcamera_sources = files([
> 'delayed_controls.cpp',
> 'device_enumerator.cpp',
> 'device_enumerator_sysfs.cpp',
> + 'fence.cpp',
> 'formats.cpp',
> 'framebuffer.cpp',
> 'framebuffer_allocator.cpp',
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list