All of lore.kernel.org
 help / color / mirror / Atom feed
From: Louis Chauvet <louis.chauvet@bootlin.com>
To: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: "Rodrigo Siqueira" <rodrigosiqueiramelo@gmail.com>,
	"Melissa Wen" <melissa.srw@gmail.com>,
	"Maíra Canal" <mairacanal@riseup.net>,
	"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>,
	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 07/16] drm/vkms: Update pixels accessor to support packed and multi-plane formats.
Date: Tue, 26 Mar 2024 16:56:59 +0100	[thread overview]
Message-ID: <ZgLwSwck8iixjmjB@localhost.localdomain> (raw)
In-Reply-To: <20240325144043.77a42acb.pekka.paalanen@collabora.com>

Le 25/03/24 - 14:40, Pekka Paalanen a écrit :
> On Wed, 13 Mar 2024 18:45:01 +0100
> Louis Chauvet <louis.chauvet@bootlin.com> wrote:
> 
> > Introduce the usage of block_h/block_w to compute the offset and the
> > pointer of a pixel. The previous implementation was specialized for
> > planes with block_h == block_w == 1. To avoid confusion and allow easier
> > implementation of tiled formats. It also remove the usage of the
> > deprecated format field `cpp`.
> > 
> > Introduce the plane_index parameter to get an offset/pointer on a
> > different plane.
> > 
> > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > ---
> >  drivers/gpu/drm/vkms/vkms_formats.c | 76 +++++++++++++++++++++++++------------
> >  1 file changed, 52 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c
> > index b2f8dfc26c35..649d75d05b1f 100644
> > --- a/drivers/gpu/drm/vkms/vkms_formats.c
> > +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> > @@ -10,23 +10,43 @@
> >  #include "vkms_formats.h"
> >  
> >  /**
> > - * pixel_offset() - Get the offset of the pixel at coordinates x/y in the first plane
> > + * packed_pixels_offset() - Get the offset of the block containing the pixel at coordinates x/y
> >   *
> >   * @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
> > + * @plane_index: The index of the plane to use
> > + * @offset: The returned offset inside the buffer of the block
> > + * @rem_x,@rem_y: The returned coordinate of the requested pixel in the block
> >   *
> > - * 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.
> > + * As some pixel formats store multiple pixels in a block (DRM_FORMAT_R* for example), some
> > + * pixels are not individually addressable. This function return 3 values: the offset of the
> > + * whole block, and the coordinate of the requested pixel inside this block.
> > + * For example, if the format is DRM_FORMAT_R1 and the requested coordinate is 13,5, the offset
> > + * will point to the byte 5*pitches + 13/8 (second byte of the 5th line), and the rem_x/rem_y
> > + * coordinates will be (13 % 8, 5 % 1) = (5, 0)
> > + *
> > + * With this function, the caller just have to extract the correct pixel from the block.
> >   */
> > -static size_t pixel_offset(const struct vkms_frame_info *frame_info, int x, int y)
> > +static void packed_pixels_offset(const struct vkms_frame_info *frame_info, int x, int y,
> > +				 int plane_index, int *offset, int *rem_x, int *rem_y)
> >  {
> >  	struct drm_framebuffer *fb = frame_info->fb;
> > +	const struct drm_format_info *format = frame_info->fb->format;
> > +	/* Directly using x and y to multiply pitches and format->ccp is not sufficient because
> > +	 * in some formats a block can represent multiple pixels.
> > +	 *
> > +	 * Dividing x and y by the block size allows to extract the correct offset of the block
> > +	 * containing the pixel.
> > +	 */
> >  
> > -	return fb->offsets[0] + (y * fb->pitches[0])
> > -			      + (x * fb->format->cpp[0]);
> > +	int block_x = x / drm_format_info_block_width(format, plane_index);
> > +	int block_y = y / drm_format_info_block_height(format, plane_index);
> > +	*rem_x = x % drm_format_info_block_width(format, plane_index);
> > +	*rem_y = x % drm_format_info_block_height(format, plane_index);
> 
> typo: x should be y

Fixed in v6.
 
> 
> > +	*offset = fb->offsets[plane_index] +
> > +		  block_y * fb->pitches[plane_index] +
> > +		  block_x * format->char_per_block[plane_index];
> >  }
> 
> Ok, this function looks very much plausible for handling blocky
> formats. Good.

Thanks!

> >  
> >  /**
> > @@ -36,30 +56,35 @@ static size_t pixel_offset(const struct vkms_frame_info *frame_info, int x, int
> >   * @frame_info: Buffer metadata
> >   * @x: The x(width) coordinate inside the plane
> >   * @y: The y(height) coordinate inside the plane
> > + * @plane_index: The index of the plane
> > + * @addr: The returned pointer
> > + * @rem_x,@rem_y: The returned coordinate of the requested pixel in the block
> >   *
> > - * 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).
> > + * Takes the information stored in the frame_info, a pair of coordinates, and returns the address
> > + * of the block containing this pixel and the pixel position inside this block.
> >   *
> > - * 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.
> > + * See @packed_pixel_offset for details about rem_x/rem_y behavior.
> >   */
> > -static void *packed_pixels_addr(const struct vkms_frame_info *frame_info,
> > -				int x, int y)
> > +static void packed_pixels_addr(const struct vkms_frame_info *frame_info,
> > +			       int x, int y, int plane_index, u8 **addr, int *rem_x,
> > +			       int *rem_y)
> >  {
> > -	size_t offset = pixel_offset(frame_info, x, y);
> > +	int offset;
> >  
> > -	return (u8 *)frame_info->map[0].vaddr + offset;
> > +	packed_pixels_offset(frame_info, x, y, plane_index, &offset, rem_x, rem_y);
> > +	*addr = (u8 *)frame_info->map[0].vaddr + offset;
> >  }
> >  
> > -static void *get_packed_src_addr(const struct vkms_frame_info *frame_info, int y)
> > +static void *get_packed_src_addr(const struct vkms_frame_info *frame_info, int y,
> > +				 int plane_index)
> >  {
> >  	int x_src = frame_info->src.x1 >> 16;
> >  	int y_src = y - frame_info->rotated.y1 + (frame_info->src.y1 >> 16);
> > +	u8 *addr;
> > +	int rem_x, rem_y;
> >  
> > -	return packed_pixels_addr(frame_info, x_src, y_src);
> > +	packed_pixels_addr(frame_info, x_src, y_src, plane_index, &addr, &rem_x, &rem_y);
> 
> How can the caller be not interested in rem_x, rem_y?

At this point of the series, I did not change how the rest was working. As 
this function will be deleted later, I just adapted it to use the new 
packed_pixel_addr implementation.
 
> Maybe there is no IGT test that uses DRM_FORMAT_R1 FB on a plane and
> has a source rectangle whose x is not divisible by 8 pixels?
> Or maybe the FB is filled with a solid color instead of a pattern that
> would show source rectangle positioning problems?

Currently, there is no DRM_FORMAT_R1 test in IGT, and all formats 
supported by VKMS are aligned on 8/16 bits with block_w == block_h == 1, 
so rem_x and rem_y will be equal to zero.

> Maybe at this point of the series, this should assert that rem_x and
> rem_y are zero? That's what vkms_compose_row() assumes, right?

Even more specificaly, vkms_compose_row() assumes that
block_w == block_h == 1, so maybe more

	WARN_ONCE(drm_format_info_block_width(format, plane_index) != 1, "get_packed_pixel_addr() only support formats with block_w == 1");
	WARN_ONCE(drm_format_info_block_hieght(format, plane_index) != 1, "get_packed_pixel_addr() only support formats with block_h == 1");

Thanks,
Louis Chauvet

> 
> Thanks,
> pq
> 
> > +	return addr;
> >  }
> >  
> >  static int get_x_position(const struct vkms_frame_info *frame_info, int limit, int x)
> > @@ -168,14 +193,14 @@ void vkms_compose_row(struct line_buffer *stage_buffer, struct vkms_plane_state
> >  {
> >  	struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
> >  	struct vkms_frame_info *frame_info = plane->frame_info;
> > -	u8 *src_pixels = get_packed_src_addr(frame_info, y);
> > +	u8 *src_pixels = get_packed_src_addr(frame_info, y, 0);
> >  	int limit = min_t(size_t, drm_rect_width(&frame_info->dst), stage_buffer->n_pixels);
> >  
> >  	for (size_t x = 0; x < limit; x++, src_pixels += frame_info->fb->format->cpp[0]) {
> >  		int x_pos = get_x_position(frame_info, limit, x);
> >  
> >  		if (drm_rotation_90_or_270(frame_info->rotation))
> > -			src_pixels = get_packed_src_addr(frame_info, x + frame_info->rotated.y1)
> > +			src_pixels = get_packed_src_addr(frame_info, x + frame_info->rotated.y1, 0)
> >  				+ frame_info->fb->format->cpp[0] * y;
> >  
> >  		plane->pixel_read(src_pixels, &out_pixels[x_pos]);
> > @@ -276,7 +301,10 @@ void vkms_writeback_row(struct vkms_writeback_job *wb,
> >  {
> >  	struct vkms_frame_info *frame_info = &wb->wb_frame_info;
> >  	int x_dst = frame_info->dst.x1;
> > -	u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
> > +	u8 *dst_pixels;
> > +	int rem_x, rem_y;
> > +
> > +	packed_pixels_addr(frame_info, x_dst, y, 0, &dst_pixels, &rem_x, &rem_y);
> >  	struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
> >  	int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst), src_buffer->n_pixels);
> >  
> > 
> 



-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2024-03-26 15:57 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
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 [this message]
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=ZgLwSwck8iixjmjB@localhost.localdomain \
    --to=louis.chauvet@bootlin.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=maarten.lankhorst@linux.intel.com \
    --cc=mairacanal@riseup.net \
    --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@collabora.com \
    --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.