On Mon, 4 Apr 2022 17:45:11 -0300 Igor Torrente igormtorrente@gmail.com wrote:

This commit is the groundwork to introduce new formats to the planes and writeback buffer. As part of it, a new buffer metadata field is added to `vkms_writeback_job`, this metadata is represented by the `vkms_composer` struct.

Hi,

should this be talking about vkms_frame_info struct instead?

Also adds two new function pointers (`{wb,plane}_format_transform_func`) are defined to handle format conversion to/from internal format.

These things will allow us, in the future, to have different compositing and wb format types.

V2: Change the code to get the drm_framebuffer reference and not copy its contents(Thomas Zimmermann). V3: Drop the refcount in the wb code(Thomas Zimmermann). V5: Add {wb,plane}_format_transform_func to vkms_writeback_job and vkms_plane_state (Pekka Paalanen)

Signed-off-by: Igor Torrente igormtorrente@gmail.com

drivers/gpu/drm/vkms/vkms_composer.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.h | 31 +++++++++++++++++++++------ drivers/gpu/drm/vkms/vkms_plane.c | 10 ++++----- drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++++++++++++++--- 4 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 2d946368a561..95029d2ebcac 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -153,7 +153,7 @@ static void compose_plane(struct vkms_frame_info *primary_plane_info, struct vkms_frame_info *plane_frame_info, void *vaddr_out) {

• struct drm_framebuffer *fb = &plane_frame_info->fb;

• struct drm_framebuffer *fb = plane_frame_info->fb; void *vaddr; void (*pixel_blend)(const u8 *p_src, u8 *p_dst);

@@ -175,7 +175,7 @@ static int compose_active_planes(void **vaddr_out, struct vkms_frame_info *primary_plane_info, struct vkms_crtc_state *crtc_state) {

• struct drm_framebuffer *fb = &primary_plane_info->fb;

• struct drm_framebuffer *fb = primary_plane_info->fb; struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0); const void *vaddr; int i;

diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h index 2e6342164bef..2704cfb6904b 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.h +++ b/drivers/gpu/drm/vkms/vkms_drv.h @@ -22,13 +22,8 @@

#define NUM_OVERLAY_PLANES 8

-struct vkms_writeback_job {

• struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
• struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];

-};

struct vkms_frame_info {

• struct drm_framebuffer fb;

• struct drm_framebuffer *fb; struct drm_rect src, dst; struct dma_buf_map map[DRM_FORMAT_MAX_PLANES]; unsigned int offset;

@@ -36,6 +31,29 @@ struct vkms_frame_info { unsigned int cpp; };

+struct pixel_argb_u16 {

• u16 a, r, g, b;

+};

+struct line_buffer {

• size_t n_pixels;
• struct pixel_argb_u16 *pixels;

+};

+typedef void +(*wb_format_transform_func)(struct vkms_frame_info *frame_info,

• 	    const struct line_buffer *buffer, int y);
  

+typedef void +(*plane_format_transform_func)(struct line_buffer *buffer,

• 	       const struct vkms_frame_info *frame_info, int y);
  

It wasn't immediately obvious to me in which direction these function types work from their names. The arguments are not wb and plane but vkms_frame_info and line_buffer in both. The implementations of these functions would have nothing specific to a wb or a plane either, would they?

What about naming them frame_to_line_func and line_to_frame_func?

+struct vkms_writeback_job {

• struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
• struct vkms_frame_info frame_info;

Which frame_info is this? Should the field be called wb_frame_info?

• wb_format_transform_func format_func;

line_to_frame_func wb_write;

perhaps? The type explains the general type of the function, and the field name refers to what it is used for.

+};

/**

• vkms_plane_state - Driver specific plane state
• @base: base plane state

@@ -44,6 +62,7 @@ struct vkms_frame_info { struct vkms_plane_state { struct drm_shadow_plane_state base; struct vkms_frame_info *frame_info;

• plane_format_transform_func format_func;

Similarly here, maybe

frame_to_line_func plane_read;

perhaps?

};

struct vkms_plane { diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index a56b0f76eddd..28752af0118c 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -50,12 +50,12 @@ static void vkms_plane_destroy_state(struct drm_plane *plane, struct vkms_plane_state *vkms_state = to_vkms_plane_state(old_state); struct drm_crtc *crtc = vkms_state->base.base.crtc;

• if (crtc) {

• if (crtc && vkms_state->frame_info->fb) { /* dropping the reference we acquired in
  • vkms_primary_plane_update()
  */

• if (drm_framebuffer_read_refcount(&vkms_state->frame_info->fb))
  

• 	drm_framebuffer_put(&vkms_state->frame_info->fb);
  

• if (drm_framebuffer_read_refcount(vkms_state->frame_info->fb))
  

• 	drm_framebuffer_put(vkms_state->frame_info->fb);
  

  }

  kfree(vkms_state->frame_info);

@@ -110,9 +110,9 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, frame_info = vkms_plane_state->frame_info; memcpy(&frame_info->src, &new_state->src, sizeof(struct drm_rect)); memcpy(&frame_info->dst, &new_state->dst, sizeof(struct drm_rect));

• memcpy(&frame_info->fb, fb, sizeof(struct drm_framebuffer));

• frame_info->fb = fb;

This change, replacing the memcpy with storing a pointer, seems to be another major point of this patch. Should it be a separate patch? It doesn't seem to fit with the current commit message.

I have no idea what kind of locking or referencing a drm_framebuffer would need, and I suspect that would be easier to review if it was a patch of its own.

memcpy(&frame_info->map, &shadow_plane_state->data, sizeof(frame_info->map));

• drm_framebuffer_get(&frame_info->fb);

• drm_framebuffer_get(frame_info->fb);

Does drm_framebuffer_get() not return anything?

To me it would be more idiomatic to write something like

frame_info->fb = drm_framebuffer_get(fb);

I don't know if that pattern is used in the kernel, but I use it in userspace to emphasise that frame_info owns a new reference rather than borrowing someone else's.

Thanks, pq

frame_info->offset = fb->offsets[0]; frame_info->pitch = fb->pitches[0]; frame_info->cpp = fb->format->cpp[0]; diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c b/drivers/gpu/drm/vkms/vkms_writeback.c index 746cb0abc6ec..ad4bb1fb37ca 100644 --- a/drivers/gpu/drm/vkms/vkms_writeback.c +++ b/drivers/gpu/drm/vkms/vkms_writeback.c @@ -74,12 +74,15 @@ static int vkms_wb_prepare_job(struct drm_writeback_connector *wb_connector, if (!vkmsjob) return -ENOMEM;

• ret = drm_gem_fb_vmap(job->fb, vkmsjob->map, vkmsjob->data);

• ret = drm_gem_fb_vmap(job->fb, vkmsjob->frame_info.map, vkmsjob->data); if (ret) { DRM_ERROR("vmap failed: %d\n", ret); goto err_kfree; }

• vkmsjob->frame_info.fb = job->fb;

• drm_framebuffer_get(vkmsjob->frame_info.fb);

• job->priv = vkmsjob;

  return 0;

@@ -98,7 +101,9 @@ static void vkms_wb_cleanup_job(struct drm_writeback_connector *connector, if (!job->fb) return;

• drm_gem_fb_vunmap(job->fb, vkmsjob->map);

• drm_gem_fb_vunmap(job->fb, vkmsjob->frame_info.map);

• drm_framebuffer_put(vkmsjob->frame_info.fb);

  vkmsdev = drm_device_to_vkms_device(job->fb->dev); vkms_set_composer(&vkmsdev->output, false);

@@ -115,14 +120,23 @@ static void vkms_wb_atomic_commit(struct drm_connector *conn, struct drm_writeback_connector *wb_conn = &output->wb_connector; struct drm_connector_state *conn_state = wb_conn->base.state; struct vkms_crtc_state *crtc_state = output->composer_state;

• struct drm_framebuffer *fb = connector_state->writeback_job->fb;

• struct vkms_writeback_job *active_wb;

• struct vkms_frame_info *wb_frame_info;

  if (!conn_state) return;

  vkms_set_composer(&vkmsdev->output, true);

• active_wb = conn_state->writeback_job->priv;

• wb_frame_info = &active_wb->frame_info;

• spin_lock_irq(&output->composer_lock);

• crtc_state->active_writeback = conn_state->writeback_job->priv;

• crtc_state->active_writeback = active_wb;
• wb_frame_info->offset = fb->offsets[0];
• wb_frame_info->pitch = fb->pitches[0];
• wb_frame_info->cpp = fb->format->cpp[0]; crtc_state->wb_pending = true; spin_unlock_irq(&output->composer_lock); drm_writeback_queue_job(wb_conn, connector_state);

On Sat, 23 Apr 2022 12:12:51 -0300 Igor Torrente igormtorrente@gmail.com wrote:

Hi Pekka,

On 4/20/22 08:23, Pekka Paalanen wrote:

...

On Mon, 4 Apr 2022 17:45:11 -0300 Igor Torrente igormtorrente@gmail.com wrote:

...

This commit is the groundwork to introduce new formats to the planes and writeback buffer. As part of it, a new buffer metadata field is added to `vkms_writeback_job`, this metadata is represented by the `vkms_composer` struct.

Hi,

should this be talking about vkms_frame_info struct instead?

Yes it should. I will fix this. Thanks.

...

...

Also adds two new function pointers (`{wb,plane}_format_transform_func`) are defined to handle format conversion to/from internal format.

These things will allow us, in the future, to have different compositing and wb format types.

V2: Change the code to get the drm_framebuffer reference and not copy its contents(Thomas Zimmermann). V3: Drop the refcount in the wb code(Thomas Zimmermann). V5: Add {wb,plane}_format_transform_func to vkms_writeback_job and vkms_plane_state (Pekka Paalanen)

Signed-off-by: Igor Torrente igormtorrente@gmail.com

drivers/gpu/drm/vkms/vkms_composer.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.h | 31 +++++++++++++++++++++------ drivers/gpu/drm/vkms/vkms_plane.c | 10 ++++----- drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++++++++++++++--- 4 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 2d946368a561..95029d2ebcac 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -153,7 +153,7 @@ static void compose_plane(struct vkms_frame_info *primary_plane_info, struct vkms_frame_info *plane_frame_info, void *vaddr_out) {

• struct drm_framebuffer *fb = &plane_frame_info->fb;

• struct drm_framebuffer *fb = plane_frame_info->fb; void *vaddr; void (*pixel_blend)(const u8 *p_src, u8 *p_dst);

@@ -175,7 +175,7 @@ static int compose_active_planes(void **vaddr_out, struct vkms_frame_info *primary_plane_info, struct vkms_crtc_state *crtc_state) {

• struct drm_framebuffer *fb = &primary_plane_info->fb;

• struct drm_framebuffer *fb = primary_plane_info->fb; struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0); const void *vaddr; int i;

diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h index 2e6342164bef..2704cfb6904b 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.h +++ b/drivers/gpu/drm/vkms/vkms_drv.h @@ -22,13 +22,8 @@

#define NUM_OVERLAY_PLANES 8

-struct vkms_writeback_job {

• struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
• struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];

-};

• struct vkms_frame_info {
• struct drm_framebuffer fb;

• struct drm_framebuffer *fb; struct drm_rect src, dst; struct dma_buf_map map[DRM_FORMAT_MAX_PLANES]; unsigned int offset;

@@ -36,6 +31,29 @@ struct vkms_frame_info { unsigned int cpp; };

+struct pixel_argb_u16 {

• u16 a, r, g, b;

+};

+struct line_buffer {

• size_t n_pixels;
• struct pixel_argb_u16 *pixels;

+};

+typedef void +(*wb_format_transform_func)(struct vkms_frame_info *frame_info,

• 	    const struct line_buffer *buffer, int y);
  

+typedef void +(*plane_format_transform_func)(struct line_buffer *buffer,

• 	       const struct vkms_frame_info *frame_info, int y);  
  

It wasn't immediately obvious to me in which direction these function types work from their names. The arguments are not wb and plane but vkms_frame_info and line_buffer in both. The implementations of these functions would have nothing specific to a wb or a plane either, would they?

No, there's nothing specific.

Do you think adding {dst_,src_} would be enough?

(*wb_format_transform_func)(struct vkms_frame_info *dst_frame_info, const struct line_buffer *src_buffer

(*plane_format_transform_func)(struct line_buffer *dst_buffer, const struct vkms_frame_info *src_frame_info,

No, because I was looking at the function pointer type names, and not the function arguments.

...

What about naming them frame_to_line_func and line_to_frame_func?

Sounds good. I will rename it.

Thanks!

...

...

+struct vkms_writeback_job {

• struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
• struct vkms_frame_info frame_info;

Which frame_info is this? Should the field be called wb_frame_info?

Considering it's already in the writeback_job struct do you think this necessary?

This struct has 'data' too, and that is not the wb buffer, right?

Hmm, if it's not the wb buffer, then using DRM_FORMAT_MAX_PLANES is odd...

In other words, what kind of misudertanding do you think can happen if this variable stay without the `wb_` prefix?

I spent a few minutes trying to find a case, but nothing came to my mind.

My question above is the confusion.

If all these members are about the wb destination buffer only, then where do the inputs come from and how are they reference-counted to make sure they are available when needed?

...

...

• wb_format_transform_func format_func;

line_to_frame_func wb_write;

perhaps? The type explains the general type of the function, and the field name refers to what it is used for.

...

+};

• /**
  • vkms_plane_state - Driver specific plane state
  • @base: base plane state

@@ -44,6 +62,7 @@ struct vkms_frame_info { struct vkms_plane_state { struct drm_shadow_plane_state base; struct vkms_frame_info *frame_info;

• plane_format_transform_func format_func;

Similarly here, maybe

frame_to_line_func plane_read;

perhaps?

Yeah, sure.

...

...

};

struct vkms_plane { diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index a56b0f76eddd..28752af0118c 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -50,12 +50,12 @@ static void vkms_plane_destroy_state(struct drm_plane *plane, struct vkms_plane_state *vkms_state = to_vkms_plane_state(old_state); struct drm_crtc *crtc = vkms_state->base.base.crtc;

• if (crtc) {

• if (crtc && vkms_state->frame_info->fb) { /* dropping the reference we acquired in
  • vkms_primary_plane_update()
  */

• if (drm_framebuffer_read_refcount(&vkms_state->frame_info->fb))
  

• 	drm_framebuffer_put(&vkms_state->frame_info->fb);
  

• if (drm_framebuffer_read_refcount(vkms_state->frame_info->fb))
  

• 	drm_framebuffer_put(vkms_state->frame_info->fb);
  

  }

  kfree(vkms_state->frame_info);

@@ -110,9 +110,9 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, frame_info = vkms_plane_state->frame_info; memcpy(&frame_info->src, &new_state->src, sizeof(struct drm_rect)); memcpy(&frame_info->dst, &new_state->dst, sizeof(struct drm_rect));

• memcpy(&frame_info->fb, fb, sizeof(struct drm_framebuffer));

• frame_info->fb = fb;

This change, replacing the memcpy with storing a pointer, seems to be another major point of this patch. Should it be a separate patch? It doesn't seem to fit with the current commit message.

I have no idea what kind of locking or referencing a drm_framebuffer would need, and I suspect that would be easier to review if it was a patch of its own.

Makes sense. I will do that.

...

...

memcpy(&frame_info->map, &shadow_plane_state->data, sizeof(frame_info->map));

• drm_framebuffer_get(&frame_info->fb);

• drm_framebuffer_get(frame_info->fb);

Does drm_framebuffer_get() not return anything?

No, it doesn't actually. This function increments the ref count of this struct and doesn't return anything.

D'oh. Oh well.

Thanks, pq

...

To me it would be more idiomatic to write something like

frame_info->fb = drm_framebuffer_get(fb); I spend few minutes trying to find a case but nothing comes to my mind. I don't know if that pattern is used in the kernel, but I use it in userspace to emphasise that frame_info owns a new reference rather than borrowing someone else's.

Thanks, pq

On Mon, 4 Apr 2022 17:45:12 -0300 Igor Torrente igormtorrente@gmail.com wrote:

Currently the blend function only accepts XRGB_8888 and ARGB_8888 as a color input.

This patch refactors all the functions related to the plane composition to overcome this limitation.

A new internal format(`struct pixel`) is introduced to deal with all

Hi,

struct pixel_argb_u16 was added in the previous patch.

possible inputs. It consists of 16 bits fields that represent each of the channels.

The pixels blend is done using this internal format. And new handlers are being added to convert a specific format to/from this internal format.

So the blend operation depends on these handlers to convert to this common format. The blended result, if necessary, is converted to the writeback buffer format.

This patch introduces three major differences to the blend function. 1 - All the planes are blended at once. 2 - The blend calculus is done as per line instead of per pixel. 3 - It is responsible to calculates the CRC and writing the writeback buffer(if necessary).

These changes allow us to allocate way less memory in the intermediate buffer to compute these operations. Because now we don't need to have the entire intermediate image lines at once, just one line is enough.

| Memory consumption (output dimensions) | |:--------------------------------------:| | Current | This patch | |:------------------:|:-----------------:| | Width * Heigth | 2 * Width |

Beyond memory, we also have a minor performance benefit from all these changes. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:

| Frametime | |:------------------------------------------:| | Implementation | Current | This commit | |:---------------:|:---------:|:------------:| | frametime range | 9~22 ms | 5~17 ms | | Average | 11.4 ms | 7.8 ms |

[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4

V2: Improves the performance drastically, by performing the operations per-line and not per-pixel(Pekka Paalanen). Minor improvements(Pekka Paalanen). V3: Changes the code to blend the planes all at once. This improves performance, memory consumption, and removes much of the weirdness of the V2(Pekka Paalanen and me). Minor improvements(Pekka Paalanen and me). V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant. V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen). Several security/robustness improvents(Pekka Paalanen). Removes check_planes_x_bounds function and allows partial partly off-screen(Pekka Paalanen).

Signed-off-by: Igor Torrente igormtorrente@gmail.com

Documentation/gpu/vkms.rst | 4 - drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 318 ++++++++++++-------------- drivers/gpu/drm/vkms/vkms_formats.c | 151 ++++++++++++ drivers/gpu/drm/vkms/vkms_formats.h | 12 + drivers/gpu/drm/vkms/vkms_plane.c | 3 + drivers/gpu/drm/vkms/vkms_writeback.c | 3 + 7 files changed, 311 insertions(+), 181 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 973e2d43108b..a49e4ae92653 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -118,10 +118,6 @@ Add Plane Features

There's lots of plane features we could add support for:

-- Clearing primary plane: clear primary plane before plane composition (at the

• start) for correctness of pixel blend ops. It also guarantees alpha channel
• is cleared in the target buffer for stable crc. [Good to get started]
• ARGB format on primary plane: blend the primary plane into background with translucent alpha.

diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile index 72f779cbfedd..1b28a6a32948 100644 --- a/drivers/gpu/drm/vkms/Makefile +++ b/drivers/gpu/drm/vkms/Makefile @@ -3,6 +3,7 @@ vkms-y := \ vkms_drv.o \ vkms_plane.o \ vkms_output.o \

• vkms_formats.o \ vkms_crtc.o \ vkms_composer.o \ vkms_writeback.o

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 95029d2ebcac..cf24015bf90f 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c

(For this file, I have removed all the minus diff lines from below to better see the new code.)

@@ -7,204 +7,186 @@ #include <drm/drm_fourcc.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_vblank.h> +#include <linux/minmax.h>

#include "vkms_drv.h"

+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha) {

• u32 new_color;

• new_color = (src * 0xffff + dst * (0xffff - alpha));

• return DIV_ROUND_CLOSEST(new_color, 0xffff);

This looks good.

}

/**

• • pre_mul_alpha_blend - alpha blending equation
• • @src_frame_info: source framebuffer's metadata
• • @stage_buffer: The line with the pixels from src_plane
• • @output_buffer: A line buffer that receives all the blends output
• • Using the information from the `frame_info`, this blends only the
• • necessary pixels from the `stage_buffer` to the `output_buffer`
• • using premultiplied blend formula.
• • The current DRM assumption is that pixel color values have been already
• • pre-multiplied with the alpha channel values. See more
• • drm_plane_create_blend_mode_property(). Also, this formula assumes a
• • completely opaque background.
  */

+static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info,

• 		struct line_buffer *stage_buffer,
  

• 		struct line_buffer *output_buffer)
  

{

• int x, x_dst = frame_info->dst.x1;
• struct pixel_argb_u16 *out = output_buffer->pixels + x_dst;
• struct pixel_argb_u16 *in = stage_buffer->pixels;
• int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	    stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++) {

• out[x].a = (u16)0xffff;
  

• out[x].r = pre_mul_blend_channel(in[x].r, out[x].r, in[x].a);
  

• out[x].g = pre_mul_blend_channel(in[x].g, out[x].g, in[x].a);
  

• out[x].b = pre_mul_blend_channel(in[x].b, out[x].b, in[x].a);
  

  }

}

+static bool check_y_limit(struct vkms_frame_info *frame_info, int y) {

• if (y >= frame_info->dst.y1 && y < frame_info->dst.y2)

• return true;
  
  

• return false;

}

/**

• • @wb_frame_info: The writeback frame buffer metadata
• • @crtc_state: The crtc state
• • @crc32: The crc output of the final frame
• • @output_buffer: A buffer of a row that will receive the result of the blend(s)
• • @stage_buffer: The line with the pixels from plane being blend to the output
• • This function blends the pixels (Using the `pre_mul_alpha_blend`)
• • from all planes, calculates the crc32 of the output from the former step,
• • and, if necessary, convert and store the output to the writeback buffer.
  */

+static void blend(struct vkms_writeback_job *wb,

•   struct vkms_crtc_state *crtc_state,
  

•   u32 *crc32, struct line_buffer *stage_buffer,
  

•   struct line_buffer *output_buffer, s64 row_size)
  

{

• struct vkms_plane_state **plane = crtc_state->active_planes;
• struct vkms_frame_info *primary_plane_info = plane[0]->frame_info;
• u32 n_active_planes = crtc_state->num_active_planes;
• int y_dst = primary_plane_info->dst.y1;
• int h_dst = drm_rect_height(&primary_plane_info->dst);
• int y_limit = y_dst + h_dst;
• int y, i;
• for (y = y_dst; y < y_limit; y++) {

• plane[0]->format_func(output_buffer, primary_plane_info, y);
  

This is a bad assumption, but the next patch removes the need for this assumption. The primary plane may not be the bottom-most AFAIU. Overlays below the primary exist on real hardware.

• /* If there are other planes besides primary, we consider the active
  

•  * planes should be in z-order and compose them associatively:
  

•  * ((primary <- overlay) <- cursor)
  

•  */
  

• for (i = 1; i < n_active_planes; i++) {
  

• 	if (!check_y_limit(plane[i]->frame_info, y))
  

• 		continue;
  

• 	plane[i]->format_func(stage_buffer, plane[i]->frame_info, y);
  

• 	pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
  

• 			    output_buffer);
  

• }
  
  

• *crc32 = crc32_le(*crc32, (void *)output_buffer->pixels, row_size);
  
  

• if (wb)
  

• 	wb->format_func(&wb->frame_info, output_buffer, y);
  

  }

}

+static int check_format_funcs(struct vkms_crtc_state *crtc_state,

• 	      struct vkms_writeback_job *active_wb)
  

{

• struct vkms_plane_state **planes = crtc_state->active_planes;

• u32 n_active_planes = crtc_state->num_active_planes;

• int i;

• for (i = 0; i < n_active_planes; i++)

• if (!planes[i]->format_func)
  

• 	return -1;
  
  

• if (active_wb && !active_wb->format_func)

• return -1;
  
  

• return 0;

}

+static int compose_active_planes(struct vkms_writeback_job *active_wb,

• 		 struct vkms_crtc_state *crtc_state,
  

• 		 u32 *crc32)
  

{

• int line_width, ret = 0, pixel_size = sizeof(struct pixel_argb_u16);

• struct vkms_frame_info *primary_plane_info = NULL;

• struct line_buffer output_buffer, stage_buffer;

• struct vkms_plane_state *act_plane = NULL;

• u32 wb_format;

• if (WARN_ON(pixel_size != 8))

Isn't there a compile-time assert macro for this? Having to actually run VKMS to check for this reduces the chances of finding it early. What's the reason for this check anyway?

• return -EINVAL;
  

• if (crtc_state->num_active_planes >= 1) {

• act_plane = crtc_state->active_planes[0];
  

• if (act_plane->base.base.plane->type == DRM_PLANE_TYPE_PRIMARY)
  

• 	primary_plane_info = act_plane->frame_info;
  

After the next patch, do you even need the primary plane for anything specifically? There is the map_is_null check below, but that should be done on all planes in the array, right?

I suspect the next patch, or another patch in this series, should just delete this chunk.

}

• if (!primary_plane_info)

• return -EINVAL;
  

• if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) return -EINVAL;

• if (WARN_ON(check_format_funcs(crtc_state, active_wb)))

• return -EINVAL;
  
  

• line_width = drm_rect_width(&primary_plane_info->dst);

• stage_buffer.n_pixels = line_width;

• output_buffer.n_pixels = line_width;

• stage_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);

• if (!stage_buffer.pixels) {

• DRM_ERROR("Cannot allocate memory for the output line buffer");
  

• return -ENOMEM;
  

• }

• output_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);

• if (!output_buffer.pixels) {

• DRM_ERROR("Cannot allocate memory for intermediate line buffer");
  

• ret = -ENOMEM;
  

• goto free_stage_buffer;
  

• }

• if (active_wb) {

• struct vkms_frame_info *wb_frame_info = &active_wb->frame_info;
  

• wb_format = wb_frame_info->fb->format->format;
  

I don't see wb_format being used, is it?

• wb_frame_info->src = primary_plane_info->src;
  

• wb_frame_info->dst = primary_plane_info->dst;
  

• }
• blend(active_wb, crtc_state, crc32, &stage_buffer,

•      &output_buffer, (s64)line_width * pixel_size);
  

What's the (s64) doing here?

Are byte sizes not usually expressed with size_t or ssize_t types, or is the kernel convention to use u64 and s64?

This makes me suspect that pixel_offset() and friends in vkms_format.c are going to need fixing as well. int type overflows at 2G.

• kvfree(output_buffer.pixels);

+free_stage_buffer:

• kvfree(stage_buffer.pixels);
• return ret;

}

/** @@ -222,13 +204,11 @@ void vkms_composer_worker(struct work_struct *work) struct vkms_crtc_state, composer_work); struct drm_crtc *crtc = crtc_state->base.crtc;

• struct vkms_writeback_job *active_wb = crtc_state->active_writeback; struct vkms_output *out = drm_crtc_to_vkms_output(crtc); bool crc_pending, wb_pending; u64 frame_start, frame_end;

• u32 crc32 = 0; int ret;

  spin_lock_irq(&out->composer_lock);

@@ -248,35 +228,19 @@ void vkms_composer_worker(struct work_struct *work) if (!crc_pending) return;

if (wb_pending)

• ret = compose_active_planes(active_wb, crtc_state, &crc32);
  

• else

• ret = compose_active_planes(NULL, crtc_state, &crc32);
  
  

• if (ret) return;

  if (wb_pending) { drm_writeback_signal_completion(&out->wb_connector, 0); spin_lock_irq(&out->composer_lock); crtc_state->wb_pending = false; spin_unlock_irq(&out->composer_lock); }

  /*

diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c new file mode 100644 index 000000000000..931a61405d6a --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_formats.c @@ -0,0 +1,151 @@ +// SPDX-License-Identifier: GPL-2.0+

+#include <drm/drm_rect.h> +#include <linux/minmax.h>

+#include "vkms_formats.h"

+static int pixel_offset(const struct vkms_frame_info *frame_info, int x, int y) +{

• return frame_info->offset + (y * frame_info->pitch)

• 		  + (x * frame_info->cpp);
  

+}

+/*

• • packed_pixels_addr - Get the pointer to pixel of a given pair of coordinates
• • @frame_info: Buffer metadata
• • @x: The x(width) coordinate of the 2D buffer
• • @y: The y(Heigth) coordinate of the 2D buffer
• • 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).
• */

+static void *packed_pixels_addr(const struct vkms_frame_info *frame_info,

• 		int x, int y)
  

+{

• int offset = pixel_offset(frame_info, x, y);
• return (u8 *)frame_info->map[0].vaddr + offset;

+}

+static void *get_packed_src_addr(const struct vkms_frame_info *frame_info, int y) +{

• int x_src = frame_info->src.x1 >> 16;
• int y_src = y - frame_info->dst.y1 + (frame_info->src.y1 >> 16);
• return packed_pixels_addr(frame_info, x_src, y_src);

+}

+static void ARGB8888_to_argb_u16(struct line_buffer *stage_buffer,

• 		 const struct vkms_frame_info *frame_info, int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u8 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• /*
  

•  * The 257 is the "conversion ratio". This number is obtained by the
  

•  * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get
  

•  * the best color value in a pixel format with more possibilities.
  

•  * A similar idea applies to others RGB color conversions.
  

•  */
  

• out_pixels[x].a = (u16)src_pixels[3] * 257;
  

• out_pixels[x].r = (u16)src_pixels[2] * 257;
  

• out_pixels[x].g = (u16)src_pixels[1] * 257;
  

• out_pixels[x].b = (u16)src_pixels[0] * 257;
  

• }

+}

+static void XRGB8888_to_argb_u16(struct line_buffer *stage_buffer,

• 		 const struct vkms_frame_info *frame_info, int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u8 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• out_pixels[x].a = (u16)0xffff;
  

• out_pixels[x].r = (u16)src_pixels[2] * 257;
  

• out_pixels[x].g = (u16)src_pixels[1] * 257;
  

• out_pixels[x].b = (u16)src_pixels[0] * 257;
  

• }

+}

+/*

• • 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.
• • They are used in the `compose_active_planes` to convert and store a line
• • from the src_buffer to the writeback buffer.
• */

+static void argb_u16_to_ARGB8888(struct vkms_frame_info *frame_info,

• 		 const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• /*
  

•  * This sequence below is important because the format's byte order is
  

•  * in little-endian. In the case of the ARGB8888 the memory is
  

•  * organized this way:
  

•  *
  

•  * | Addr     | = blue channel
  

•  * | Addr + 1 | = green channel
  

•  * | Addr + 2 | = Red channel
  

•  * | Addr + 3 | = Alpha channel
  

•  */
  

• dst_pixels[3] = DIV_ROUND_CLOSEST(in_pixels[x].a, 257);
  

• dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257);
  

• dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257);
  

• dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257);
  

• }

+}

+static void argb_u16_to_XRGB8888(struct vkms_frame_info *frame_info,

• 		 const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• dst_pixels[3] = (u8)0xff;
  

When writing to XRGB, it's not necessary to ensure the X channel has any sensible value. Anyone reading from XRGB must ignore that value anyway. So why not write something wacky here, like 0xa1, that is far enough from both 0x00 or 0xff to not be confused with them even visually? Also not 0x7f or 0x80 which are close to half of 0xff.

Or, you could save a whole function and just use argb_u16_to_ARGBxxxx() instead, even for XRGB destination.

• dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257);
  

• dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257);
  

• dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257);
  

• }

+}

+plane_format_transform_func get_plane_fmt_transform_function(u32 format) +{

• if (format == DRM_FORMAT_ARGB8888)

• return &ARGB8888_to_argb_u16;
  

• else if (format == DRM_FORMAT_XRGB8888)

• return &XRGB8888_to_argb_u16;
  

• else

• return NULL;
  

This works for now, but when more formats are added, I'd think a switch statement would look better.

+}

+wb_format_transform_func get_wb_fmt_transform_function(u32 format) +{

• if (format == DRM_FORMAT_ARGB8888)

• return &argb_u16_to_ARGB8888;
  

• else if (format == DRM_FORMAT_XRGB8888)

• return &argb_u16_to_XRGB8888;
  

• else

• return NULL;
  

+} diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h new file mode 100644 index 000000000000..adc5a17b9584 --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_formats.h @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0+

+#ifndef _VKMS_FORMATS_H_ +#define _VKMS_FORMATS_H_

+#include "vkms_drv.h"

+plane_format_transform_func get_plane_fmt_transform_function(u32 format);

+wb_format_transform_func get_wb_fmt_transform_function(u32 format);

This is good, exposing only what is necessary.

Thanks, pq

+#endif /* _VKMS_FORMATS_H_ */ diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index 28752af0118c..798243837fd0 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -10,6 +10,7 @@ #include <drm/drm_plane_helper.h>

#include "vkms_drv.h" +#include "vkms_formats.h"

static const u32 vkms_formats[] = { DRM_FORMAT_XRGB8888, @@ -100,6 +101,7 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, struct drm_shadow_plane_state *shadow_plane_state; struct drm_framebuffer *fb = new_state->fb; struct vkms_frame_info *frame_info;

• u32 fmt = fb->format->format;

  if (!new_state->crtc || !fb) return;

@@ -116,6 +118,7 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, frame_info->offset = fb->offsets[0]; frame_info->pitch = fb->pitches[0]; frame_info->cpp = fb->format->cpp[0];

• vkms_plane_state->format_func = get_plane_fmt_transform_function(fmt);

}

static int vkms_plane_atomic_check(struct drm_plane *plane, diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c b/drivers/gpu/drm/vkms/vkms_writeback.c index ad4bb1fb37ca..97f71e784bbf 100644 --- a/drivers/gpu/drm/vkms/vkms_writeback.c +++ b/drivers/gpu/drm/vkms/vkms_writeback.c @@ -11,6 +11,7 @@ #include <drm/drm_gem_shmem_helper.h>

#include "vkms_drv.h" +#include "vkms_formats.h"

static const u32 vkms_wb_formats[] = { DRM_FORMAT_XRGB8888, @@ -123,6 +124,7 @@ static void vkms_wb_atomic_commit(struct drm_connector *conn, struct drm_framebuffer *fb = connector_state->writeback_job->fb; struct vkms_writeback_job *active_wb; struct vkms_frame_info *wb_frame_info;

• u32 wb_format = fb->format->format;

  if (!conn_state) return;

@@ -140,6 +142,7 @@ static void vkms_wb_atomic_commit(struct drm_connector *conn, crtc_state->wb_pending = true; spin_unlock_irq(&output->composer_lock); drm_writeback_queue_job(wb_conn, connector_state);

• active_wb->format_func = get_wb_fmt_transform_function(wb_format);

}

static const struct drm_connector_helper_funcs vkms_wb_conn_helper_funcs = {

I forgot to respond some points from your review.

On 4/23/22 13:04, Igor Torrente wrote:

Hi Pekka,

On 4/20/22 09:36, Pekka Paalanen wrote:

...

On Mon, 4 Apr 2022 17:45:12 -0300 Igor Torrente igormtorrente@gmail.com wrote:

...

Currently the blend function only accepts XRGB_8888 and ARGB_8888 as a color input.

This patch refactors all the functions related to the plane composition to overcome this limitation.

A new internal format(`struct pixel`) is introduced to deal with all

Hi,

struct pixel_argb_u16 was added in the previous patch.

I will fix it. Thanks!

...

...

possible inputs. It consists of 16 bits fields that represent each of the channels.

The pixels blend is done using this internal format. And new handlers are being added to convert a specific format to/from this internal format.

So the blend operation depends on these handlers to convert to this common format. The blended result, if necessary, is converted to the writeback buffer format.

This patch introduces three major differences to the blend function. 1 - All the planes are blended at once. 2 - The blend calculus is done as per line instead of per pixel. 3 - It is responsible to calculates the CRC and writing the writeback buffer(if necessary).

These changes allow us to allocate way less memory in the intermediate buffer to compute these operations. Because now we don't need to have the entire intermediate image lines at once, just one line is enough.

| Memory consumption (output dimensions) | |:--------------------------------------:| | Current | This patch | |:------------------:|:-----------------:| | Width * Heigth | 2 * Width |

Beyond memory, we also have a minor performance benefit from all these changes. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:

| Frametime | |:------------------------------------------:| | Implementation | Current | This commit | |:---------------:|:---------:|:------------:| | frametime range | 9~22 ms | 5~17 ms | | Average | 11.4 ms | 7.8 ms |

[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4

V2: Improves the performance drastically, by performing the operations per-line and not per-pixel(Pekka Paalanen). Minor improvements(Pekka Paalanen). V3: Changes the code to blend the planes all at once. This improves performance, memory consumption, and removes much of the weirdness of the V2(Pekka Paalanen and me). Minor improvements(Pekka Paalanen and me). V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant. V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen). Several security/robustness improvents(Pekka Paalanen). Removes check_planes_x_bounds function and allows partial partly off-screen(Pekka Paalanen).

Signed-off-by: Igor Torrente igormtorrente@gmail.com

Documentation/gpu/vkms.rst | 4 - drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 318 ++++++++++++-------------- drivers/gpu/drm/vkms/vkms_formats.c | 151 ++++++++++++ drivers/gpu/drm/vkms/vkms_formats.h | 12 + drivers/gpu/drm/vkms/vkms_plane.c | 3 + drivers/gpu/drm/vkms/vkms_writeback.c | 3 + 7 files changed, 311 insertions(+), 181 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 973e2d43108b..a49e4ae92653 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -118,10 +118,6 @@ Add Plane Features

There's lots of plane features we could add support for:

-- Clearing primary plane: clear primary plane before plane composition (at the

• start) for correctness of pixel blend ops. It also guarantees alpha channel
• is cleared in the target buffer for stable crc. [Good to get started]
• • ARGB format on primary plane: blend the primary plane into background with translucent alpha.

diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile index 72f779cbfedd..1b28a6a32948 100644 --- a/drivers/gpu/drm/vkms/Makefile +++ b/drivers/gpu/drm/vkms/Makefile @@ -3,6 +3,7 @@ vkms-y := \ vkms_drv.o \ vkms_plane.o \ vkms_output.o \

• vkms_formats.o \ vkms_crtc.o \ vkms_composer.o \ vkms_writeback.o

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 95029d2ebcac..cf24015bf90f 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c

(For this file, I have removed all the minus diff lines from below to better see the new code.)

...

@@ -7,204 +7,186 @@ #include <drm/drm_fourcc.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_vblank.h> +#include <linux/minmax.h>

#include "vkms_drv.h"

+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha) {

• u32 new_color;

• new_color = (src * 0xffff + dst * (0xffff - alpha));

• return DIV_ROUND_CLOSEST(new_color, 0xffff);

This looks good.

...

}

/**

• • pre_mul_alpha_blend - alpha blending equation
• • @src_frame_info: source framebuffer's metadata
• • @stage_buffer: The line with the pixels from src_plane
• • @output_buffer: A line buffer that receives all the blends output
• • Using the information from the `frame_info`, this blends only the
• • necessary pixels from the `stage_buffer` to the `output_buffer`
• • using premultiplied blend formula.
• • The current DRM assumption is that pixel color values have been already
• • pre-multiplied with the alpha channel values. See more
• • drm_plane_create_blend_mode_property(). Also, this formula assumes a
• • completely opaque background. */

+static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info,

• 		struct line_buffer *stage_buffer,
  

• 		struct line_buffer *output_buffer)
  

  {
• int x, x_dst = frame_info->dst.x1;
• struct pixel_argb_u16 *out = output_buffer->pixels + x_dst;
• struct pixel_argb_u16 *in = stage_buffer->pixels;
• int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	    stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++) {

• out[x].a = (u16)0xffff;
  

• out[x].r = pre_mul_blend_channel(in[x].r, out[x].r, in[x].a);
  

• out[x].g = pre_mul_blend_channel(in[x].g, out[x].g, in[x].a);
  

• out[x].b = pre_mul_blend_channel(in[x].b, out[x].b, in[x].a);
  

  } }

+static bool check_y_limit(struct vkms_frame_info *frame_info, int y) {

• if (y >= frame_info->dst.y1 && y < frame_info->dst.y2)

• return true;
  
  

• return false; }

  /**

• • @wb_frame_info: The writeback frame buffer metadata
• • @crtc_state: The crtc state
• • @crc32: The crc output of the final frame
• • @output_buffer: A buffer of a row that will receive the result of the blend(s)
• • @stage_buffer: The line with the pixels from plane being blend to the output
• • This function blends the pixels (Using the `pre_mul_alpha_blend`)
• • from all planes, calculates the crc32 of the output from the former step,
• • and, if necessary, convert and store the output to the writeback buffer. */

+static void blend(struct vkms_writeback_job *wb,

•   struct vkms_crtc_state *crtc_state,
  

•   u32 *crc32, struct line_buffer *stage_buffer,
  

•   struct line_buffer *output_buffer, s64 row_size)
  

  {
• struct vkms_plane_state **plane = crtc_state->active_planes;
• struct vkms_frame_info *primary_plane_info = plane[0]->frame_info;
• u32 n_active_planes = crtc_state->num_active_planes;
• int y_dst = primary_plane_info->dst.y1;
• int h_dst = drm_rect_height(&primary_plane_info->dst);
• int y_limit = y_dst + h_dst;
• int y, i;
• for (y = y_dst; y < y_limit; y++) {

• plane[0]->format_func(output_buffer, primary_plane_info, y);
  

This is a bad assumption, but the next patch removes the need for this assumption. The primary plane may not be the bottom-most AFAIU. Overlays below the primary exist on real hardware.

...

• /* If there are other planes besides primary, we consider the active
  

•  * planes should be in z-order and compose them associatively:
  

•  * ((primary <- overlay) <- cursor)
  

•  */
  

• for (i = 1; i < n_active_planes; i++) {
  

• 	if (!check_y_limit(plane[i]->frame_info, y))
  

• 		continue;
  

• 	plane[i]->format_func(stage_buffer, plane[i]->frame_info, y);
  

• 	pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer,
  

• 			    output_buffer);
  

• }
  
  

• *crc32 = crc32_le(*crc32, (void *)output_buffer->pixels, row_size);
  
  

• if (wb)
  

• 	wb->format_func(&wb->frame_info, output_buffer, y);
  

  } }

+static int check_format_funcs(struct vkms_crtc_state *crtc_state,

• 	      struct vkms_writeback_job *active_wb)
  

  {

• struct vkms_plane_state **planes = crtc_state->active_planes;

• u32 n_active_planes = crtc_state->num_active_planes;

• int i;

• for (i = 0; i < n_active_planes; i++)

• if (!planes[i]->format_func)
  

• 	return -1;
  
  

• if (active_wb && !active_wb->format_func)

• return -1;
  
  

• return 0; }

+static int compose_active_planes(struct vkms_writeback_job *active_wb,

• 		 struct vkms_crtc_state *crtc_state,
  

• 		 u32 *crc32)
  

  {

• int line_width, ret = 0, pixel_size = sizeof(struct pixel_argb_u16);

• struct vkms_frame_info *primary_plane_info = NULL;

• struct line_buffer output_buffer, stage_buffer;

• struct vkms_plane_state *act_plane = NULL;

• u32 wb_format;

• if (WARN_ON(pixel_size != 8))

Isn't there a compile-time assert macro for this? Having to actually run VKMS to check for this reduces the chances of finding it early. What's the reason for this check anyway?

Yes, it exists.

include/linux/build_bug.h:1:#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)

I didn't add it because I can imagine some people very mad if the kernel did not compile because of vkms.

This check exists so we can call `crc32_le` for the entire line instead doing it for each channel of each pixel in case `struct `pixel_argb_u16` had any gap added by the compiler between the struct fields.

...

...

• return -EINVAL;
  

• if (crtc_state->num_active_planes >= 1) {

• act_plane = crtc_state->active_planes[0];
  

• if (act_plane->base.base.plane->type == DRM_PLANE_TYPE_PRIMARY)
  

• 	primary_plane_info = act_plane->frame_info;
  

After the next patch, do you even need the primary plane for anything specifically?

Yeah, I will not need it anymore.

...

There is the map_is_null check below, but that should be done on all planes in the array, right?

Yes, I guess so. And I don't know why it only checks for the primary_plane TBH.

...

I suspect the next patch, or another patch in this series, should just delete this chunk.

I should, and I will in the V6 of next patch.

...

...

}

• if (!primary_plane_info)

• return -EINVAL;
  

• if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) return -EINVAL;

• if (WARN_ON(check_format_funcs(crtc_state, active_wb)))

• return -EINVAL;
  
  

• line_width = drm_rect_width(&primary_plane_info->dst);

• stage_buffer.n_pixels = line_width;

• output_buffer.n_pixels = line_width;

• stage_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);

• if (!stage_buffer.pixels) {

• DRM_ERROR("Cannot allocate memory for the output line buffer");
  

• return -ENOMEM;
  

• }

• output_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);

• if (!output_buffer.pixels) {

• DRM_ERROR("Cannot allocate memory for intermediate line buffer");
  

• ret = -ENOMEM;
  

• goto free_stage_buffer;
  

• }

• if (active_wb) {

• struct vkms_frame_info *wb_frame_info = &active_wb->frame_info;
  

• wb_format = wb_frame_info->fb->format->format;
  

I don't see wb_format being used, is it?

This is probably a leftover from the last versions. Thanks for catching it.

...

...

• wb_frame_info->src = primary_plane_info->src;
  

• wb_frame_info->dst = primary_plane_info->dst;
  

• }
• blend(active_wb, crtc_state, crc32, &stage_buffer,

•      &output_buffer, (s64)line_width * pixel_size);
  

What's the (s64) doing here?

Are byte sizes not usually expressed with size_t or ssize_t types, or is the kernel convention to use u64 and s64?

This makes me suspect that pixel_offset() and friends in vkms_format.c are going to need fixing as well. int type overflows at 2G.

Yeah, I should be using size_t in all these places.

...

...

• kvfree(output_buffer.pixels);

+free_stage_buffer:

• kvfree(stage_buffer.pixels);

+can

• return ret; }

  /**

@@ -222,13 +204,11 @@ void vkms_composer_worker(struct work_struct *work) struct vkms_crtc_state, composer_work); struct drm_crtc *crtc = crtc_state->base.crtc;

• struct vkms_writeback_job *active_wb = crtc_state->active_writeback; struct vkms_output *out = drm_crtc_to_vkms_output(crtc); bool crc_pending, wb_pending; u64 frame_start, frame_end;

• u32 crc32 = 0; int ret;

  spin_lock_irq(&out->composer_lock);

@@ -248,35 +228,19 @@ void vkms_composer_worker(struct work_struct *work) if (!crc_pending) return;

if (wb_pending)

• ret = compose_active_planes(active_wb, crtc_state, &crc32);
  

• else

• ret = compose_active_planes(NULL, crtc_state, &crc32);
  
  

• if (ret) return;

  if (wb_pending) { drm_writeback_signal_completion(&out->wb_connector, 0); spin_lock_irq(&out->composer_lock); crtc_state->wb_pending = false; spin_unlock_irq(&out->composer_lock); }

  /*

diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c new file mode 100644 index 000000000000..931a61405d6a --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_formats.c @@ -0,0 +1,151 @@ +// SPDX-License-Identifier: GPL-2.0+

+#include <drm/drm_rect.h> +#include <linux/minmax.h>

+#include "vkms_formats.h"

+static int pixel_offset(const struct vkms_frame_info *frame_info, int x, int y) +{

• return frame_info->offset + (y * frame_info->pitch)

• 		  + (x * frame_info->cpp);
  

+}

+/*

• • packed_pixels_addr - Get the pointer to pixel of a given pair of coordinates
• • @frame_info: Buffer metadata
• • @x: The x(width) coordinate of the 2D buffer
• • @y: The y(Heigth) coordinate of the 2D buffercan
• • 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).
• */

+static void *packed_pixels_addr(const struct vkms_frame_info *frame_info,

• 		int x, int y)
  

+{

• int offset = pixel_offset(frame_info, x, y);
• return (u8 *)frame_info->map[0].vaddr + offset;

+}

+static void *get_packed_src_addr(const struct vkms_frame_info *frame_info, int y) +{

• int x_src = frame_info->src.x1 >> 16;
• int y_src = y - frame_info->dst.y1 + (frame_info->src.y1 >> 16);
• return packed_pixels_addr(frame_info, x_src, y_src);

+}

+static void ARGB8888_to_argb_u16(struct line_buffer *stage_buffer,

• 		 const struct vkms_frame_info *frame_info, int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u8 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• /*
  

•  * The 257 is the "conversion ratio". This number is obtained by the
  

•  * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get
  

•  * the best color value in a pixel format with more possibilities.
  

•  * A similar idea applies to others RGB color conversions.
  

•  */
  

• out_pixels[x].a = (u16)src_pixels[3] * 257;
  

• out_pixels[x].r = (u16)src_pixels[2] * 257;
  

• out_pixels[x].g = (u16)src_pixels[1] * 257;
  

• out_pixels[x].b = (u16)src_pixels[0] * 257;
  

• }

+}

+static void XRGB8888_to_argb_u16(struct line_buffer *stage_buffer,

• 		 const struct vkms_frame_info *frame_info, int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u8 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• out_pixels[x].a = (u16)0xffff;
  

• out_pixels[x].r = (u16)src_pixels[2] * 257;
  

• out_pixels[x].g = (u16)src_pixels[1] * 257;
  

• out_pixels[x].b = (u16)src_pixels[0] * 257;
  

• }

+}

+/*

• • 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.
• • They are used in the `compose_active_planes` to convert and store a line
• • from the src_buffer to the writeback buffer.
• */

+static void argb_u16_to_ARGB8888(struct vkms_frame_info *frame_info,

• 		 const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• /*
  

•  * This sequence below is important because the format's byte order is
  

•  * in little-endian. In the case of the ARGB8888 the memory is
  

•  * organized this way:
  

•  *
  

•  * | Addr     | = blue channel
  

•  * | Addr + 1 | = green channel
  

•  * | Addr + 2 | = Red channel
  

•  * | Addr + 3 | = Alpha channel
  

•  */
  

• dst_pixels[3] = DIV_ROUND_CLOSEST(in_pixels[x].a, 257);
  

• dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257);
  

• dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257);
  

• dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257);
  

• }

+}

+static void argb_u16_to_XRGB8888(struct vkms_frame_info *frame_info,

• 		 const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• dst_pixels[3] = (u8)0xff;
  

When writing to XRGB, it's not necessary to ensure the X channel has any sensible value. Anyone reading from XRGB must ignore that value anyway. So why not write something wacky here, like 0xa1, that is far enough from both 0x00 or 0xff to not be confused with them even visually? Also not 0x7f or 0x80 which are close to half of 0xff.

Or, you could save a whole function and just use argb_u16_to_ARGBxxxx() instead, even for XRGB destination.

Right. Maybe I could just leave the channel untouched.

...

...

• dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257);
  

• dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257);
  

• dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257);
  

• }

+}

+plane_format_transform_func get_plane_fmt_transform_function(u32 format) +{

• if (format == DRM_FORMAT_ARGB8888)

• return &ARGB8888_to_argb_u16;
  

• else if (format == DRM_FORMAT_XRGB8888)

• return &XRGB8888_to_argb_u16;
  

• else

• return NULL;
  

This works for now, but when more formats are added, I'd think a switch statement would look better.

ok.

...

...

+}

+wb_format_transform_func get_wb_fmt_transform_function(u32 format) +{

• if (format == DRM_FORMAT_ARGB8888)

• return &argb_u16_to_ARGB8888;
  

• else if (format == DRM_FORMAT_XRGB8888)

• return &argb_u16_to_XRGB8888;
  

• else

• return NULL;
  

+} diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h new file mode 100644 index 000000000000..adc5a17b9584 --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_formats.h @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0+

+#ifndef _VKMS_FORMATS_H_ +#define _VKMS_FORMATS_H_

+#include "vkms_drv.h"

+plane_format_transform_func get_plane_fmt_transform_function(u32 format);

+wb_format_transform_func get_wb_fmt_transform_function(u32 format);

This is good, exposing only what is necessary.

Thanks, pq

...

+#endif /* _VKMS_FORMATS_H_ */ diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index 28752af0118c..798243837fd0 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -10,6 +10,7 @@ #include <drm/drm_plane_helper.h>

#include "vkms_drv.h" +#include "vkms_formats.h"

static const u32 vkms_formats[] = { DRM_FORMAT_XRGB8888, @@ -100,6 +101,7 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, struct drm_shadow_plane_state *shadow_plane_state; struct drm_framebuffer *fb = new_state->fb; struct vkms_frame_info *frame_info;

• u32 fmt = fb->format->format;

  if (!new_state->crtc || !fb) return;

@@ -116,6 +118,7 @@ static void vkms_plane_atomic_update(struct drm_plane *plane, frame_info->offset = fb->offsets[0]; frame_info->pitch = fb->pitches[0]; frame_info->cpp = fb->format->cpp[0];

• vkms_plane_state->format_func = get_plane_fmt_transform_function(fmt); }

  static int vkms_plane_atomic_check(struct drm_plane *plane,

diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c b/drivers/gpu/drm/vkms/vkms_writeback.c index ad4bb1fb37ca..97f71e784bbf 100644 --- a/drivers/gpu/drm/vkms/vkms_writeback.c +++ b/drivers/gpu/drm/vkms/vkms_writeback.c @@ -11,6 +11,7 @@ #include <drm/drm_gem_shmem_helper.h>

#include "vkms_drv.h" +#include "vkms_formats.h"

static const u32 vkms_wb_formats[] = { DRM_FORMAT_XRGB8888, @@ -123,6 +124,7 @@ static void vkms_wb_atomic_commit(struct drm_connector *conn, struct drm_framebuffer *fb = connector_state->writeback_job->fb; struct vkms_writeback_job *active_wb; struct vkms_frame_info *wb_frame_info;

• u32 wb_format = fb->format->format;

  if (!conn_state) return;

@@ -140,6 +142,7 @@ static void vkms_wb_atomic_commit(struct drm_connector *conn, crtc_state->wb_pending = true; spin_unlock_irq(&output->composer_lock); drm_writeback_queue_job(wb_conn, connector_state);

• active_wb->format_func = get_wb_fmt_transform_function(wb_format); }

  static const struct drm_connector_helper_funcs vkms_wb_conn_helper_funcs = {

Hi Pekka,

On 4/25/22 05:10, Pekka Paalanen wrote:

On Sat, 23 Apr 2022 15:53:20 -0300 Igor Torrente igormtorrente@gmail.com wrote:

...

I forgot to respond some points from your review.

On 4/23/22 13:04, Igor Torrente wrote:

...

Hi Pekka,

On 4/20/22 09:36, Pekka Paalanen wrote:

...

On Mon, 4 Apr 2022 17:45:12 -0300 Igor Torrente igormtorrente@gmail.com wrote:

...

Currently the blend function only accepts XRGB_8888 and ARGB_8888 as a color input.

This patch refactors all the functions related to the plane composition to overcome this limitation.

A new internal format(`struct pixel`) is introduced to deal with all

Hi,

struct pixel_argb_u16 was added in the previous patch.

I will fix it. Thanks!

...

...

...

...

...

+static int compose_active_planes(struct vkms_writeback_job *active_wb,

• 		 struct vkms_crtc_state *crtc_state,
  

• 		 u32 *crc32)
  

  {

• int line_width, ret = 0, pixel_size = sizeof(struct pixel_argb_u16);

• struct vkms_frame_info *primary_plane_info = NULL;

• struct line_buffer output_buffer, stage_buffer;

• struct vkms_plane_state *act_plane = NULL;

• u32 wb_format;

• if (WARN_ON(pixel_size != 8))

Isn't there a compile-time assert macro for this? Having to actually run VKMS to check for this reduces the chances of finding it early. What's the reason for this check anyway?

Yes, it exists.

include/linux/build_bug.h:1:#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)

I didn't add it because I can imagine some people very mad if the kernel did not compile because of vkms.

But that would mean that VKMS is broken on those platforms. You'd better know which platforms VKMS is broken, so the Kconfig can stop VKMS from being built there at all. Or better, fix it before anyone needs VKMS there.

Right. Makes sense. I will add it then.

...

This check exists so we can call `crc32_le` for the entire line instead doing it for each channel of each pixel in case `struct `pixel_argb_u16` had any gap added by the compiler between the struct fields.

Oh the CRC computation. Good point.

Can you add a comment about that with the check?

Yeah, np.

I will copy the explanation above :)

...

...

...

...

• return -EINVAL;
  

• if (crtc_state->num_active_planes >= 1) {

• act_plane = crtc_state->active_planes[0];
  

• if (act_plane->base.base.plane->type == DRM_PLANE_TYPE_PRIMARY)
  

• 	primary_plane_info = act_plane->frame_info;
  

After the next patch, do you even need the primary plane for anything specifically?

Yeah, I will not need it anymore.

...

...

There is the map_is_null check below, but that should be done on all planes in the array, right?

Yes, I guess so. And I don't know why it only checks for the primary_plane TBH.

Maybe a left-over from times when it didn't have anything but a primary plane?

Maybe.

Anyway, I have added this verification to all active planes in the next version.

...

...

...

I suspect the next patch, or another patch in this series, should just delete this chunk.

I should, and I will in the V6 of next patch.

...

...

...

	}

• if (!primary_plane_info)

• return -EINVAL;
  

• if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0])))
  	return -EINVAL;
  
  

• if (WARN_ON(check_format_funcs(crtc_state, active_wb)))

• return -EINVAL;
  
  

• line_width = drm_rect_width(&primary_plane_info->dst);

• stage_buffer.n_pixels = line_width;

• output_buffer.n_pixels = line_width;

• stage_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);

• if (!stage_buffer.pixels) {

• DRM_ERROR("Cannot allocate memory for the output line buffer");
  

• return -ENOMEM;
  

• }

• output_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL);

• if (!output_buffer.pixels) {

• DRM_ERROR("Cannot allocate memory for intermediate line buffer");
  

• ret = -ENOMEM;
  

• goto free_stage_buffer;
  

• }

• if (active_wb) {

• struct vkms_frame_info *wb_frame_info = &active_wb->frame_info;
  

• wb_format = wb_frame_info->fb->format->format;
  

I don't see wb_format being used, is it?

This is probably a leftover from the last versions. Thanks for catching it.

...

...

• wb_frame_info->src = primary_plane_info->src;
  

• wb_frame_info->dst = primary_plane_info->dst;
  

• }
• blend(active_wb, crtc_state, crc32, &stage_buffer,

•      &output_buffer, (s64)line_width * pixel_size);
  

What's the (s64) doing here?

Are byte sizes not usually expressed with size_t or ssize_t types, or is the kernel convention to use u64 and s64?

This makes me suspect that pixel_offset() and friends in vkms_format.c are going to need fixing as well. int type overflows at 2G.

Yeah, I should be using size_t in all these places.

...

...

• kvfree(output_buffer.pixels);

+free_stage_buffer:

• kvfree(stage_buffer.pixels);

+can

• return ret; }

  /**

@@ -222,13 +204,11 @@ void vkms_composer_worker(struct work_struct *work) struct vkms_crtc_state, composer_work); struct drm_crtc *crtc = crtc_state->base.crtc;

• struct vkms_writeback_job *active_wb = crtc_state->active_writeback; struct vkms_output *out = drm_crtc_to_vkms_output(crtc); bool crc_pending, wb_pending; u64 frame_start, frame_end;

• u32 crc32 = 0; int ret;

  spin_lock_irq(&out->composer_lock);
  

@@ -248,35 +228,19 @@ void vkms_composer_worker(struct work_struct *work) if (!crc_pending) return;

	if (wb_pending)

• ret = compose_active_planes(active_wb, crtc_state, &crc32);
  

• else

• ret = compose_active_planes(NULL, crtc_state, &crc32);
  
  

• if (ret) return;

  if (wb_pending) {
  	drm_writeback_signal_completion(&out->wb_connector, 0);
  	spin_lock_irq(&out->composer_lock);
  	crtc_state->wb_pending = false;
  	spin_unlock_irq(&out->composer_lock);
  }
  
  /*
  

diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c new file mode 100644 index 000000000000..931a61405d6a --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_formats.c @@ -0,0 +1,151 @@ +// SPDX-License-Identifier: GPL-2.0+

+#include <drm/drm_rect.h> +#include <linux/minmax.h>

+#include "vkms_formats.h"

+static int pixel_offset(const struct vkms_frame_info *frame_info, int x, int y) +{

• return frame_info->offset + (y * frame_info->pitch)

• 		  + (x * frame_info->cpp);
  

+}

+/*

• • packed_pixels_addr - Get the pointer to pixel of a given pair of coordinates
• • @frame_info: Buffer metadata
• • @x: The x(width) coordinate of the 2D buffer
• • @y: The y(Heigth) coordinate of the 2D buffercan
• • 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).
• */

+static void *packed_pixels_addr(const struct vkms_frame_info *frame_info,

• 		int x, int y)
  

+{

• int offset = pixel_offset(frame_info, x, y);
• return (u8 *)frame_info->map[0].vaddr + offset;

+}

+static void *get_packed_src_addr(const struct vkms_frame_info *frame_info, int y) +{

• int x_src = frame_info->src.x1 >> 16;
• int y_src = y - frame_info->dst.y1 + (frame_info->src.y1 >> 16);
• return packed_pixels_addr(frame_info, x_src, y_src);

+}

+static void ARGB8888_to_argb_u16(struct line_buffer *stage_buffer,

• 		 const struct vkms_frame_info *frame_info, int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u8 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• /*
  

•  * The 257 is the "conversion ratio". This number is obtained by the
  

•  * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get
  

•  * the best color value in a pixel format with more possibilities.
  

•  * A similar idea applies to others RGB color conversions.
  

•  */
  

• out_pixels[x].a = (u16)src_pixels[3] * 257;
  

• out_pixels[x].r = (u16)src_pixels[2] * 257;
  

• out_pixels[x].g = (u16)src_pixels[1] * 257;
  

• out_pixels[x].b = (u16)src_pixels[0] * 257;
  

• }

+}

+static void XRGB8888_to_argb_u16(struct line_buffer *stage_buffer,

• 		 const struct vkms_frame_info *frame_info, int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u8 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• out_pixels[x].a = (u16)0xffff;
  

• out_pixels[x].r = (u16)src_pixels[2] * 257;
  

• out_pixels[x].g = (u16)src_pixels[1] * 257;
  

• out_pixels[x].b = (u16)src_pixels[0] * 257;
  

• }

+}

+/*

• • 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.
• • They are used in the `compose_active_planes` to convert and store a line
• • from the src_buffer to the writeback buffer.
• */

+static void argb_u16_to_ARGB8888(struct vkms_frame_info *frame_info,

• 		 const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• /*
  

•  * This sequence below is important because the format's byte order is
  

•  * in little-endian. In the case of the ARGB8888 the memory is
  

•  * organized this way:
  

•  *
  

•  * | Addr     | = blue channel
  

•  * | Addr + 1 | = green channel
  

•  * | Addr + 2 | = Red channel
  

•  * | Addr + 3 | = Alpha channel
  

•  */
  

• dst_pixels[3] = DIV_ROUND_CLOSEST(in_pixels[x].a, 257);
  

• dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257);
  

• dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257);
  

• dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257);
  

• }

+}

+static void argb_u16_to_XRGB8888(struct vkms_frame_info *frame_info,

• 		 const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• dst_pixels[3] = (u8)0xff;
  

When writing to XRGB, it's not necessary to ensure the X channel has any sensible value. Anyone reading from XRGB must ignore that value anyway. So why not write something wacky here, like 0xa1, that is far enough from both 0x00 or 0xff to not be confused with them even visually? Also not 0x7f or 0x80 which are close to half of 0xff.

Or, you could save a whole function and just use argb_u16_to_ARGBxxxx() instead, even for XRGB destination.

Right. Maybe I could just leave the channel untouched.

Untouched may not be a good idea. Leaving anything untouched always has the risk of leaking information through uninitialized memory. Maybe not in this case because the destination is allocated by userspace already, but nothing beats being obviously correct.

Makes sense.

Whatever you decide here, be prepared for it becoming de-facto kernel UABI, because it is easy for userspace to (accidentally) rely on the value, no matter what you pick.

I hope to make the right decision then.

Thanks, pq

...

...

...

...

• dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257);
  

• dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257);
  

• dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257);
  

• }

+}

+plane_format_transform_func get_plane_fmt_transform_function(u32 format) +{

• if (format == DRM_FORMAT_ARGB8888)

• return &ARGB8888_to_argb_u16;
  

• else if (format == DRM_FORMAT_XRGB8888)

• return &XRGB8888_to_argb_u16;
  

• else

• return NULL;
  

This works for now, but when more formats are added, I'd think a switch statement would look better.

ok.

...

...

+}

+wb_format_transform_func get_wb_fmt_transform_function(u32 format) +{

• if (format == DRM_FORMAT_ARGB8888)

• return &argb_u16_to_ARGB8888;
  

• else if (format == DRM_FORMAT_XRGB8888)

• return &argb_u16_to_XRGB8888;
  

• else

• return NULL;
  

+}

On April 26, 2022 10:03:09 PM GMT-03:00, Igor Torrente igormtorrente@gmail.com wrote:

On 4/25/22 22:54, Igor Torrente wrote:

...

Hi Pekka,

On 4/25/22 05:10, Pekka Paalanen wrote:

...

On Sat, 23 Apr 2022 15:53:20 -0300 Igor Torrente igormtorrente@gmail.com wrote:

...

I forgot to respond some points from your review.

On 4/23/22 13:04, Igor Torrente wrote:

...

Hi Pekka,

On 4/20/22 09:36, Pekka Paalanen wrote:

...

On Mon, 4 Apr 2022 17:45:12 -0300 Igor Torrente igormtorrente@gmail.com wrote:

> Currently the blend function only accepts XRGB_8888 and ARGB_8888 > as a color input. > > This patch refactors all the functions related to the plane composition > to overcome this limitation. > > A new internal format(`struct pixel`) is introduced to deal with all

Hi,

struct pixel_argb_u16 was added in the previous patch.

I will fix it. Thanks!

...

...

...

...

> +static int compose_active_planes(struct vkms_writeback_job *active_wb, > + struct vkms_crtc_state *crtc_state, > + u32 *crc32) > { > + int line_width, ret = 0, pixel_size = sizeof(struct pixel_argb_u16); > + struct vkms_frame_info *primary_plane_info = NULL; > + struct line_buffer output_buffer, stage_buffer; > + struct vkms_plane_state *act_plane = NULL; > + u32 wb_format; > + if (WARN_ON(pixel_size != 8))

Isn't there a compile-time assert macro for this? Having to actually run VKMS to check for this reduces the chances of finding it early. What's the reason for this check anyway?

Yes, it exists.

include/linux/build_bug.h:1:#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)

I didn't add it because I can imagine some people very mad if the kernel did not compile because of vkms.

But that would mean that VKMS is broken on those platforms. You'd better know which platforms VKMS is broken, so the Kconfig can stop VKMS from being built there at all. Or better, fix it before anyone needs VKMS there.

Right. Makes sense. I will add it then.

...

...

This check exists so we can call `crc32_le` for the entire line instead doing it for each channel of each pixel in case `struct `pixel_argb_u16` had any gap added by the compiler between the struct fields.

Oh the CRC computation. Good point.

Can you add a comment about that with the check?

Yeah, np.

I will copy the explanation above :)

...

...

...

...

> + return -EINVAL; > + > + if (crtc_state->num_active_planes >= 1) { > + act_plane = crtc_state->active_planes[0]; > + if (act_plane->base.base.plane->type == DRM_PLANE_TYPE_PRIMARY) > + primary_plane_info = act_plane->frame_info;

After the next patch, do you even need the primary plane for anything specifically?

Yeah, I will not need it anymore.

...

...

There is the map_is_null check below, but that should be done on all planes in the array, right?

Yes, I guess so. And I don't know why it only checks for the primary_plane TBH.

Maybe a left-over from times when it didn't have anything but a primary plane?

Maybe.

Anyway, I have added this verification to all active planes in the next version.

...

...

...

...

I suspect the next patch, or another patch in this series, should just delete this chunk.

I should, and I will in the V6 of next patch.

...

...

> } > + if (!primary_plane_info) > + return -EINVAL; > + > if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) > return -EINVAL; > + if (WARN_ON(check_format_funcs(crtc_state, active_wb))) > + return -EINVAL; > + line_width = drm_rect_width(&primary_plane_info->dst); > + stage_buffer.n_pixels = line_width; > + output_buffer.n_pixels = line_width; > + stage_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL); > + if (!stage_buffer.pixels) { > + DRM_ERROR("Cannot allocate memory for the output line buffer"); > + return -ENOMEM; > + } > + output_buffer.pixels = kvmalloc(line_width * pixel_size, GFP_KERNEL); > + if (!output_buffer.pixels) { > + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); > + ret = -ENOMEM; > + goto free_stage_buffer; > + } > + > + if (active_wb) { > + struct vkms_frame_info *wb_frame_info = &active_wb->frame_info; > + > + wb_format = wb_frame_info->fb->format->format;

I don't see wb_format being used, is it?

This is probably a leftover from the last versions. Thanks for catching it.

...

> + wb_frame_info->src = primary_plane_info->src; > + wb_frame_info->dst = primary_plane_info->dst; > + } > + > + blend(active_wb, crtc_state, crc32, &stage_buffer, > + &output_buffer, (s64)line_width * pixel_size);

What's the (s64) doing here?

Are byte sizes not usually expressed with size_t or ssize_t types, or is the kernel convention to use u64 and s64?

This makes me suspect that pixel_offset() and friends in vkms_format.c are going to need fixing as well. int type overflows at 2G.

Yeah, I should be using size_t in all these places.

...

> + > + kvfree(output_buffer.pixels); > +free_stage_buffer: > + kvfree(stage_buffer.pixels); > +can > + return ret; > } > /** > @@ -222,13 +204,11 @@ void vkms_composer_worker(struct work_struct *work) > struct vkms_crtc_state, > composer_work); > struct drm_crtc *crtc = crtc_state->base.crtc; > + struct vkms_writeback_job *active_wb = crtc_state->active_writeback; > struct vkms_output *out = drm_crtc_to_vkms_output(crtc); > bool crc_pending, wb_pending; > u64 frame_start, frame_end; > + u32 crc32 = 0; > int ret; > spin_lock_irq(&out->composer_lock); > @@ -248,35 +228,19 @@ void vkms_composer_worker(struct work_struct *work) > if (!crc_pending) > return; > if (wb_pending) > + ret = compose_active_planes(active_wb, crtc_state, &crc32); > + else > + ret = compose_active_planes(NULL, crtc_state, &crc32); > + if (ret) > return; > if (wb_pending) { > drm_writeback_signal_completion(&out->wb_connector, 0); > spin_lock_irq(&out->composer_lock); > crtc_state->wb_pending = false; > spin_unlock_irq(&out->composer_lock); > } > /* > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c > new file mode 100644 > index 000000000000..931a61405d6a > --- /dev/null > +++ b/drivers/gpu/drm/vkms/vkms_formats.c > @@ -0,0 +1,151 @@ > +// SPDX-License-Identifier: GPL-2.0+ > + > +#include <drm/drm_rect.h> > +#include <linux/minmax.h> > + > +#include "vkms_formats.h" > + > +static int pixel_offset(const struct vkms_frame_info *frame_info, int x, int y) > +{ > + return frame_info->offset + (y * frame_info->pitch) > + + (x * frame_info->cpp); > +} > + > +/* > + * packed_pixels_addr - Get the pointer to pixel of a given pair of coordinates > + * > + * @frame_info: Buffer metadata > + * @x: The x(width) coordinate of the 2D buffer > + * @y: The y(Heigth) coordinate of the 2D buffercan > + * > + * 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). > + */ > +static void *packed_pixels_addr(const struct vkms_frame_info *frame_info, > + int x, int y) > +{ > + int offset = pixel_offset(frame_info, x, y); > + > + return (u8 *)frame_info->map[0].vaddr + offset; > +} > + > +static void *get_packed_src_addr(const struct vkms_frame_info *frame_info, int y) > +{ > + int x_src = frame_info->src.x1 >> 16; > + int y_src = y - frame_info->dst.y1 + (frame_info->src.y1 >> 16); > + > + return packed_pixels_addr(frame_info, x_src, y_src); > +} > + > +static void ARGB8888_to_argb_u16(struct line_buffer *stage_buffer, > + const struct vkms_frame_info *frame_info, int y) > +{ > + struct pixel_argb_u16 *out_pixels = stage_buffer->pixels; > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > + int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst), > + stage_buffer->n_pixels); > + > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > + /* > + * The 257 is the "conversion ratio". This number is obtained by the > + * (2^16 - 1) / (2^8 - 1) division. Which, in this case, tries to get > + * the best color value in a pixel format with more possibilities. > + * A similar idea applies to others RGB color conversions. > + */ > + out_pixels[x].a = (u16)src_pixels[3] * 257; > + out_pixels[x].r = (u16)src_pixels[2] * 257; > + out_pixels[x].g = (u16)src_pixels[1] * 257; > + out_pixels[x].b = (u16)src_pixels[0] * 257; > + } > +} > + > +static void XRGB8888_to_argb_u16(struct line_buffer *stage_buffer, > + const struct vkms_frame_info *frame_info, int y) > +{ > + struct pixel_argb_u16 *out_pixels = stage_buffer->pixels; > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > + int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst), > + stage_buffer->n_pixels); > + > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > + out_pixels[x].a = (u16)0xffff; > + out_pixels[x].r = (u16)src_pixels[2] * 257; > + out_pixels[x].g = (u16)src_pixels[1] * 257; > + out_pixels[x].b = (u16)src_pixels[0] * 257; > + } > +} > + > +/* > + * 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. > + * > + * They are used in the `compose_active_planes` to convert and store a line > + * from the src_buffer to the writeback buffer. > + */ > +static void argb_u16_to_ARGB8888(struct vkms_frame_info *frame_info, > + const struct line_buffer *src_buffer, int y) > +{ > + int x, x_dst = frame_info->dst.x1; > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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); > + > + for (x = 0; x < x_limit; x++, dst_pixels += 4) { > + /* > + * This sequence below is important because the format's byte order is > + * in little-endian. In the case of the ARGB8888 the memory is > + * organized this way: > + * > + * | Addr | = blue channel > + * | Addr + 1 | = green channel > + * | Addr + 2 | = Red channel > + * | Addr + 3 | = Alpha channel > + */ > + dst_pixels[3] = DIV_ROUND_CLOSEST(in_pixels[x].a, 257); > + dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257); > + dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257); > + dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257); > + } > +} > + > +static void argb_u16_to_XRGB8888(struct vkms_frame_info *frame_info, > + const struct line_buffer *src_buffer, int y) > +{ > + int x, x_dst = frame_info->dst.x1; > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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); > + > + for (x = 0; x < x_limit; x++, dst_pixels += 4) { > + dst_pixels[3] = (u8)0xff;

When writing to XRGB, it's not necessary to ensure the X channel has any sensible value. Anyone reading from XRGB must ignore that value anyway. So why not write something wacky here, like 0xa1, that is far enough from both 0x00 or 0xff to not be confused with them even visually? Also not 0x7f or 0x80 which are close to half of 0xff.

Or, you could save a whole function and just use argb_u16_to_ARGBxxxx() instead, even for XRGB destination.

Right. Maybe I could just leave the channel untouched.

Untouched may not be a good idea. Leaving anything untouched always has the risk of leaking information through uninitialized memory. Maybe not in this case because the destination is allocated by userspace already, but nothing beats being obviously correct.

Makes sense.

...

Whatever you decide here, be prepared for it becoming de-facto kernel UABI, because it is easy for userspace to (accidentally) rely on the value, no matter what you pick.

I hope to make the right decision then.

The de-facto UABI seems to be already in place for {A, X}RGB8888.

"Only XRGB_8888

I changed from 0xff to 0xbe and the `writeback-check-output` started to fail.

...

...

Thanks, pq

...

...

...

> + dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixels[x].r, 257); > + dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixels[x].g, 257); > + dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixels[x].b, 257); > + } > +} > + > +plane_format_transform_func get_plane_fmt_transform_function(u32 format) > +{ > + if (format == DRM_FORMAT_ARGB8888) > + return &ARGB8888_to_argb_u16; > + else if (format == DRM_FORMAT_XRGB8888) > + return &XRGB8888_to_argb_u16; > + else > + return NULL;

This works for now, but when more formats are added, I'd think a switch statement would look better.

ok.

...

> +} > + > +wb_format_transform_func get_wb_fmt_transform_function(u32 format) > +{ > + if (format == DRM_FORMAT_ARGB8888) > + return &argb_u16_to_ARGB8888; > + else if (format == DRM_FORMAT_XRGB8888) > + return &argb_u16_to_XRGB8888; > + else > + return NULL; > +}

Hi Pekka,

On 4/20/22 10:13, Pekka Paalanen wrote:

On Mon, 4 Apr 2022 17:45:13 -0300 Igor Torrente igormtorrente@gmail.com wrote:

...

We will break the current assumption that the primary plane has the

Hi,

I'd say "remove" rather than "break". Breaking sounds bad but this is good. :-)

Yeah, sure. :)

...

same size and position as CRTC.

...and that the primary plane is the bottom-most in zpos order, or is even enabled. At least as far as the blending machinery is concerned.

...

For that we will add CRTC dimension information to `vkms_crtc_state` and add a opaque black backgound color.

Because now we need to fill the background, we had a loss in performance with this change. Results running the IGT[1] test `igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:

| Frametime | |:--------------------------------------------:| | Implementation | Previous | This commit | |:---------------:|:---------:|:--------------:| | frametime range | 5~18 ms | 10~22 ms | | Average | 8.47 ms | 12.32 ms |

[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4

Signed-off-by: Igor Torrente igormtorrente@gmail.com

Documentation/gpu/vkms.rst | 3 +-- drivers/gpu/drm/vkms/vkms_composer.c | 32 +++++++++++++++++++--------- drivers/gpu/drm/vkms/vkms_crtc.c | 4 ++++ drivers/gpu/drm/vkms/vkms_drv.h | 2 ++ 4 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index a49e4ae92653..49db221c0f52 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -121,8 +121,7 @@ There's lots of plane features we could add support for:

• ARGB format on primary plane: blend the primary plane into background with translucent alpha.

-- Support when the primary plane isn't exactly matching the output size: blend

• the primary plane into the black background.

+- Add background color KMS property[Good to get started].

• Full alpha blending on all planes.

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index cf24015bf90f..f80842227669 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -61,6 +61,15 @@ static bool check_y_limit(struct vkms_frame_info *frame_info, int y) return false; }

+static void fill_background(struct pixel_argb_u16 *backgroud_color,

Hi,

this could be const struct pixel_argb_u16 *. Also a typo: missing n in backgroud_color.

Oops.

...

• 	    struct line_buffer *output_buffer)
  

+{

• int i;
• for (i = 0; i < output_buffer->n_pixels; i++)

• output_buffer->pixels[i] = *backgroud_color;
  

+}

• /**
  • @wb_frame_info: The writeback frame buffer metadata
  • @crtc_state: The crtc state

@@ -78,22 +87,23 @@ static void blend(struct vkms_writeback_job *wb, struct line_buffer *output_buffer, s64 row_size) { struct vkms_plane_state **plane = crtc_state->active_planes;

• struct vkms_frame_info *primary_plane_info = plane[0]->frame_info; u32 n_active_planes = crtc_state->num_active_planes;

• int y_dst = primary_plane_info->dst.y1;

• int h_dst = drm_rect_height(&primary_plane_info->dst);

• int y_limit = y_dst + h_dst;

• struct pixel_argb_u16 background_color = (struct pixel_argb_u16) {

• .a = 0xffff
  

• };

Could be const and shorter, if that fits the kernel style:

const struct pixel_arb_u16 background_color = { .a = 0xffff };

It fits.

...

• int crtc_y_limit = crtc_state->crtc_height; int y, i;

• for (y = y_dst; y < y_limit; y++) {

• plane[0]->format_func(output_buffer, primary_plane_info, y);
  

• for (y = 0; y < crtc_y_limit; y++) {

• fill_background(&background_color, output_buffer);
  
  

  /* If there are other planes besides primary, we consider the active

  • planes should be in z-order and compose them associatively:

Is "associatively" the right word here?

...

 * ((primary <- overlay) <- cursor)

The example (primary <- overlay) is not generally true with real hardware.

Maybe what you are trying to say is: The active planes are composed in z-order.

I always forgot to update these comments. Thanks!

...

 */

• for (i = 1; i < n_active_planes; i++) {
  

• for (i = 0; i < n_active_planes; i++) {
  if (!check_y_limit(plane[i]->frame_info, y))
  	continue;
  
  

@@ -154,7 +164,7 @@ static int compose_active_planes(struct vkms_writeback_job *active_wb,

As I mentioned on the previous patch, I think the finding of primary plane (which was generally incorrect) should be removed here.

I will remove this.

...

if (WARN_ON(check_format_funcs(crtc_state, active_wb))) return -EINVAL;

• line_width = drm_rect_width(&primary_plane_info->dst);

• line_width = crtc_state->crtc_width; stage_buffer.n_pixels = line_width; output_buffer.n_pixels = line_width;

@@ -175,8 +185,10 @@ static int compose_active_planes(struct vkms_writeback_job *active_wb, struct vkms_frame_info *wb_frame_info = &active_wb->frame_info;

wb_format = wb_frame_info->fb->format->format;

• wb_frame_info->src = primary_plane_info->src;
  

• wb_frame_info->dst = primary_plane_info->dst;
  

• drm_rect_init(&wb_frame_info->src, 0, 0, crtc_state->crtc_width,
  

• 	      crtc_state->crtc_height);
  

• drm_rect_init(&wb_frame_info->dst, 0, 0, crtc_state->crtc_width,
  

• 	      crtc_state->crtc_height);
  

Why are these not set when the active_wb->frame_info is created?

I thought that I hadn't access to the crtc at the wb creation.

After looking more carefully at the structs, I found this is not the case.

So I will improve this.

Can the CRTC (video mode) be smaller than the wb buffer?

AFAIK this is not possible.

Somewhere you must have a check that wb buffer size can fit the crtc size, or maybe they must be exactly the same size. At least setting destination rectangle bigger than the buffer dimensions must be impossible.

...

}

blend(active_wb, crtc_state, crc32, &stage_buffer, diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c index 57bbd32e9beb..4a37e243c2d7 100644 --- a/drivers/gpu/drm/vkms/vkms_crtc.c +++ b/drivers/gpu/drm/vkms/vkms_crtc.c @@ -248,7 +248,9 @@ static void vkms_crtc_atomic_begin(struct drm_crtc *crtc, static void vkms_crtc_atomic_flush(struct drm_crtc *crtc, struct drm_atomic_state *state) {

• struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc); struct vkms_output *vkms_output = drm_crtc_to_vkms_output(crtc);

• struct drm_display_mode *mode = &crtc_state->mode;

  if (crtc->state->event) { spin_lock(&crtc->dev->event_lock);

@@ -264,6 +266,8 @@ static void vkms_crtc_atomic_flush(struct drm_crtc *crtc, }

vkms_output->composer_state = to_vkms_crtc_state(crtc->state);

• vkms_output->composer_state->crtc_width = mode->hdisplay;
• vkms_output->composer_state->crtc_height = mode->vdisplay;

Is the crtc not keeping track of the current mode, do you really need your own crtc_width and crtc_height?

I don't really need it. I was just putting more easily accessible to the composer functions.

But np, I can change this.

Thanks, pq

...

spin_unlock_irq(&vkms_output->lock); } diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h index 2704cfb6904b..ab92d9f7b701 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.h +++ b/drivers/gpu/drm/vkms/vkms_drv.h @@ -90,6 +90,8 @@ struct vkms_crtc_state { bool wb_pending; u64 frame_start; u64 frame_end;

• u16 crtc_width;

• u16 crtc_height; };

  struct vkms_output {

On Mon, 4 Apr 2022 17:45:14 -0300 Igor Torrente igormtorrente@gmail.com wrote:

This will be useful to write tests that depends on these formats.

ARGB and XRGB follows the a similar implementation of the former formats. Just adjusting for 16 bits per channel.

V3: Adapt the handlers to the new format introduced in patch 7 V3. V5: Minor improvements Added le16_to_cpu/cpu_to_le16 to the 16 bits color read/writes.

Signed-off-by: Igor Torrente igormtorrente@gmail.com

drivers/gpu/drm/vkms/vkms_formats.c | 77 +++++++++++++++++++++++++++ drivers/gpu/drm/vkms/vkms_plane.c | 5 +- drivers/gpu/drm/vkms/vkms_writeback.c | 2 + 3 files changed, 83 insertions(+), 1 deletion(-)

Hi,

aside from the comments I already gave on the other patch adding the *RGB8888 variants that apply here too, this looks good to me, with or without those changes.

Reviewed-by: Pekka Paalanen pekka.paalanen@collabora.com

Thanks, pq

diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c index 931a61405d6a..8d913fa7dbde 100644 --- a/drivers/gpu/drm/vkms/vkms_formats.c +++ b/drivers/gpu/drm/vkms/vkms_formats.c @@ -78,6 +78,41 @@ static void XRGB8888_to_argb_u16(struct line_buffer *stage_buffer, } }

+static void ARGB16161616_to_argb_u16(struct line_buffer *stage_buffer,

• 		     const struct vkms_frame_info *frame_info,
  

• 		     int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u16 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• out_pixels[x].a = le16_to_cpu(src_pixels[3]);
  

• out_pixels[x].r = le16_to_cpu(src_pixels[2]);
  

• out_pixels[x].g = le16_to_cpu(src_pixels[1]);
  

• out_pixels[x].b = le16_to_cpu(src_pixels[0]);
  

• }

+}

+static void XRGB16161616_to_argb_u16(struct line_buffer *stage_buffer,

• 		     const struct vkms_frame_info *frame_info,
  

• 		     int y)
  

+{

• struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
• u16 *src_pixels = get_packed_src_addr(frame_info, y);
• int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),

• 	       stage_buffer->n_pixels);
  

• for (x = 0; x < x_limit; x++, src_pixels += 4) {

• out_pixels[x].a = (u16)0xffff;
  

• out_pixels[x].r = le16_to_cpu(src_pixels[2]);
  

• out_pixels[x].g = le16_to_cpu(src_pixels[1]);
  

• out_pixels[x].b = le16_to_cpu(src_pixels[0]);
  

• }

+}

/*

• 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

@@ -130,12 +165,50 @@ static void argb_u16_to_XRGB8888(struct vkms_frame_info *frame_info, } }

+static void argb_u16_to_ARGB16161616(struct vkms_frame_info *frame_info,

• 		     const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• dst_pixels[3] = cpu_to_le16(in_pixels[x].a);
  

• dst_pixels[2] = cpu_to_le16(in_pixels[x].r);
  

• dst_pixels[1] = cpu_to_le16(in_pixels[x].g);
  

• dst_pixels[0] = cpu_to_le16(in_pixels[x].b);
  

• }

+}

+static void argb_u16_to_XRGB16161616(struct vkms_frame_info *frame_info,

• 		     const struct line_buffer *src_buffer, int y)
  

+{

• int x, x_dst = frame_info->dst.x1;
• u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, 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);
  

• for (x = 0; x < x_limit; x++, dst_pixels += 4) {

• dst_pixels[3] = (u8)0xffff;
  

• dst_pixels[2] = cpu_to_le16(in_pixels[x].r);
  

• dst_pixels[1] = cpu_to_le16(in_pixels[x].g);
  

• dst_pixels[0] = cpu_to_le16(in_pixels[x].b);
  

• }

+}

plane_format_transform_func get_plane_fmt_transform_function(u32 format) { if (format == DRM_FORMAT_ARGB8888) return &ARGB8888_to_argb_u16; else if (format == DRM_FORMAT_XRGB8888) return &XRGB8888_to_argb_u16;

• else if (format == DRM_FORMAT_ARGB16161616)

• return &ARGB16161616_to_argb_u16;
  

• else if (format == DRM_FORMAT_XRGB16161616)

• return &XRGB16161616_to_argb_u16;
  

  else return NULL;

} @@ -146,6 +219,10 @@ wb_format_transform_func get_wb_fmt_transform_function(u32 format) return &argb_u16_to_ARGB8888; else if (format == DRM_FORMAT_XRGB8888) return &argb_u16_to_XRGB8888;

• else if (format == DRM_FORMAT_ARGB16161616)

• return &argb_u16_to_ARGB16161616;
  

• else if (format == DRM_FORMAT_XRGB16161616)

• return &argb_u16_to_XRGB16161616;
  

  else return NULL;

} diff --git a/drivers/gpu/drm/vkms/vkms_plane.c b/drivers/gpu/drm/vkms/vkms_plane.c index 798243837fd0..60054a85204a 100644 --- a/drivers/gpu/drm/vkms/vkms_plane.c +++ b/drivers/gpu/drm/vkms/vkms_plane.c @@ -14,11 +14,14 @@

static const u32 vkms_formats[] = { DRM_FORMAT_XRGB8888,

• DRM_FORMAT_XRGB16161616

};

static const u32 vkms_plane_formats[] = { DRM_FORMAT_ARGB8888,

• DRM_FORMAT_XRGB8888

• DRM_FORMAT_XRGB8888,
• DRM_FORMAT_XRGB16161616,
• DRM_FORMAT_ARGB16161616

};

static struct drm_plane_state * diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c b/drivers/gpu/drm/vkms/vkms_writeback.c index 97f71e784bbf..cb63a5da9af1 100644 --- a/drivers/gpu/drm/vkms/vkms_writeback.c +++ b/drivers/gpu/drm/vkms/vkms_writeback.c @@ -15,6 +15,8 @@

static const u32 vkms_wb_formats[] = { DRM_FORMAT_XRGB8888,

• DRM_FORMAT_XRGB16161616,
• DRM_FORMAT_ARGB16161616

};

static const struct drm_connector_funcs vkms_wb_connector_funcs = {