All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maíra Canal" <mcanal@igalia.com>
To: Louis Chauvet <louis.chauvet@bootlin.com>,
	Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>,
	Melissa Wen <melissa.srw@gmail.com>,
	Haneen Mohammed <hamohammed.sa@gmail.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>,
	arthurgrillo@riseup.net, Jonathan Corbet <corbet@lwn.net>,
	pekka.paalanen@haloniitty.fi
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	jeremie.dautheribes@bootlin.com, miquel.raynal@bootlin.com,
	thomas.petazzoni@bootlin.com, seanpaul@google.com,
	marcheu@google.com, nicolejadeyee@google.com
Subject: Re: [PATCH v5 03/16] drm/vkms: write/update the documentation for pixel conversion and pixel write functions
Date: Mon, 25 Mar 2024 10:32:31 -0300	[thread overview]
Message-ID: <cae591ee-cd61-421c-b3b4-810790836f1b@igalia.com> (raw)
In-Reply-To: <20240313-yuv-v5-3-e610cbd03f52@bootlin.com>

On 3/13/24 14:44, Louis Chauvet wrote:
> Add some documentation on pixel conversion functions.
> Update of outdated comments for pixel_write functions.
> 
> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> ---
>   drivers/gpu/drm/vkms/vkms_composer.c |  7 ++++
>   drivers/gpu/drm/vkms/vkms_drv.h      | 13 ++++++++
>   drivers/gpu/drm/vkms/vkms_formats.c  | 62 ++++++++++++++++++++++++++++++------
>   3 files changed, 73 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c
> index c6d9b4a65809..da0651a94c9b 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -189,6 +189,13 @@ static void blend(struct vkms_writeback_job *wb,
>   
>   	size_t crtc_y_limit = crtc_state->base.crtc->mode.vdisplay;
>   
> +	/*
> +	 * The planes are composed line-by-line to avoid heavy memory usage. It is a necessary
> +	 * complexity to avoid poor blending performance.
> +	 *
> +	 * The function vkms_compose_row is used to read a line, pixel-by-pixel, into the staging
> +	 * buffer.
> +	 */
>   	for (size_t y = 0; y < crtc_y_limit; y++) {
>   		fill_background(&background_color, output_buffer);
>   
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index b4b357447292..18086423a3a7 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -25,6 +25,17 @@
>   
>   #define VKMS_LUT_SIZE 256
>   
> +/**
> + * struct vkms_frame_info - structure to store the state of a frame
> + *
> + * @fb: backing drm framebuffer
> + * @src: source rectangle of this frame in the source framebuffer
> + * @dst: destination rectangle in the crtc buffer
> + * @map: see drm_shadow_plane_state@data
> + * @rotation: rotation applied to the source.
> + *
> + * @src and @dst should have the same size modulo the rotation.
> + */
>   struct vkms_frame_info {
>   	struct drm_framebuffer *fb;
>   	struct drm_rect src, dst;
> @@ -52,6 +63,8 @@ struct vkms_writeback_job {
>    * vkms_plane_state - Driver specific plane state

It should be "* struct vkms_plane_state - Driver specific plane state".

>    * @base: base plane state
>    * @frame_info: data required for composing computation
> + * @pixel_read: function to read a pixel in this plane. The creator of a vkms_plane_state must
> + * ensure that this pointer is valid
>    */
>   struct vkms_plane_state {
>   	struct drm_shadow_plane_state base;
> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c
> index 172830a3936a..6e3dc8682ff9 100644
> --- a/drivers/gpu/drm/vkms/vkms_formats.c
> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> @@ -9,6 +9,18 @@
>   
>   #include "vkms_formats.h"
>   
> +/**
> + * pixel_offset() - Get the offset of the pixel at coordinates x/y in the first plane
> + *
> + * @frame_info: Buffer metadata
> + * @x: The x coordinate of the wanted pixel in the buffer
> + * @y: The y coordinate of the wanted pixel in the buffer
> + *
> + * The caller must ensure that the framebuffer associated with this request uses a pixel format
> + * where block_h == block_w == 1.
> + * If this requirement is not fulfilled, the resulting offset can point to an other pixel or
> + * outside of the buffer.
> + */
>   static size_t pixel_offset(const struct vkms_frame_info *frame_info, int x, int y)
>   {
>   	struct drm_framebuffer *fb = frame_info->fb;
> @@ -17,18 +29,22 @@ static size_t pixel_offset(const struct vkms_frame_info *frame_info, int x, int
>   			      + (x * fb->format->cpp[0]);
>   }
>   
> -/*
> - * packed_pixels_addr - Get the pointer to pixel of a given pair of coordinates
> +/**
> + * packed_pixels_addr() - Get the pointer to the block containing the pixel at the given
> + * coordinates
>    *
>    * @frame_info: Buffer metadata
> - * @x: The x(width) coordinate of the 2D buffer
> - * @y: The y(Heigth) coordinate of the 2D buffer
> + * @x: The x(width) coordinate inside the plane
> + * @y: The y(height) coordinate inside the plane

I would add a space after x and y.

>    *
>    * Takes the information stored in the frame_info, a pair of coordinates, and
>    * returns the address of the first color channel.
>    * This function assumes the channels are packed together, i.e. a color channel
>    * comes immediately after another in the memory. And therefore, this function
>    * doesn't work for YUV with chroma subsampling (e.g. YUV420 and NV21).
> + *
> + * The caller must ensure that the framebuffer associated with this request uses a pixel format
> + * where block_h == block_w == 1, otherwise the returned pointer can be outside the buffer.
>    */
>   static void *packed_pixels_addr(const struct vkms_frame_info *frame_info,
>   				int x, int y)
> @@ -53,6 +69,13 @@ static int get_x_position(const struct vkms_frame_info *frame_info, int limit, i
>   	return x;
>   }
>   
> +/*
> + * The following  functions take pixel data from the buffer and convert them to the format

Double-spacing.

> + * ARGB16161616 in out_pixel.
> + *
> + * They are used in the `vkms_compose_row` function to handle multiple formats.

For cross-referencing functions, we use vkms_compose_row() [1].

[1] 
https://docs.kernel.org/doc-guide/kernel-doc.html#highlights-and-cross-references

> + */
> +
>   static void ARGB8888_to_argb_u16(u8 *src_pixels, struct pixel_argb_u16 *out_pixel)
>   {
>   	/*
> @@ -145,12 +168,11 @@ void vkms_compose_row(struct line_buffer *stage_buffer, struct vkms_plane_state
>   }
>   
>   /*
> - * The following  functions take an line of argb_u16 pixels from the
> - * src_buffer, convert them to a specific format, and store them in the
> - * destination.
> + * The following functions take one argb_u16 pixel and convert it to a specific format. The

For cross-referencing structs, look here [1].

> + * result is stored in @dst_pixels.
>    *
> - * They are used in the `compose_active_planes` to convert and store a line
> - * from the src_buffer to the writeback buffer.
> + * They are used in the `vkms_writeback_row` to convert and store a pixel from the src_buffer to

Same.

> + * the writeback buffer.
>    */
>   static void argb_u16_to_ARGB8888(u8 *dst_pixels, struct pixel_argb_u16 *in_pixel)
>   {
> @@ -216,6 +238,14 @@ static void argb_u16_to_RGB565(u8 *dst_pixels, struct pixel_argb_u16 *in_pixel)
>   	*pixels = cpu_to_le16(r << 11 | g << 5 | b);
>   }
>   
> +/**
> + * Generic loop for all supported writeback format. It is executed just after the blending to
> + * write a line in the writeback buffer.
> + *
> + * @wb: Job where to insert the final image
> + * @src_buffer: Line to write
> + * @y: Row to write in the writeback buffer
> + */
>   void vkms_writeback_row(struct vkms_writeback_job *wb,
>   			const struct line_buffer *src_buffer, int y)
>   {
> @@ -229,6 +259,13 @@ void vkms_writeback_row(struct vkms_writeback_job *wb,
>   		wb->pixel_write(dst_pixels, &in_pixels[x]);
>   }
>   
> +/**

Where is the function name?

> + * Retrieve the correct read_pixel function for a specific format.
> + * The returned pointer is NULL for unsupported pixel formats. The caller must ensure that the
> + * pointer is valid before using it in a vkms_plane_state.
> + *
> + * @format: DRM_FORMAT_* value for which to obtain a conversion function (see [drm_fourcc.h])
> + */
>   void *get_pixel_conversion_function(u32 format)
>   {
>   	switch (format) {
> @@ -247,6 +284,13 @@ void *get_pixel_conversion_function(u32 format)
>   	}
>   }
>   
> +/**

Same.

Best Regards,
- Maíra

> + * Retrieve the correct write_pixel function for a specific format.
> + * The returned pointer is NULL for unsupported pixel formats. The caller must ensure that the
> + * pointer is valid before using it in a vkms_writeback_job.
> + *
> + * @format: DRM_FORMAT_* value for which to obtain a conversion function (see [drm_fourcc.h])
> + */
>   void *get_pixel_write_function(u32 format)
>   {
>   	switch (format) {
> 

  parent reply	other threads:[~2024-03-25 13:32 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 17:44 [PATCH v5 00/16] drm/vkms: Reimplement line-per-line pixel conversion for plane reading Louis Chauvet
2024-03-13 17:44 ` [PATCH v5 01/16] drm/vkms: Code formatting Louis Chauvet
2024-03-25 12:03   ` Pekka Paalanen
2024-03-25 13:13   ` Maíra Canal
2024-03-13 17:44 ` [PATCH v5 02/16] drm/vkms: Use drm_frame directly Louis Chauvet
2024-03-25 12:04   ` Pekka Paalanen
2024-03-25 13:20   ` Maíra Canal
2024-03-26 15:56     ` Louis Chauvet
2024-03-13 17:44 ` [PATCH v5 03/16] drm/vkms: write/update the documentation for pixel conversion and pixel write functions Louis Chauvet
2024-03-13 19:02   ` Randy Dunlap
2024-03-25 13:32   ` Maíra Canal [this message]
2024-03-26 15:56     ` Louis Chauvet
2024-03-13 17:44 ` [PATCH v5 04/16] drm/vkms: Add typedef and documentation for pixel_read and pixel_write functions Louis Chauvet
2024-03-25 12:04   ` Pekka Paalanen
2024-03-26 15:56     ` Louis Chauvet
2024-03-25 13:56   ` Maíra Canal
2024-03-26 15:56     ` Louis Chauvet
2024-03-27 15:03       ` Maíra Canal
2024-03-13 17:44 ` [PATCH v5 05/16] drm/vkms: Add dummy pixel_read/pixel_write callbacks to avoid NULL pointers Louis Chauvet
2024-03-13 19:08   ` Randy Dunlap
2024-03-25 12:05   ` Pekka Paalanen
2024-03-26 15:56     ` Louis Chauvet
2024-03-25 13:59   ` Maíra Canal
2024-03-26 15:56     ` Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 06/16] drm/vkms: Use const for input pointers in pixel_read an pixel_write functions Louis Chauvet
2024-03-25 12:05   ` Pekka Paalanen
2024-03-25 14:00   ` Maíra Canal
2024-03-13 17:45 ` [PATCH v5 07/16] drm/vkms: Update pixels accessor to support packed and multi-plane formats Louis Chauvet
2024-03-25 12:40   ` Pekka Paalanen
2024-03-26 15:56     ` Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 08/16] drm/vkms: Avoid computing blending limits inside pre_mul_alpha_blend Louis Chauvet
2024-03-25 12:41   ` Pekka Paalanen
2024-03-26 15:57     ` Louis Chauvet
2024-03-27 11:48       ` Pekka Paalanen
2024-04-08  7:50         ` Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 09/16] drm/vkms: Introduce pixel_read_direction enum Louis Chauvet
2024-03-25 13:11   ` Pekka Paalanen
2024-03-26 15:57     ` Louis Chauvet
2024-03-27 12:16       ` Pekka Paalanen
2024-04-08  7:50         ` Louis Chauvet
2024-04-09  7:35           ` Pekka Paalanen
2024-04-09 10:06             ` Louis Chauvet
2024-03-25 14:07   ` Maíra Canal
2024-03-26 15:57     ` Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 10/16] drm/vkms: Re-introduce line-per-line composition algorithm Louis Chauvet
2024-03-25 14:15   ` Maíra Canal
2024-03-25 14:56     ` Pekka Paalanen
2024-03-26 15:57     ` Louis Chauvet
2024-03-25 15:43   ` Pekka Paalanen
2024-03-26 15:57     ` Louis Chauvet
2024-03-27 12:29       ` Pekka Paalanen
2024-04-08  7:50         ` Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 11/16] drm/vkms: Add YUV support Louis Chauvet
2024-03-13 19:20   ` Randy Dunlap
2024-03-14 14:41     ` Louis Chauvet
2024-03-25 14:26   ` Maíra Canal
2024-03-26 15:57     ` Louis Chauvet
2024-03-27 12:59       ` Pekka Paalanen
2024-04-08  7:50         ` Louis Chauvet
2024-03-27 12:11   ` Philipp Zabel
2024-04-08  7:50     ` Louis Chauvet
2024-03-27 14:23   ` Pekka Paalanen
2024-04-08  7:50     ` Louis Chauvet
2024-04-09  7:58       ` Pekka Paalanen
2024-04-09 10:06         ` Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 12/16] drm/vkms: Add range and encoding properties to the plane Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 13/16] drm/vkms: Drop YUV formats TODO Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 14/16] drm/vkms: Create KUnit tests for YUV conversions Louis Chauvet
2024-03-25 14:34   ` Maíra Canal
2024-03-26 15:57     ` Louis Chauvet
2024-03-28 13:26     ` Pekka Paalanen
2024-03-13 17:45 ` [PATCH v5 15/16] drm/vkms: Add how to run the Kunit tests Louis Chauvet
2024-03-13 17:45 ` [PATCH v5 16/16] drm/vkms: Add support for DRM_FORMAT_R* Louis Chauvet
2024-03-28 14:00   ` Pekka Paalanen
2024-04-08  7:50     ` Louis Chauvet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cae591ee-cd61-421c-b3b4-810790836f1b@igalia.com \
    --to=mcanal@igalia.com \
    --cc=airlied@gmail.com \
    --cc=arthurgrillo@riseup.net \
    --cc=corbet@lwn.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=jeremie.dautheribes@bootlin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=louis.chauvet@bootlin.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marcheu@google.com \
    --cc=melissa.srw@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=mripard@kernel.org \
    --cc=nicolejadeyee@google.com \
    --cc=pekka.paalanen@haloniitty.fi \
    --cc=rodrigosiqueiramelo@gmail.com \
    --cc=seanpaul@google.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.