| Message ID | 20220121213831.47229-8-igormtorrente@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add new formats support to vkms | expand |
On 01/21, Igor Torrente 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 > 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 tests `*kms_cursor_crc*`: > First, thanks for this improvement. Some recent changes in kms_cursor_crc caused VKMS to fail in most test cases (iirc, only size-change and alpha-opaque are passing currently). But saying that performance improvement here would cause a misunderstanding when reviewing the change history. Can you update this statistics here? I think you can specify the IGT hash to specify the test case version or you can pick another test for comparison. > | Frametime | > |:------------------------------------------:| > | Implementation | Current | This commit | > |:---------------:|:---------:|:------------:| > | frametime range | 8~22 ms | 5~18 ms | > | Average | 10.0 ms | 7.3 ms | > > Reported-by: kernel test robot <lkp@intel.com> A little confusing for me to have this reported-by tag without any explanation of what was reported and fixed. Can you specify it? > Signed-off-by: Igor Torrente <igormtorrente@gmail.com> > --- > V2: Improves the performance drastically, by perfoming 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. Can you move version changes up so that they are not ignored? I also pointed out minor code style issue below. With these comments addressed, you can add my r-b tag in the next version. > --- > drivers/gpu/drm/vkms/Makefile | 1 + > drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- > drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ > drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ > 4 files changed, 333 insertions(+), 172 deletions(-) > create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c > create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h > > 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..9f70fcf84fb9 100644 > --- a/drivers/gpu/drm/vkms/vkms_composer.c > +++ b/drivers/gpu/drm/vkms/vkms_composer.c > @@ -9,202 +9,210 @@ > #include <drm/drm_vblank.h> > > #include "vkms_drv.h" > +#include "vkms_formats.h" > > -static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer, > - const struct vkms_frame_info *frame_info) > +static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha) > { > - u32 pixel; > - int src_offset = frame_info->offset + (y * frame_info->pitch) > - + (x * frame_info->cpp); > + u32 new_color; > > - pixel = *(u32 *)&buffer[src_offset]; > + new_color = (src * 0xffff + dst * (0xffff - alpha)); > > - return pixel; > + return DIV_ROUND_UP(new_color, 0xffff); > } > > /** > - * compute_crc - Compute CRC value on output frame > + * 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 > * > - * @vaddr: address to final framebuffer > - * @frame_info: framebuffer's metadata > + * 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. > * > - * returns CRC value computed using crc32 on the visible portion of > - * the final framebuffer at vaddr_out > + * 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 uint32_t compute_crc(const u8 *vaddr, > - const struct vkms_frame_info *frame_info) > +static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info, > + struct line_buffer *stage_buffer, > + struct line_buffer *output_buffer) > { > - int x, y; > - u32 crc = 0, pixel = 0; > - int x_src = frame_info->src.x1 >> 16; > - int y_src = frame_info->src.y1 >> 16; > - int h_src = drm_rect_height(&frame_info->src) >> 16; > - int w_src = drm_rect_width(&frame_info->src) >> 16; > - > - for (y = y_src; y < y_src + h_src; ++y) { > - for (x = x_src; x < x_src + w_src; ++x) { > - pixel = get_pixel_from_buffer(x, y, vaddr, frame_info); > - crc = crc32_le(crc, (void *)&pixel, sizeof(u32)); > - } > + int x, x_dst = frame_info->dst.x1; > + int x_limit = drm_rect_width(&frame_info->dst); > + struct line_buffer *out = output_buffer + x_dst; > + struct line_buffer *in = stage_buffer; > + > + 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); > } > - > - return crc; > } > > -static u8 blend_channel(u8 src, u8 dst, u8 alpha) > +static bool check_y_limit(struct vkms_frame_info *frame_info, int y) > { > - u32 pre_blend; > - u8 new_color; > - > - pre_blend = (src * 255 + dst * (255 - alpha)); > - > - /* Faster div by 255 */ > - new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8); > + if (y >= frame_info->dst.y1 && y < frame_info->dst.y2) > + return true; > > - return new_color; > + return false; > } > > /** > - * alpha_blend - alpha blending equation > - * @argb_src: src pixel on premultiplied alpha mode > - * @argb_dst: dst pixel completely opaque > - * > - * blend pixels 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 alpha_blend(const u8 *argb_src, u8 *argb_dst) > -{ > - u8 alpha; > - > - alpha = argb_src[3]; > - argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha); > - argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha); > - argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha); > -} > - > -/** > - * x_blend - blending equation that ignores the pixel alpha > - * > - * overwrites RGB color value from src pixel to dst pixel. > - */ > -static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst) > -{ > - memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3); > -} > - > -/** > - * blend - blend value at vaddr_src with value at vaddr_dst > - * @vaddr_dst: destination address > - * @vaddr_src: source address > - * @dst_frame_info: destination framebuffer's metadata > - * @src_frame_info: source framebuffer's metadata > - * @pixel_blend: blending equation based on plane format > + * @wb_frame_info: The writeback frame buffer metadata > + * @wb_fmt_func: The format tranformatio function to the wb buffer > + * @crtc_state: The crtc state > + * @plane_fmt_func: A format tranformation function to each plane > + * @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 src_compositor > * > - * Blend the vaddr_src value with the vaddr_dst value using a pixel blend > - * equation according to the supported plane formats DRM_FORMAT_(A/XRGB8888) > - * and clearing alpha channel to an completely opaque background. This function > - * uses buffer's metadata to locate the new composite values at vaddr_dst. > + * 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. > * > * TODO: completely clear the primary plane (a = 0xff) before starting to blend > * pixel color values > */ > -static void blend(void *vaddr_dst, void *vaddr_src, > - struct vkms_frame_info *dst_frame_info, > - struct vkms_frame_info *src_frame_info, > - void (*pixel_blend)(const u8 *, u8 *)) > +static void blend(struct vkms_frame_info *wb_frame_info, > + format_transform_func wb_fmt_func, > + struct vkms_crtc_state *crtc_state, > + format_transform_func *plane_fmt_func, > + u32 *crc32, struct line_buffer *stage_buffer, > + struct line_buffer *output_buffer, s64 row_size) > { > - int i, j, j_dst, i_dst; > - int offset_src, offset_dst; > - u8 *pixel_dst, *pixel_src; > - > - int x_src = src_frame_info->src.x1 >> 16; > - int y_src = src_frame_info->src.y1 >> 16; > - > - int x_dst = src_frame_info->dst.x1; > - int y_dst = src_frame_info->dst.y1; > - int h_dst = drm_rect_height(&src_frame_info->dst); > - int w_dst = drm_rect_width(&src_frame_info->dst); > + 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_src = primary_plane_info->dst.y1; > + int h_dst = drm_rect_height(&primary_plane_info->dst); > int y_limit = y_src + h_dst; > - int x_limit = x_src + w_dst; > - > - for (i = y_src, i_dst = y_dst; i < y_limit; ++i) { > - for (j = x_src, j_dst = x_dst; j < x_limit; ++j) { > - offset_dst = dst_frame_info->offset > - + (i_dst * dst_frame_info->pitch) > - + (j_dst++ * dst_frame_info->cpp); > - offset_src = src_frame_info->offset > - + (i * src_frame_info->pitch) > - + (j * src_frame_info->cpp); > - > - pixel_src = (u8 *)(vaddr_src + offset_src); > - pixel_dst = (u8 *)(vaddr_dst + offset_dst); > - pixel_blend(pixel_src, pixel_dst); > - /* clearing alpha channel (0xff)*/ > - pixel_dst[3] = 0xff; > + int y, i; > + > + for (y = y_src; y < y_limit; y++) { > + plane_fmt_func[0](primary_plane_info, y, output_buffer); > + > + /* 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_fmt_func[i](plane[i]->frame_info, y, stage_buffer); > + pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer, > + output_buffer); > } > - i_dst++; > + > + *crc32 = crc32_le(*crc32, (void *)output_buffer, row_size); > + > + if (wb_frame_info) > + wb_fmt_func(wb_frame_info, y, output_buffer); > } > } > > -static void compose_plane(struct vkms_frame_info *primary_plane_info, > - struct vkms_frame_info *plane_frame_info, > - void *vaddr_out) > +static void get_format_transform_functions(struct vkms_crtc_state *crtc_state, > + format_transform_func plane_funcs[]) > { > - struct drm_framebuffer *fb = plane_frame_info->fb; > - void *vaddr; > - void (*pixel_blend)(const u8 *p_src, u8 *p_dst); > + struct vkms_plane_state **active_planes = crtc_state->active_planes; > + u32 n_active_planes = crtc_state->num_active_planes, s_fmt; > + int i; > > - if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) > - return; > + for (i = 0; i < n_active_planes; i++) { > + s_fmt = active_planes[i]->frame_info->fb->format->format; > + plane_funcs[i] = get_fmt_transform_function(s_fmt); > + } > +} > > - vaddr = plane_frame_info->map[0].vaddr; > +static bool check_planes_x_bounds(struct vkms_crtc_state *crtc_state, > + struct vkms_frame_info *wb_frame_info) > +{ > + struct vkms_plane_state **planes = crtc_state->active_planes; > + struct vkms_frame_info *primary_plane_info = planes[0]->frame_info; > + int line_width = drm_rect_width(&primary_plane_info->dst); > + u32 n_active_planes = crtc_state->num_active_planes; > + int i; > > - if (fb->format->format == DRM_FORMAT_ARGB8888) > - pixel_blend = &alpha_blend; > - else > - pixel_blend = &x_blend; > + for (i = 0; i < n_active_planes; i++) { > + int x_dst = planes[i]->frame_info->dst.x1; > + int x_src = planes[i]->frame_info->src.x1 >> 16; > + int x2_src = planes[i]->frame_info->src.x2 >> 16; > + int x_limit = drm_rect_width(&planes[i]->frame_info->dst); > > - blend(vaddr_out, vaddr, primary_plane_info, > - plane_frame_info, pixel_blend); > + if (x_dst + x_limit > line_width) > + return false; > + if (x_src + x_limit > x2_src) > + return false; > + } > + > + return true; > } > > -static int compose_active_planes(void **vaddr_out, > - struct vkms_frame_info *primary_plane_info, > - struct vkms_crtc_state *crtc_state) > +static int compose_active_planes(struct vkms_frame_info *wb_frame_info, > + struct vkms_crtc_state *crtc_state, > + u32 *crc32) > { > - 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; > + format_transform_func plane_funcs[NUM_OVERLAY_PLANES], wb_func = NULL; > + int line_width, ret = 0, pixel_size = sizeof(struct line_buffer); > + 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 (!*vaddr_out) { > - *vaddr_out = kvzalloc(gem_obj->size, GFP_KERNEL); > - if (!*vaddr_out) { > - DRM_ERROR("Cannot allocate memory for output frame."); > - return -ENOMEM; > - } > + if (WARN_ON(pixel_size != 8)) > + 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; > } > > + if (!primary_plane_info) > + return -EINVAL; > + > if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) > return -EINVAL; > > - vaddr = primary_plane_info->map[0].vaddr; > + if (WARN_ON(!check_planes_x_bounds(crtc_state, wb_frame_info))) > + return -EINVAL; > > - memcpy(*vaddr_out, vaddr, gem_obj->size); > + line_width = drm_rect_width(&primary_plane_info->dst); > > - /* 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 < crtc_state->num_active_planes; i++) > - compose_plane(primary_plane_info, > - crtc_state->active_planes[i]->frame_info, > - *vaddr_out); > + stage_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); > + if (!stage_buffer) { > + DRM_ERROR("Cannot allocate memory for the output line buffer"); > + return -ENOMEM; > + } > > - return 0; > + output_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); > + if (!output_buffer) { > + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); > + ret = -ENOMEM; > + goto free_stage_buffer; > + } > + > + get_format_transform_functions(crtc_state, plane_funcs); > + > + if (wb_frame_info) { > + wb_format = wb_frame_info->fb->format->format; > + wb_func = get_wb_fmt_transform_function(wb_format); > + wb_frame_info->src = primary_plane_info->src; > + wb_frame_info->dst = primary_plane_info->dst; > + } > + > + blend(wb_frame_info, wb_func, crtc_state, plane_funcs, crc32, > + stage_buffer, output_buffer, (s64)line_width * pixel_size); > + > + kvfree(output_buffer); > +free_stage_buffer: > + kvfree(stage_buffer); > + > + return ret; > } > > /** > @@ -222,13 +230,12 @@ 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_frame_info *wb_frame_info = &active_wb->frame_info; > struct vkms_output *out = drm_crtc_to_vkms_output(crtc); > - struct vkms_frame_info *primary_plane_info = NULL; > - struct vkms_plane_state *act_plane = NULL; > bool crc_pending, wb_pending; > - void *vaddr_out = NULL; > - u32 crc32 = 0; > u64 frame_start, frame_end; > + u32 crc32 = 0; > int ret; > > spin_lock_irq(&out->composer_lock); > @@ -248,35 +255,19 @@ void vkms_composer_worker(struct work_struct *work) > if (!crc_pending) > return; > > - 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; > - } > - > - if (!primary_plane_info) > - return; > - > if (wb_pending) > - vaddr_out = crtc_state->active_writeback->data[0].vaddr; > + ret = compose_active_planes(wb_frame_info, crtc_state, &crc32); > + else > + ret = compose_active_planes(NULL, crtc_state, &crc32); > > - ret = compose_active_planes(&vaddr_out, primary_plane_info, > - crtc_state); > - if (ret) { > - if (ret == -EINVAL && !wb_pending) > - kvfree(vaddr_out); > + if (ret) > return; > - } > - > - crc32 = compute_crc(vaddr_out, primary_plane_info); > > 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); > - } else { > - kvfree(vaddr_out); > } > > /* > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c > new file mode 100644 > index 000000000000..0d1838d1b835 > --- /dev/null > +++ b/drivers/gpu/drm/vkms/vkms_formats.c > @@ -0,0 +1,138 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ checkpatch complains here ^ Use `\\` > + > +#include <drm/drm_rect.h> > +#include "vkms_formats.h" > + > +format_transform_func get_fmt_transform_function(u32 format) > +{ > + if (format == DRM_FORMAT_ARGB8888) > + return &ARGB8888_to_ARGB16161616; > + else > + return &XRGB8888_to_ARGB16161616; > +} > + > +format_transform_func get_wb_fmt_transform_function(u32 format) > +{ > + if (format == DRM_FORMAT_ARGB8888) > + return &convert_to_ARGB8888; > + else > + return &convert_to_XRGB8888; > +} > + > +static int pixel_offset(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(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(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); > +} > + > +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer) > +{ > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > + int x, x_limit = drm_rect_width(&frame_info->dst); > + > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > + /* > + * Organizes the channels in their respective positions and converts > + * the 8 bits channel to 16. > + * 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. > + * And a similar idea applies to others RGB color conversions. > + */ > + stage_buffer[x].a = (u16)src_pixels[3] * 257; > + stage_buffer[x].r = (u16)src_pixels[2] * 257; > + stage_buffer[x].g = (u16)src_pixels[1] * 257; > + stage_buffer[x].b = (u16)src_pixels[0] * 257; > + } > +} > + > +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer) > +{ > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > + int x, x_limit = drm_rect_width(&frame_info->dst); > + > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > + stage_buffer[x].a = (u16)0xffff; > + stage_buffer[x].r = (u16)src_pixels[2] * 257; > + stage_buffer[x].g = (u16)src_pixels[1] * 257; > + stage_buffer[x].b = (u16)src_pixels[0] * 257; > + } > +} > + > +/* > + * The following functions take an line of ARGB16161616 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. > + */ > +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, > + int y, struct line_buffer *src_buffer) > +{ > + int x, x_dst = frame_info->dst.x1; > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); > + int x_limit = drm_rect_width(&frame_info->dst); > + > + 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_UP(src_buffer[x].a, 257); > + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); > + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); > + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); > + } > +} > + > +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, > + int y, struct line_buffer *src_buffer) > +{ > + int x, x_dst = frame_info->dst.x1; > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); > + int x_limit = drm_rect_width(&frame_info->dst); > + > + for (x = 0; x < x_limit; x++, dst_pixels += 4) { > + dst_pixels[3] = (u8)0xff; > + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); > + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); > + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); > + } > +} > diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h > new file mode 100644 > index 000000000000..817e8b2124ae > --- /dev/null > +++ b/drivers/gpu/drm/vkms/vkms_formats.h > @@ -0,0 +1,31 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ and here ^ > + > +#ifndef _VKMS_FORMATS_H_ > +#define _VKMS_FORMATS_H_ > + > +#include "vkms_drv.h" > + > +struct line_buffer { > + u16 a, r, g, b; > +}; > + > +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer); > + > +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer); > + > +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *src_buffer); > + > +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *src_buffer); > + > +typedef void (*format_transform_func)(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *buffer); > + > +format_transform_func get_fmt_transform_function(u32 format); > + > +format_transform_func get_wb_fmt_transform_function(u32 format); > + > +#endif /* _VKMS_FORMATS_H_ */ > -- > 2.30.2 >
Hi Melissa, On 2/8/22 07:40, Melissa Wen wrote: > On 01/21, Igor Torrente 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 >> 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 tests `*kms_cursor_crc*`: >> > First, thanks for this improvement. > > Some recent changes in kms_cursor_crc caused VKMS to fail in most test > cases (iirc, only size-change and alpha-opaque are passing currently). I updated my igt and kernel(from drm_misc/drm-misc-next) to the latest commit[1][2] and I'm getting mixed results. Sometimes most of the test passes, sometimes almost nothing passes. [1] a96674e7 (tests/api_intel_bb: Handle different alignments in delta-check) [2] b21a142fd205 (drm/nouveau/backlight: Just set all backlight types as RAW) > But saying that performance improvement here would cause a > misunderstanding when reviewing the change history. Can you update this > statistics here? I think you can specify the IGT hash to specify the > test case version or you can pick another test for comparison. OK, I will do both. >> | Frametime | >> |:------------------------------------------:| >> | Implementation | Current | This commit | >> |:---------------:|:---------:|:------------:| >> | frametime range | 8~22 ms | 5~18 ms | >> | Average | 10.0 ms | 7.3 ms | >> >> Reported-by: kernel test robot <lkp@intel.com> > A little confusing for me to have this reported-by tag without any > explanation of what was reported and fixed. Can you specify it? >> Signed-off-by: Igor Torrente <igormtorrente@gmail.com> >> --- >> V2: Improves the performance drastically, by perfoming 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. > Can you move version changes up so that they are not ignored? > > I also pointed out minor code style issue below. > With these comments addressed, you can add my r-b tag in the next > version. >> --- >> drivers/gpu/drm/vkms/Makefile | 1 + >> drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- >> drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ >> drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ >> 4 files changed, 333 insertions(+), 172 deletions(-) >> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c >> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h >> >> 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..9f70fcf84fb9 100644 >> --- a/drivers/gpu/drm/vkms/vkms_composer.c >> +++ b/drivers/gpu/drm/vkms/vkms_composer.c >> @@ -9,202 +9,210 @@ >> #include <drm/drm_vblank.h> >> >> #include "vkms_drv.h" >> +#include "vkms_formats.h" >> >> -static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer, >> - const struct vkms_frame_info *frame_info) >> +static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha) >> { >> - u32 pixel; >> - int src_offset = frame_info->offset + (y * frame_info->pitch) >> - + (x * frame_info->cpp); >> + u32 new_color; >> >> - pixel = *(u32 *)&buffer[src_offset]; >> + new_color = (src * 0xffff + dst * (0xffff - alpha)); >> >> - return pixel; >> + return DIV_ROUND_UP(new_color, 0xffff); >> } >> >> /** >> - * compute_crc - Compute CRC value on output frame >> + * 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 >> * >> - * @vaddr: address to final framebuffer >> - * @frame_info: framebuffer's metadata >> + * 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. >> * >> - * returns CRC value computed using crc32 on the visible portion of >> - * the final framebuffer at vaddr_out >> + * 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 uint32_t compute_crc(const u8 *vaddr, >> - const struct vkms_frame_info *frame_info) >> +static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info, >> + struct line_buffer *stage_buffer, >> + struct line_buffer *output_buffer) >> { >> - int x, y; >> - u32 crc = 0, pixel = 0; >> - int x_src = frame_info->src.x1 >> 16; >> - int y_src = frame_info->src.y1 >> 16; >> - int h_src = drm_rect_height(&frame_info->src) >> 16; >> - int w_src = drm_rect_width(&frame_info->src) >> 16; >> - >> - for (y = y_src; y < y_src + h_src; ++y) { >> - for (x = x_src; x < x_src + w_src; ++x) { >> - pixel = get_pixel_from_buffer(x, y, vaddr, frame_info); >> - crc = crc32_le(crc, (void *)&pixel, sizeof(u32)); >> - } >> + int x, x_dst = frame_info->dst.x1; >> + int x_limit = drm_rect_width(&frame_info->dst); >> + struct line_buffer *out = output_buffer + x_dst; >> + struct line_buffer *in = stage_buffer; >> + >> + 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); >> } >> - >> - return crc; >> } >> >> -static u8 blend_channel(u8 src, u8 dst, u8 alpha) >> +static bool check_y_limit(struct vkms_frame_info *frame_info, int y) >> { >> - u32 pre_blend; >> - u8 new_color; >> - >> - pre_blend = (src * 255 + dst * (255 - alpha)); >> - >> - /* Faster div by 255 */ >> - new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8); >> + if (y >= frame_info->dst.y1 && y < frame_info->dst.y2) >> + return true; >> >> - return new_color; >> + return false; >> } >> >> /** >> - * alpha_blend - alpha blending equation >> - * @argb_src: src pixel on premultiplied alpha mode >> - * @argb_dst: dst pixel completely opaque >> - * >> - * blend pixels 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 alpha_blend(const u8 *argb_src, u8 *argb_dst) >> -{ >> - u8 alpha; >> - >> - alpha = argb_src[3]; >> - argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha); >> - argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha); >> - argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha); >> -} >> - >> -/** >> - * x_blend - blending equation that ignores the pixel alpha >> - * >> - * overwrites RGB color value from src pixel to dst pixel. >> - */ >> -static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst) >> -{ >> - memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3); >> -} >> - >> -/** >> - * blend - blend value at vaddr_src with value at vaddr_dst >> - * @vaddr_dst: destination address >> - * @vaddr_src: source address >> - * @dst_frame_info: destination framebuffer's metadata >> - * @src_frame_info: source framebuffer's metadata >> - * @pixel_blend: blending equation based on plane format >> + * @wb_frame_info: The writeback frame buffer metadata >> + * @wb_fmt_func: The format tranformatio function to the wb buffer >> + * @crtc_state: The crtc state >> + * @plane_fmt_func: A format tranformation function to each plane >> + * @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 src_compositor >> * >> - * Blend the vaddr_src value with the vaddr_dst value using a pixel blend >> - * equation according to the supported plane formats DRM_FORMAT_(A/XRGB8888) >> - * and clearing alpha channel to an completely opaque background. This function >> - * uses buffer's metadata to locate the new composite values at vaddr_dst. >> + * 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. >> * >> * TODO: completely clear the primary plane (a = 0xff) before starting to blend >> * pixel color values >> */ >> -static void blend(void *vaddr_dst, void *vaddr_src, >> - struct vkms_frame_info *dst_frame_info, >> - struct vkms_frame_info *src_frame_info, >> - void (*pixel_blend)(const u8 *, u8 *)) >> +static void blend(struct vkms_frame_info *wb_frame_info, >> + format_transform_func wb_fmt_func, >> + struct vkms_crtc_state *crtc_state, >> + format_transform_func *plane_fmt_func, >> + u32 *crc32, struct line_buffer *stage_buffer, >> + struct line_buffer *output_buffer, s64 row_size) >> { >> - int i, j, j_dst, i_dst; >> - int offset_src, offset_dst; >> - u8 *pixel_dst, *pixel_src; >> - >> - int x_src = src_frame_info->src.x1 >> 16; >> - int y_src = src_frame_info->src.y1 >> 16; >> - >> - int x_dst = src_frame_info->dst.x1; >> - int y_dst = src_frame_info->dst.y1; >> - int h_dst = drm_rect_height(&src_frame_info->dst); >> - int w_dst = drm_rect_width(&src_frame_info->dst); >> + 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_src = primary_plane_info->dst.y1; >> + int h_dst = drm_rect_height(&primary_plane_info->dst); >> int y_limit = y_src + h_dst; >> - int x_limit = x_src + w_dst; >> - >> - for (i = y_src, i_dst = y_dst; i < y_limit; ++i) { >> - for (j = x_src, j_dst = x_dst; j < x_limit; ++j) { >> - offset_dst = dst_frame_info->offset >> - + (i_dst * dst_frame_info->pitch) >> - + (j_dst++ * dst_frame_info->cpp); >> - offset_src = src_frame_info->offset >> - + (i * src_frame_info->pitch) >> - + (j * src_frame_info->cpp); >> - >> - pixel_src = (u8 *)(vaddr_src + offset_src); >> - pixel_dst = (u8 *)(vaddr_dst + offset_dst); >> - pixel_blend(pixel_src, pixel_dst); >> - /* clearing alpha channel (0xff)*/ >> - pixel_dst[3] = 0xff; >> + int y, i; >> + >> + for (y = y_src; y < y_limit; y++) { >> + plane_fmt_func[0](primary_plane_info, y, output_buffer); >> + >> + /* 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_fmt_func[i](plane[i]->frame_info, y, stage_buffer); >> + pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer, >> + output_buffer); >> } >> - i_dst++; >> + >> + *crc32 = crc32_le(*crc32, (void *)output_buffer, row_size); >> + >> + if (wb_frame_info) >> + wb_fmt_func(wb_frame_info, y, output_buffer); >> } >> } >> >> -static void compose_plane(struct vkms_frame_info *primary_plane_info, >> - struct vkms_frame_info *plane_frame_info, >> - void *vaddr_out) >> +static void get_format_transform_functions(struct vkms_crtc_state *crtc_state, >> + format_transform_func plane_funcs[]) >> { >> - struct drm_framebuffer *fb = plane_frame_info->fb; >> - void *vaddr; >> - void (*pixel_blend)(const u8 *p_src, u8 *p_dst); >> + struct vkms_plane_state **active_planes = crtc_state->active_planes; >> + u32 n_active_planes = crtc_state->num_active_planes, s_fmt; >> + int i; >> >> - if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) >> - return; >> + for (i = 0; i < n_active_planes; i++) { >> + s_fmt = active_planes[i]->frame_info->fb->format->format; >> + plane_funcs[i] = get_fmt_transform_function(s_fmt); >> + } >> +} >> >> - vaddr = plane_frame_info->map[0].vaddr; >> +static bool check_planes_x_bounds(struct vkms_crtc_state *crtc_state, >> + struct vkms_frame_info *wb_frame_info) >> +{ >> + struct vkms_plane_state **planes = crtc_state->active_planes; >> + struct vkms_frame_info *primary_plane_info = planes[0]->frame_info; >> + int line_width = drm_rect_width(&primary_plane_info->dst); >> + u32 n_active_planes = crtc_state->num_active_planes; >> + int i; >> >> - if (fb->format->format == DRM_FORMAT_ARGB8888) >> - pixel_blend = &alpha_blend; >> - else >> - pixel_blend = &x_blend; >> + for (i = 0; i < n_active_planes; i++) { >> + int x_dst = planes[i]->frame_info->dst.x1; >> + int x_src = planes[i]->frame_info->src.x1 >> 16; >> + int x2_src = planes[i]->frame_info->src.x2 >> 16; >> + int x_limit = drm_rect_width(&planes[i]->frame_info->dst); >> >> - blend(vaddr_out, vaddr, primary_plane_info, >> - plane_frame_info, pixel_blend); >> + if (x_dst + x_limit > line_width) >> + return false; >> + if (x_src + x_limit > x2_src) >> + return false; >> + } >> + >> + return true; >> } >> >> -static int compose_active_planes(void **vaddr_out, >> - struct vkms_frame_info *primary_plane_info, >> - struct vkms_crtc_state *crtc_state) >> +static int compose_active_planes(struct vkms_frame_info *wb_frame_info, >> + struct vkms_crtc_state *crtc_state, >> + u32 *crc32) >> { >> - 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; >> + format_transform_func plane_funcs[NUM_OVERLAY_PLANES], wb_func = NULL; >> + int line_width, ret = 0, pixel_size = sizeof(struct line_buffer); >> + 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 (!*vaddr_out) { >> - *vaddr_out = kvzalloc(gem_obj->size, GFP_KERNEL); >> - if (!*vaddr_out) { >> - DRM_ERROR("Cannot allocate memory for output frame."); >> - return -ENOMEM; >> - } >> + if (WARN_ON(pixel_size != 8)) >> + 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; >> } >> >> + if (!primary_plane_info) >> + return -EINVAL; >> + >> if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) >> return -EINVAL; >> >> - vaddr = primary_plane_info->map[0].vaddr; >> + if (WARN_ON(!check_planes_x_bounds(crtc_state, wb_frame_info))) >> + return -EINVAL; >> >> - memcpy(*vaddr_out, vaddr, gem_obj->size); >> + line_width = drm_rect_width(&primary_plane_info->dst); >> >> - /* 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 < crtc_state->num_active_planes; i++) >> - compose_plane(primary_plane_info, >> - crtc_state->active_planes[i]->frame_info, >> - *vaddr_out); >> + stage_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); >> + if (!stage_buffer) { >> + DRM_ERROR("Cannot allocate memory for the output line buffer"); >> + return -ENOMEM; >> + } >> >> - return 0; >> + output_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); >> + if (!output_buffer) { >> + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); >> + ret = -ENOMEM; >> + goto free_stage_buffer; >> + } >> + >> + get_format_transform_functions(crtc_state, plane_funcs); >> + >> + if (wb_frame_info) { >> + wb_format = wb_frame_info->fb->format->format; >> + wb_func = get_wb_fmt_transform_function(wb_format); >> + wb_frame_info->src = primary_plane_info->src; >> + wb_frame_info->dst = primary_plane_info->dst; >> + } >> + >> + blend(wb_frame_info, wb_func, crtc_state, plane_funcs, crc32, >> + stage_buffer, output_buffer, (s64)line_width * pixel_size); >> + >> + kvfree(output_buffer); >> +free_stage_buffer: >> + kvfree(stage_buffer); >> + >> + return ret; >> } >> >> /** >> @@ -222,13 +230,12 @@ 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_frame_info *wb_frame_info = &active_wb->frame_info; >> struct vkms_output *out = drm_crtc_to_vkms_output(crtc); >> - struct vkms_frame_info *primary_plane_info = NULL; >> - struct vkms_plane_state *act_plane = NULL; >> bool crc_pending, wb_pending; >> - void *vaddr_out = NULL; >> - u32 crc32 = 0; >> u64 frame_start, frame_end; >> + u32 crc32 = 0; >> int ret; >> >> spin_lock_irq(&out->composer_lock); >> @@ -248,35 +255,19 @@ void vkms_composer_worker(struct work_struct *work) >> if (!crc_pending) >> return; >> >> - 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; >> - } >> - >> - if (!primary_plane_info) >> - return; >> - >> if (wb_pending) >> - vaddr_out = crtc_state->active_writeback->data[0].vaddr; >> + ret = compose_active_planes(wb_frame_info, crtc_state, &crc32); >> + else >> + ret = compose_active_planes(NULL, crtc_state, &crc32); >> >> - ret = compose_active_planes(&vaddr_out, primary_plane_info, >> - crtc_state); >> - if (ret) { >> - if (ret == -EINVAL && !wb_pending) >> - kvfree(vaddr_out); >> + if (ret) >> return; >> - } >> - >> - crc32 = compute_crc(vaddr_out, primary_plane_info); >> >> 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); >> - } else { >> - kvfree(vaddr_out); >> } >> >> /* >> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c >> new file mode 100644 >> index 000000000000..0d1838d1b835 >> --- /dev/null >> +++ b/drivers/gpu/drm/vkms/vkms_formats.c >> @@ -0,0 +1,138 @@ >> +/* SPDX-License-Identifier: GPL-2.0+ */ > checkpatch complains here ^ Use `\\` I change it, but: WARNING: Improper SPDX comment style for 'drivers/gpu/drm/vkms/vkms_formats.h', please use '/*' instead #660: FILE: drivers/gpu/drm/vkms/vkms_formats.h:1: +// SPDX-License-Identifier: GPL-2.0+ I keep the change to be consitent with the rest of the vkms files. >> + >> +#include <drm/drm_rect.h> >> +#include "vkms_formats.h" >> + >> +format_transform_func get_fmt_transform_function(u32 format) >> +{ >> + if (format == DRM_FORMAT_ARGB8888) >> + return &ARGB8888_to_ARGB16161616; >> + else >> + return &XRGB8888_to_ARGB16161616; >> +} >> + >> +format_transform_func get_wb_fmt_transform_function(u32 format) >> +{ >> + if (format == DRM_FORMAT_ARGB8888) >> + return &convert_to_ARGB8888; >> + else >> + return &convert_to_XRGB8888; >> +} >> + >> +static int pixel_offset(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(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(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); >> +} >> + >> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer) >> +{ >> + u8 *src_pixels = get_packed_src_addr(frame_info, y); >> + int x, x_limit = drm_rect_width(&frame_info->dst); >> + >> + for (x = 0; x < x_limit; x++, src_pixels += 4) { >> + /* >> + * Organizes the channels in their respective positions and converts >> + * the 8 bits channel to 16. >> + * 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. >> + * And a similar idea applies to others RGB color conversions. >> + */ >> + stage_buffer[x].a = (u16)src_pixels[3] * 257; >> + stage_buffer[x].r = (u16)src_pixels[2] * 257; >> + stage_buffer[x].g = (u16)src_pixels[1] * 257; >> + stage_buffer[x].b = (u16)src_pixels[0] * 257; >> + } >> +} >> + >> +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer) >> +{ >> + u8 *src_pixels = get_packed_src_addr(frame_info, y); >> + int x, x_limit = drm_rect_width(&frame_info->dst); >> + >> + for (x = 0; x < x_limit; x++, src_pixels += 4) { >> + stage_buffer[x].a = (u16)0xffff; >> + stage_buffer[x].r = (u16)src_pixels[2] * 257; >> + stage_buffer[x].g = (u16)src_pixels[1] * 257; >> + stage_buffer[x].b = (u16)src_pixels[0] * 257; >> + } >> +} >> + >> +/* >> + * The following functions take an line of ARGB16161616 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. >> + */ >> +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, >> + int y, struct line_buffer *src_buffer) >> +{ >> + int x, x_dst = frame_info->dst.x1; >> + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); >> + int x_limit = drm_rect_width(&frame_info->dst); >> + >> + 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_UP(src_buffer[x].a, 257); >> + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); >> + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); >> + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); >> + } >> +} >> + >> +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, >> + int y, struct line_buffer *src_buffer) >> +{ >> + int x, x_dst = frame_info->dst.x1; >> + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); >> + int x_limit = drm_rect_width(&frame_info->dst); >> + >> + for (x = 0; x < x_limit; x++, dst_pixels += 4) { >> + dst_pixels[3] = (u8)0xff; >> + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); >> + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); >> + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); >> + } >> +} >> diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h >> new file mode 100644 >> index 000000000000..817e8b2124ae >> --- /dev/null >> +++ b/drivers/gpu/drm/vkms/vkms_formats.h >> @@ -0,0 +1,31 @@ >> +/* SPDX-License-Identifier: GPL-2.0+ */ > and here ^ > >> + >> +#ifndef _VKMS_FORMATS_H_ >> +#define _VKMS_FORMATS_H_ >> + >> +#include "vkms_drv.h" >> + >> +struct line_buffer { >> + u16 a, r, g, b; >> +}; >> + >> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer); >> + >> +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer); >> + >> +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *src_buffer); >> + >> +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *src_buffer); >> + >> +typedef void (*format_transform_func)(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *buffer); >> + >> +format_transform_func get_fmt_transform_function(u32 format); >> + >> +format_transform_func get_wb_fmt_transform_function(u32 format); >> + >> +#endif /* _VKMS_FORMATS_H_ */ >> -- >> 2.30.2 >>
On 02/08, Igor Torrente wrote: > Hi Melissa, > > On 2/8/22 07:40, Melissa Wen wrote: > > On 01/21, Igor Torrente 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 > > > 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 tests `*kms_cursor_crc*`: > > > > > First, thanks for this improvement. > > > > Some recent changes in kms_cursor_crc caused VKMS to fail in most test > > cases (iirc, only size-change and alpha-opaque are passing currently). > > I updated my igt and kernel(from drm_misc/drm-misc-next) to the latest > commit[1][2] and I'm getting mixed results. Sometimes most of the test > passes, sometimes almost nothing passes. hmm.. is it happening when running kms_cursor_crc? Is the results variation random or is it possible to follow a set of steps to reproduce it? When failing, what is the reason displayed by the log? From my side, only the first two subtest of kms_cursor_crc is passing before this patch. And after your changes here, all subtests are successful again, except those related to 32x10 cursor size (that needs futher investigation). I didn't check how the recent changes in kms_cursor_crc affect VKMS performance on it, but I bet that clearing the alpha channel is the reason to have the performance back. > > [1] a96674e7 (tests/api_intel_bb: Handle different alignments in > delta-check) > [2] b21a142fd205 (drm/nouveau/backlight: Just set all backlight types as > RAW) > > > But saying that performance improvement here would cause a > > misunderstanding when reviewing the change history. Can you update this > > statistics here? I think you can specify the IGT hash to specify the > > test case version or you can pick another test for comparison. > > OK, I will do both. > > > > | Frametime | > > > |:------------------------------------------:| > > > | Implementation | Current | This commit | > > > |:---------------:|:---------:|:------------:| > > > | frametime range | 8~22 ms | 5~18 ms | > > > | Average | 10.0 ms | 7.3 ms | > > > > > > Reported-by: kernel test robot <lkp@intel.com> > > A little confusing for me to have this reported-by tag without any > > explanation of what was reported and fixed. Can you specify it? > > > Signed-off-by: Igor Torrente <igormtorrente@gmail.com> > > > --- > > > V2: Improves the performance drastically, by perfoming 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. > > Can you move version changes up so that they are not ignored? > > > > I also pointed out minor code style issue below. > > With these comments addressed, you can add my r-b tag in the next > > version. > > > --- > > > drivers/gpu/drm/vkms/Makefile | 1 + > > > drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- > > > drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ > > > drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ > > > 4 files changed, 333 insertions(+), 172 deletions(-) > > > create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c > > > create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h > > > > > > 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..9f70fcf84fb9 100644 > > > --- a/drivers/gpu/drm/vkms/vkms_composer.c > > > +++ b/drivers/gpu/drm/vkms/vkms_composer.c > > > @@ -9,202 +9,210 @@ > > > #include <drm/drm_vblank.h> > > > #include "vkms_drv.h" > > > +#include "vkms_formats.h" > > > -static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer, > > > - const struct vkms_frame_info *frame_info) > > > +static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha) > > > { > > > - u32 pixel; > > > - int src_offset = frame_info->offset + (y * frame_info->pitch) > > > - + (x * frame_info->cpp); > > > + u32 new_color; > > > - pixel = *(u32 *)&buffer[src_offset]; > > > + new_color = (src * 0xffff + dst * (0xffff - alpha)); > > > - return pixel; > > > + return DIV_ROUND_UP(new_color, 0xffff); > > > } > > > /** > > > - * compute_crc - Compute CRC value on output frame > > > + * 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 > > > * > > > - * @vaddr: address to final framebuffer > > > - * @frame_info: framebuffer's metadata > > > + * 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. > > > * > > > - * returns CRC value computed using crc32 on the visible portion of > > > - * the final framebuffer at vaddr_out > > > + * 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 uint32_t compute_crc(const u8 *vaddr, > > > - const struct vkms_frame_info *frame_info) > > > +static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info, > > > + struct line_buffer *stage_buffer, > > > + struct line_buffer *output_buffer) > > > { > > > - int x, y; > > > - u32 crc = 0, pixel = 0; > > > - int x_src = frame_info->src.x1 >> 16; > > > - int y_src = frame_info->src.y1 >> 16; > > > - int h_src = drm_rect_height(&frame_info->src) >> 16; > > > - int w_src = drm_rect_width(&frame_info->src) >> 16; > > > - > > > - for (y = y_src; y < y_src + h_src; ++y) { > > > - for (x = x_src; x < x_src + w_src; ++x) { > > > - pixel = get_pixel_from_buffer(x, y, vaddr, frame_info); > > > - crc = crc32_le(crc, (void *)&pixel, sizeof(u32)); > > > - } > > > + int x, x_dst = frame_info->dst.x1; > > > + int x_limit = drm_rect_width(&frame_info->dst); > > > + struct line_buffer *out = output_buffer + x_dst; > > > + struct line_buffer *in = stage_buffer; > > > + > > > + 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); > > > } > > > - > > > - return crc; > > > } > > > -static u8 blend_channel(u8 src, u8 dst, u8 alpha) > > > +static bool check_y_limit(struct vkms_frame_info *frame_info, int y) > > > { > > > - u32 pre_blend; > > > - u8 new_color; > > > - > > > - pre_blend = (src * 255 + dst * (255 - alpha)); > > > - > > > - /* Faster div by 255 */ > > > - new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8); > > > + if (y >= frame_info->dst.y1 && y < frame_info->dst.y2) > > > + return true; > > > - return new_color; > > > + return false; > > > } > > > /** > > > - * alpha_blend - alpha blending equation > > > - * @argb_src: src pixel on premultiplied alpha mode > > > - * @argb_dst: dst pixel completely opaque > > > - * > > > - * blend pixels 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 alpha_blend(const u8 *argb_src, u8 *argb_dst) > > > -{ > > > - u8 alpha; > > > - > > > - alpha = argb_src[3]; > > > - argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha); > > > - argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha); > > > - argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha); > > > -} > > > - > > > -/** > > > - * x_blend - blending equation that ignores the pixel alpha > > > - * > > > - * overwrites RGB color value from src pixel to dst pixel. > > > - */ > > > -static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst) > > > -{ > > > - memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3); > > > -} > > > - > > > -/** > > > - * blend - blend value at vaddr_src with value at vaddr_dst > > > - * @vaddr_dst: destination address > > > - * @vaddr_src: source address > > > - * @dst_frame_info: destination framebuffer's metadata > > > - * @src_frame_info: source framebuffer's metadata > > > - * @pixel_blend: blending equation based on plane format > > > + * @wb_frame_info: The writeback frame buffer metadata > > > + * @wb_fmt_func: The format tranformatio function to the wb buffer > > > + * @crtc_state: The crtc state > > > + * @plane_fmt_func: A format tranformation function to each plane > > > + * @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 src_compositor > > > * > > > - * Blend the vaddr_src value with the vaddr_dst value using a pixel blend > > > - * equation according to the supported plane formats DRM_FORMAT_(A/XRGB8888) > > > - * and clearing alpha channel to an completely opaque background. This function > > > - * uses buffer's metadata to locate the new composite values at vaddr_dst. > > > + * 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. > > > * > > > * TODO: completely clear the primary plane (a = 0xff) before starting to blend > > > * pixel color values > > > */ > > > -static void blend(void *vaddr_dst, void *vaddr_src, > > > - struct vkms_frame_info *dst_frame_info, > > > - struct vkms_frame_info *src_frame_info, > > > - void (*pixel_blend)(const u8 *, u8 *)) > > > +static void blend(struct vkms_frame_info *wb_frame_info, > > > + format_transform_func wb_fmt_func, > > > + struct vkms_crtc_state *crtc_state, > > > + format_transform_func *plane_fmt_func, > > > + u32 *crc32, struct line_buffer *stage_buffer, > > > + struct line_buffer *output_buffer, s64 row_size) > > > { > > > - int i, j, j_dst, i_dst; > > > - int offset_src, offset_dst; > > > - u8 *pixel_dst, *pixel_src; > > > - > > > - int x_src = src_frame_info->src.x1 >> 16; > > > - int y_src = src_frame_info->src.y1 >> 16; > > > - > > > - int x_dst = src_frame_info->dst.x1; > > > - int y_dst = src_frame_info->dst.y1; > > > - int h_dst = drm_rect_height(&src_frame_info->dst); > > > - int w_dst = drm_rect_width(&src_frame_info->dst); > > > + 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_src = primary_plane_info->dst.y1; > > > + int h_dst = drm_rect_height(&primary_plane_info->dst); > > > int y_limit = y_src + h_dst; > > > - int x_limit = x_src + w_dst; > > > - > > > - for (i = y_src, i_dst = y_dst; i < y_limit; ++i) { > > > - for (j = x_src, j_dst = x_dst; j < x_limit; ++j) { > > > - offset_dst = dst_frame_info->offset > > > - + (i_dst * dst_frame_info->pitch) > > > - + (j_dst++ * dst_frame_info->cpp); > > > - offset_src = src_frame_info->offset > > > - + (i * src_frame_info->pitch) > > > - + (j * src_frame_info->cpp); > > > - > > > - pixel_src = (u8 *)(vaddr_src + offset_src); > > > - pixel_dst = (u8 *)(vaddr_dst + offset_dst); > > > - pixel_blend(pixel_src, pixel_dst); > > > - /* clearing alpha channel (0xff)*/ > > > - pixel_dst[3] = 0xff; > > > + int y, i; > > > + > > > + for (y = y_src; y < y_limit; y++) { > > > + plane_fmt_func[0](primary_plane_info, y, output_buffer); > > > + > > > + /* 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_fmt_func[i](plane[i]->frame_info, y, stage_buffer); > > > + pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer, > > > + output_buffer); > > > } > > > - i_dst++; > > > + > > > + *crc32 = crc32_le(*crc32, (void *)output_buffer, row_size); > > > + > > > + if (wb_frame_info) > > > + wb_fmt_func(wb_frame_info, y, output_buffer); > > > } > > > } > > > -static void compose_plane(struct vkms_frame_info *primary_plane_info, > > > - struct vkms_frame_info *plane_frame_info, > > > - void *vaddr_out) > > > +static void get_format_transform_functions(struct vkms_crtc_state *crtc_state, > > > + format_transform_func plane_funcs[]) > > > { > > > - struct drm_framebuffer *fb = plane_frame_info->fb; > > > - void *vaddr; > > > - void (*pixel_blend)(const u8 *p_src, u8 *p_dst); > > > + struct vkms_plane_state **active_planes = crtc_state->active_planes; > > > + u32 n_active_planes = crtc_state->num_active_planes, s_fmt; > > > + int i; > > > - if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) > > > - return; > > > + for (i = 0; i < n_active_planes; i++) { > > > + s_fmt = active_planes[i]->frame_info->fb->format->format; > > > + plane_funcs[i] = get_fmt_transform_function(s_fmt); > > > + } > > > +} > > > - vaddr = plane_frame_info->map[0].vaddr; > > > +static bool check_planes_x_bounds(struct vkms_crtc_state *crtc_state, > > > + struct vkms_frame_info *wb_frame_info) > > > +{ > > > + struct vkms_plane_state **planes = crtc_state->active_planes; > > > + struct vkms_frame_info *primary_plane_info = planes[0]->frame_info; > > > + int line_width = drm_rect_width(&primary_plane_info->dst); > > > + u32 n_active_planes = crtc_state->num_active_planes; > > > + int i; > > > - if (fb->format->format == DRM_FORMAT_ARGB8888) > > > - pixel_blend = &alpha_blend; > > > - else > > > - pixel_blend = &x_blend; > > > + for (i = 0; i < n_active_planes; i++) { > > > + int x_dst = planes[i]->frame_info->dst.x1; > > > + int x_src = planes[i]->frame_info->src.x1 >> 16; > > > + int x2_src = planes[i]->frame_info->src.x2 >> 16; > > > + int x_limit = drm_rect_width(&planes[i]->frame_info->dst); > > > - blend(vaddr_out, vaddr, primary_plane_info, > > > - plane_frame_info, pixel_blend); > > > + if (x_dst + x_limit > line_width) > > > + return false; > > > + if (x_src + x_limit > x2_src) > > > + return false; > > > + } > > > + > > > + return true; > > > } > > > -static int compose_active_planes(void **vaddr_out, > > > - struct vkms_frame_info *primary_plane_info, > > > - struct vkms_crtc_state *crtc_state) > > > +static int compose_active_planes(struct vkms_frame_info *wb_frame_info, > > > + struct vkms_crtc_state *crtc_state, > > > + u32 *crc32) > > > { > > > - 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; > > > + format_transform_func plane_funcs[NUM_OVERLAY_PLANES], wb_func = NULL; > > > + int line_width, ret = 0, pixel_size = sizeof(struct line_buffer); > > > + 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 (!*vaddr_out) { > > > - *vaddr_out = kvzalloc(gem_obj->size, GFP_KERNEL); > > > - if (!*vaddr_out) { > > > - DRM_ERROR("Cannot allocate memory for output frame."); > > > - return -ENOMEM; > > > - } > > > + if (WARN_ON(pixel_size != 8)) > > > + 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; > > > } > > > + if (!primary_plane_info) > > > + return -EINVAL; > > > + > > > if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) > > > return -EINVAL; > > > - vaddr = primary_plane_info->map[0].vaddr; > > > + if (WARN_ON(!check_planes_x_bounds(crtc_state, wb_frame_info))) > > > + return -EINVAL; > > > - memcpy(*vaddr_out, vaddr, gem_obj->size); > > > + line_width = drm_rect_width(&primary_plane_info->dst); > > > - /* 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 < crtc_state->num_active_planes; i++) > > > - compose_plane(primary_plane_info, > > > - crtc_state->active_planes[i]->frame_info, > > > - *vaddr_out); > > > + stage_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); > > > + if (!stage_buffer) { > > > + DRM_ERROR("Cannot allocate memory for the output line buffer"); > > > + return -ENOMEM; > > > + } > > > - return 0; > > > + output_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); > > > + if (!output_buffer) { > > > + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); > > > + ret = -ENOMEM; > > > + goto free_stage_buffer; > > > + } > > > + > > > + get_format_transform_functions(crtc_state, plane_funcs); > > > + > > > + if (wb_frame_info) { > > > + wb_format = wb_frame_info->fb->format->format; > > > + wb_func = get_wb_fmt_transform_function(wb_format); > > > + wb_frame_info->src = primary_plane_info->src; > > > + wb_frame_info->dst = primary_plane_info->dst; > > > + } > > > + > > > + blend(wb_frame_info, wb_func, crtc_state, plane_funcs, crc32, > > > + stage_buffer, output_buffer, (s64)line_width * pixel_size); > > > + > > > + kvfree(output_buffer); > > > +free_stage_buffer: > > > + kvfree(stage_buffer); > > > + > > > + return ret; > > > } > > > /** > > > @@ -222,13 +230,12 @@ 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_frame_info *wb_frame_info = &active_wb->frame_info; > > > struct vkms_output *out = drm_crtc_to_vkms_output(crtc); > > > - struct vkms_frame_info *primary_plane_info = NULL; > > > - struct vkms_plane_state *act_plane = NULL; > > > bool crc_pending, wb_pending; > > > - void *vaddr_out = NULL; > > > - u32 crc32 = 0; > > > u64 frame_start, frame_end; > > > + u32 crc32 = 0; > > > int ret; > > > spin_lock_irq(&out->composer_lock); > > > @@ -248,35 +255,19 @@ void vkms_composer_worker(struct work_struct *work) > > > if (!crc_pending) > > > return; > > > - 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; > > > - } > > > - > > > - if (!primary_plane_info) > > > - return; > > > - > > > if (wb_pending) > > > - vaddr_out = crtc_state->active_writeback->data[0].vaddr; > > > + ret = compose_active_planes(wb_frame_info, crtc_state, &crc32); > > > + else > > > + ret = compose_active_planes(NULL, crtc_state, &crc32); > > > - ret = compose_active_planes(&vaddr_out, primary_plane_info, > > > - crtc_state); > > > - if (ret) { > > > - if (ret == -EINVAL && !wb_pending) > > > - kvfree(vaddr_out); > > > + if (ret) > > > return; > > > - } > > > - > > > - crc32 = compute_crc(vaddr_out, primary_plane_info); > > > 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); > > > - } else { > > > - kvfree(vaddr_out); > > > } > > > /* > > > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c > > > new file mode 100644 > > > index 000000000000..0d1838d1b835 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/vkms/vkms_formats.c > > > @@ -0,0 +1,138 @@ > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > checkpatch complains here ^ Use `\\` > > I change it, but: > > WARNING: Improper SPDX comment style for > 'drivers/gpu/drm/vkms/vkms_formats.h', please use '/*' instead > #660: FILE: drivers/gpu/drm/vkms/vkms_formats.h:1: > +// SPDX-License-Identifier: GPL-2.0+ Ok, previously checkpatch was complaining only for `vkms_format.c` but not for the header. I got it wrong when I pointed to the .h file too, sorry. I had two points in mind, but the second issue is not here, it is `multiple blank lines` in the next patch. btw, you find more details about the comment style for SPDX here: https://www.kernel.org/doc/html/latest/process/license-rules.html#license-identifier-syntax > > I keep the change to be consitent with the rest of the vkms files. > > > > + > > > +#include <drm/drm_rect.h> > > > +#include "vkms_formats.h" > > > + > > > +format_transform_func get_fmt_transform_function(u32 format) > > > +{ > > > + if (format == DRM_FORMAT_ARGB8888) > > > + return &ARGB8888_to_ARGB16161616; > > > + else > > > + return &XRGB8888_to_ARGB16161616; > > > +} > > > + > > > +format_transform_func get_wb_fmt_transform_function(u32 format) > > > +{ > > > + if (format == DRM_FORMAT_ARGB8888) > > > + return &convert_to_ARGB8888; > > > + else > > > + return &convert_to_XRGB8888; > > > +} > > > + > > > +static int pixel_offset(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(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(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); > > > +} > > > + > > > +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > > > + struct line_buffer *stage_buffer) > > > +{ > > > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > > > + int x, x_limit = drm_rect_width(&frame_info->dst); > > > + > > > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > > > + /* > > > + * Organizes the channels in their respective positions and converts > > > + * the 8 bits channel to 16. > > > + * 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. > > > + * And a similar idea applies to others RGB color conversions. > > > + */ > > > + stage_buffer[x].a = (u16)src_pixels[3] * 257; > > > + stage_buffer[x].r = (u16)src_pixels[2] * 257; > > > + stage_buffer[x].g = (u16)src_pixels[1] * 257; > > > + stage_buffer[x].b = (u16)src_pixels[0] * 257; > > > + } > > > +} > > > + > > > +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > > > + struct line_buffer *stage_buffer) > > > +{ > > > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > > > + int x, x_limit = drm_rect_width(&frame_info->dst); > > > + > > > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > > > + stage_buffer[x].a = (u16)0xffff; > > > + stage_buffer[x].r = (u16)src_pixels[2] * 257; > > > + stage_buffer[x].g = (u16)src_pixels[1] * 257; > > > + stage_buffer[x].b = (u16)src_pixels[0] * 257; > > > + } > > > +} > > > + > > > +/* > > > + * The following functions take an line of ARGB16161616 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. > > > + */ > > > +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, > > > + int y, struct line_buffer *src_buffer) > > > +{ > > > + int x, x_dst = frame_info->dst.x1; > > > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); > > > + int x_limit = drm_rect_width(&frame_info->dst); > > > + > > > + 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_UP(src_buffer[x].a, 257); > > > + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); > > > + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); > > > + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); > > > + } > > > +} > > > + > > > +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, > > > + int y, struct line_buffer *src_buffer) > > > +{ > > > + int x, x_dst = frame_info->dst.x1; > > > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); > > > + int x_limit = drm_rect_width(&frame_info->dst); > > > + > > > + for (x = 0; x < x_limit; x++, dst_pixels += 4) { > > > + dst_pixels[3] = (u8)0xff; > > > + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); > > > + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); > > > + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); > > > + } > > > +} > > > diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h > > > new file mode 100644 > > > index 000000000000..817e8b2124ae > > > --- /dev/null > > > +++ b/drivers/gpu/drm/vkms/vkms_formats.h > > > @@ -0,0 +1,31 @@ > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > and here ^ > > > > > + > > > +#ifndef _VKMS_FORMATS_H_ > > > +#define _VKMS_FORMATS_H_ > > > + > > > +#include "vkms_drv.h" > > > + > > > +struct line_buffer { > > > + u16 a, r, g, b; > > > +}; > > > + > > > +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > > > + struct line_buffer *stage_buffer); > > > + > > > +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > > > + struct line_buffer *stage_buffer); > > > + > > > +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, int y, > > > + struct line_buffer *src_buffer); > > > + > > > +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, int y, > > > + struct line_buffer *src_buffer); > > > + > > > +typedef void (*format_transform_func)(struct vkms_frame_info *frame_info, int y, > > > + struct line_buffer *buffer); > > > + > > > +format_transform_func get_fmt_transform_function(u32 format); > > > + > > > +format_transform_func get_wb_fmt_transform_function(u32 format); > > > + > > > +#endif /* _VKMS_FORMATS_H_ */ > > > -- > > > 2.30.2 > > >
On Fri, 21 Jan 2022 18:38:29 -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 > 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 tests `*kms_cursor_crc*`: > > | Frametime | > |:------------------------------------------:| > | Implementation | Current | This commit | > |:---------------:|:---------:|:------------:| > | frametime range | 8~22 ms | 5~18 ms | > | Average | 10.0 ms | 7.3 ms | > > Reported-by: kernel test robot <lkp@intel.com> > Signed-off-by: Igor Torrente <igormtorrente@gmail.com> > --- > V2: Improves the performance drastically, by perfoming 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. > --- > drivers/gpu/drm/vkms/Makefile | 1 + > drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- > drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ > drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ > 4 files changed, 333 insertions(+), 172 deletions(-) > create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c > create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h Hi Igor, I'm really happy to see this, thanks! I still have some security/robustness and other comments below. I've deleted all the minus lines from the patch to make the new code more clear. > > 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..9f70fcf84fb9 100644 > --- a/drivers/gpu/drm/vkms/vkms_composer.c > +++ b/drivers/gpu/drm/vkms/vkms_composer.c > @@ -9,202 +9,210 @@ > #include <drm/drm_vblank.h> > > #include "vkms_drv.h" > +#include "vkms_formats.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_UP(new_color, 0xffff); Why round-up rather than the usual mathematical rounding? > } > > /** > + * 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; > + int x_limit = drm_rect_width(&frame_info->dst); > + struct line_buffer *out = output_buffer + x_dst; > + struct line_buffer *in = stage_buffer; Here you would check that you don't overrun any of the arrays. At this point, I believe an overrun would indicate a bug in VKMS, so handle it according to the kernel conventions. I have suggestion further below how to make that check possible. In other places, I'll just say "check for overruns" for short. > + > + 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 > + * @wb_fmt_func: The format tranformatio function to the wb buffer > + * @crtc_state: The crtc state > + * @plane_fmt_func: A format tranformation function to each plane Is it not *from* each plane? Each plane... does this mean that all planes must have the same pixel format? Oh wait, it's a pointer, so an array, isn't it? You're passing in an array without passing in the array size. That seems quite risky to me. Think of someone else needing to patch something here without fully understanding how this all works, they'd easily introduce a subtle bug. Looks like the array must be number of "active planes" long. So it's not even a constant, and the size of the array is not documented here. What if the fmt_func was a field in struct vkms_frame_info? So you could set it when creating a vkms_frame_info. Wouldn't that simplify the code in blend() and its callers? > + * @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 src_compositor I don't see src_compositor? > * > + * 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. > * > * TODO: completely clear the primary plane (a = 0xff) before starting to blend > * pixel color values Mm, you only need to clear output_buffer, not the whole writeback FB. output_buffer will unconditionally and totally overwrite the writeback FB, right? > */ > +static void blend(struct vkms_frame_info *wb_frame_info, Using "wb" as short for writeback is... well, it's hard for the me remember at least. Could this not be named simply "writeback"? > + format_transform_func wb_fmt_func, "writeback_func" > + struct vkms_crtc_state *crtc_state, > + format_transform_func *plane_fmt_func, > + 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_src = primary_plane_info->dst.y1; Shouldn't this be called y_dst instead? > + int h_dst = drm_rect_height(&primary_plane_info->dst); > int y_limit = y_src + h_dst; > + int y, i; It took me a while to understand that all these y-coordinates are CRTC coordinates. Maybe call them crtc_y, crtc_y_begin, crtc_y_end, crtc_y_height, etc. > + > + for (y = y_src; y < y_limit; y++) { > + plane_fmt_func[0](primary_plane_info, y, output_buffer); This is initializing output_buffer, right? So why do you have the TODO comment about clearing the primary plane above? Is it because the primary plane may not cover the CRTC exactly, the destination rectangle might be bigger or smaller? The output_buffer length should be the CRTC width, right? Maybe the special-casing the primary plane in this code is wrong. crtc_y needs to iterate over the CRTC height starting from zero. Then, you explicitly clear output_buffer to opaque background color, and primary plane becomes just another plane in the array of active planes with no special handling here. That will allow you to support overlay planes *below* the primary plane (as is fairly common in non-PC hardware), and you can even support the background color KMS property. > + > + /* 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_fmt_func[i](plane[i]->frame_info, y, stage_buffer); > + pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer, > + output_buffer); > } > + > + *crc32 = crc32_le(*crc32, (void *)output_buffer, row_size); > + > + if (wb_frame_info) > + wb_fmt_func(wb_frame_info, y, output_buffer); > } > } > > +static void get_format_transform_functions(struct vkms_crtc_state *crtc_state, > + format_transform_func plane_funcs[]) > { > + struct vkms_plane_state **active_planes = crtc_state->active_planes; > + u32 n_active_planes = crtc_state->num_active_planes, s_fmt; > + int i; > > + for (i = 0; i < n_active_planes; i++) { > + s_fmt = active_planes[i]->frame_info->fb->format->format; > + plane_funcs[i] = get_fmt_transform_function(s_fmt); > + } > +} > > +static bool check_planes_x_bounds(struct vkms_crtc_state *crtc_state, > + struct vkms_frame_info *wb_frame_info) > +{ > + struct vkms_plane_state **planes = crtc_state->active_planes; > + struct vkms_frame_info *primary_plane_info = planes[0]->frame_info; > + int line_width = drm_rect_width(&primary_plane_info->dst); > + u32 n_active_planes = crtc_state->num_active_planes; > + int i; > > + for (i = 0; i < n_active_planes; i++) { > + int x_dst = planes[i]->frame_info->dst.x1; > + int x_src = planes[i]->frame_info->src.x1 >> 16; > + int x2_src = planes[i]->frame_info->src.x2 >> 16; > + int x_limit = drm_rect_width(&planes[i]->frame_info->dst); > > + if (x_dst + x_limit > line_width) > + return false; > + if (x_src + x_limit > x2_src) > + return false; > + } That's interesting. Looks like you reject everything if any plane is not fully inside the primary plane destination rectangle. But that's not the right check, is it? If you want to check this, you would check against the CRTC dimensions. Then again, I think some hardware do allow planes to reach outside of the CRTC dimensions. Cursor plane is probably the best example. The cursor can be partly off-screen. So this is something that would need to be supported both ways I suppose, but going with the "all plane destination rectangles must be strictly inside the CRTC dimensions" is a good start. But why only x-coordinate check? y should have the same rules, right? > + > + return true; > } > > +static int compose_active_planes(struct vkms_frame_info *wb_frame_info, > + struct vkms_crtc_state *crtc_state, > + u32 *crc32) > { > + format_transform_func plane_funcs[NUM_OVERLAY_PLANES], wb_func = NULL; > + int line_width, ret = 0, pixel_size = sizeof(struct line_buffer); > + 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)) > + 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; > } > > + 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_planes_x_bounds(crtc_state, wb_frame_info))) > + return -EINVAL; > > + line_width = drm_rect_width(&primary_plane_info->dst); This needs to be CRTC width, not primary plane width. > > + stage_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); > + if (!stage_buffer) { > + DRM_ERROR("Cannot allocate memory for the output line buffer"); > + return -ENOMEM; > + } > > + output_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); > + if (!output_buffer) { > + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); > + ret = -ENOMEM; > + goto free_stage_buffer; > + } > + > + get_format_transform_functions(crtc_state, plane_funcs); > + > + if (wb_frame_info) { > + wb_format = wb_frame_info->fb->format->format; > + wb_func = get_wb_fmt_transform_function(wb_format); > + wb_frame_info->src = primary_plane_info->src; > + wb_frame_info->dst = primary_plane_info->dst; > + } > + > + blend(wb_frame_info, wb_func, crtc_state, plane_funcs, crc32, > + stage_buffer, output_buffer, (s64)line_width * pixel_size); > + > + kvfree(output_buffer); > +free_stage_buffer: > + kvfree(stage_buffer); > + > + return ret; > } > > /** > @@ -222,13 +230,12 @@ 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_frame_info *wb_frame_info = &active_wb->frame_info; > 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 +255,19 @@ void vkms_composer_worker(struct work_struct *work) > if (!crc_pending) > return; > > if (wb_pending) > + ret = compose_active_planes(wb_frame_info, 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..0d1838d1b835 > --- /dev/null > +++ b/drivers/gpu/drm/vkms/vkms_formats.c > @@ -0,0 +1,138 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > + > +#include <drm/drm_rect.h> > +#include "vkms_formats.h" > + > +format_transform_func get_fmt_transform_function(u32 format) > +{ > + if (format == DRM_FORMAT_ARGB8888) > + return &ARGB8888_to_ARGB16161616; > + else > + return &XRGB8888_to_ARGB16161616; In functions like this you should prepare for caller errors. Use a switch, and fail any attempt to use a pixel format it doesn't support. Failing is much better than silently producing garbage or worse: buffer overruns when bytes-per-pixel is not what you expected. What to do on failure depends on whether the failure here is never supposed to happen (follow the kernel style) e.g. malicious userspace cannot trigger it, or if you actually use this function to define the supported for pixel formats. The latter means you'd have a list of all DRM pixel formats and then you'd ask for each one if this function knows it, and if yes, you add the format to the list of supported formats advertised to userspace. I don't know if that would be fine by DRM coding style. > +} > + > +format_transform_func get_wb_fmt_transform_function(u32 format) > +{ > + if (format == DRM_FORMAT_ARGB8888) > + return &convert_to_ARGB8888; > + else > + return &convert_to_XRGB8888; > +} I think you could move the above getter functions to the bottom of the .c file, and make all the four *_to_* functions static, and remove them from the header. > + > +static int pixel_offset(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(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(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); > +} > + > +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer) I'm fairly sure that DRM will one day add exactly ARGB16161616 format. But that will not be the format you use here (or it might be, but purely accidentally and depending on machine endianess and whatnot), so I would suggest inventing a new name. Also use the same name for the struct to hold a single pixel. E.g. struct pixel_argb_u16 So that it is clear it is not meant to be any specific DRM_FORMAT_* format. > +{ > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > + int x, x_limit = drm_rect_width(&frame_info->dst); > + > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > + /* > + * Organizes the channels in their respective positions and converts > + * the 8 bits channel to 16. > + * 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. > + * And a similar idea applies to others RGB color conversions. > + */ > + stage_buffer[x].a = (u16)src_pixels[3] * 257; > + stage_buffer[x].r = (u16)src_pixels[2] * 257; > + stage_buffer[x].g = (u16)src_pixels[1] * 257; > + stage_buffer[x].b = (u16)src_pixels[0] * 257; > + } > +} > + > +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer) > +{ > + u8 *src_pixels = get_packed_src_addr(frame_info, y); > + int x, x_limit = drm_rect_width(&frame_info->dst); > + > + for (x = 0; x < x_limit; x++, src_pixels += 4) { > + stage_buffer[x].a = (u16)0xffff; > + stage_buffer[x].r = (u16)src_pixels[2] * 257; > + stage_buffer[x].g = (u16)src_pixels[1] * 257; > + stage_buffer[x].b = (u16)src_pixels[0] * 257; > + } > +} > + > +/* > + * The following functions take an line of ARGB16161616 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. > + */ > +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, > + int y, struct line_buffer *src_buffer) Please, use consistent function naming style. These are using "convert" while the other ones are using "ARGB16161616". > +{ > + int x, x_dst = frame_info->dst.x1; > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); > + int x_limit = drm_rect_width(&frame_info->dst); > + > + 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_UP(src_buffer[x].a, 257); > + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); > + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); > + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); > + } > +} > + > +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, > + int y, struct line_buffer *src_buffer) > +{ > + int x, x_dst = frame_info->dst.x1; > + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); > + int x_limit = drm_rect_width(&frame_info->dst); > + > + for (x = 0; x < x_limit; x++, dst_pixels += 4) { > + dst_pixels[3] = (u8)0xff; > + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); > + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); > + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); > + } > +} > diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h > new file mode 100644 > index 000000000000..817e8b2124ae > --- /dev/null > +++ b/drivers/gpu/drm/vkms/vkms_formats.h > @@ -0,0 +1,31 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > + > +#ifndef _VKMS_FORMATS_H_ > +#define _VKMS_FORMATS_H_ > + > +#include "vkms_drv.h" > + > +struct line_buffer { As I mentioned above, this would be called pixel_argb_u16 or something like that. > + u16 a, r, g, b; > +}; I was trying to suggest that a line_buffer would actually hold a whole line, something like the pseudo code: struct line_buffer { size_t len_pixels; struct my_pixel_type pixels[]; } or whatever the kernel style for a variable length array at the end of a struct is. Field names are suggestions. Then it is easy to check that you don't overflow any line_buffer when operating on them. > + > +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer); > + > +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *stage_buffer); > + > +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *src_buffer); > + > +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *src_buffer); You should only need the below functions and not the above ones in this header. > + > +typedef void (*format_transform_func)(struct vkms_frame_info *frame_info, int y, > + struct line_buffer *buffer); The arguments for this function-pointer should be documented, especially that y is the y-coordinate in CRTC coordinate space, i.e. plane destination rectangle. You might even call it crtc_y. I think you should use two different function-pointer types for the two different kinds of functions: - reads arbitrary pixel format and writes to rgba_u16 - reads rgba_u16 and writes to arbitrary pixel format This will prevent any mistakes in accidentally using the wrong kind of function. If you also have the argument order different between the two types of functions, getting them mixed up is even less likely. I presume the kernel uses the function(destination, source) style of argument ordering. You can also use 'const' on the source, that is a good way to document things too. The consequence of using the wrong function could be the leak of kernel memory content to userspace, which is pretty bad. So preventing that kind of problems before they happen is nice. > + > +format_transform_func get_fmt_transform_function(u32 format); > + > +format_transform_func get_wb_fmt_transform_function(u32 format); > + > +#endif /* _VKMS_FORMATS_H_ */ Good work! Thanks, pq
Hi Melissa, On 2/9/22 18:45, Melissa Wen wrote: > On 02/08, Igor Torrente wrote: >> Hi Melissa, >> >> On 2/8/22 07:40, Melissa Wen wrote: >>> On 01/21, Igor Torrente 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 >>>> 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 tests `*kms_cursor_crc*`: >>>> >>> First, thanks for this improvement. >>> >>> Some recent changes in kms_cursor_crc caused VKMS to fail in most test >>> cases (iirc, only size-change and alpha-opaque are passing currently). >> >> I updated my igt and kernel(from drm_misc/drm-misc-next) to the latest >> commit[1][2] and I'm getting mixed results. Sometimes most of the test >> passes, sometimes almost nothing passes. > hmm.. is it happening when running kms_cursor_crc? Is the results > variation random or is it possible to follow a set of steps to reproduce > it? When failing, what is the reason displayed by the log? I investigated it a little bit and discovered that the KMS cursor(".*kms_cursor_crc*" ) are failing after the execution of writeback tests(".*kms_writeback.*"). I don't know what is causing it, but they are failing while trying to commit the KMS changes. out.txt: IGT-Version: 1.26-NO-GIT (x86_64) (Linux: 5.17.0-rc2 x86_64) Stack trace: #0 ../lib/igt_core.c:1754 __igt_fail_assert() #1 ../lib/igt_kms.c:3795 do_display_commit() #2 ../lib/igt_kms.c:3901 igt_display_commit2() #3 ../tests/kms_cursor_crc.c:820 __igt_unique____real_main814() #4 ../tests/kms_cursor_crc.c:814 main() #5 ../csu/libc-start.c:308 __libc_start_main() #6 [_start+0x2a] Subtest pipe-A-cursor-size-change: FAIL err.txt: (kms_cursor_crc:1936) igt_kms-CRITICAL: Test assertion failure function do_display_commit, file ../lib/igt_kms.c:3795: (kms_cursor_crc:1936) igt_kms-CRITICAL: Failed assertion: ret == 0 (kms_cursor_crc:1936) igt_kms-CRITICAL: Last errno: 22, Invalid argument (kms_cursor_crc:1936) igt_kms-CRITICAL: error: -22 != 0 > > From my side, only the first two subtest of kms_cursor_crc is passing > before this patch. And after your changes here, all subtests are > successful again, except those related to 32x10 cursor size (that needs > futher investigation). I didn't check how the recent changes in > kms_cursor_crc affect VKMS performance on it, but I bet that clearing > the alpha channel is the reason to have the performance back. Yeah, I also don't understand why the 32x10 cursor tests are failing. >> >> [1] a96674e7 (tests/api_intel_bb: Handle different alignments in >> delta-check) >> [2] b21a142fd205 (drm/nouveau/backlight: Just set all backlight types as >> RAW) >> >>> But saying that performance improvement here would cause a >>> misunderstanding when reviewing the change history. Can you update this >>> statistics here? I think you can specify the IGT hash to specify the >>> test case version or you can pick another test for comparison. >> >> OK, I will do both. >> >>>> | Frametime | >>>> |:------------------------------------------:| >>>> | Implementation | Current | This commit | >>>> |:---------------:|:---------:|:------------:| >>>> | frametime range | 8~22 ms | 5~18 ms | >>>> | Average | 10.0 ms | 7.3 ms | >>>> >>>> Reported-by: kernel test robot <lkp@intel.com> >>> A little confusing for me to have this reported-by tag without any >>> explanation of what was reported and fixed. Can you specify it? >>>> Signed-off-by: Igor Torrente <igormtorrente@gmail.com> >>>> --- >>>> V2: Improves the performance drastically, by perfoming 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. >>> Can you move version changes up so that they are not ignored? >>> >>> I also pointed out minor code style issue below. >>> With these comments addressed, you can add my r-b tag in the next >>> version. >>>> --- >>>> drivers/gpu/drm/vkms/Makefile | 1 + >>>> drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- >>>> drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ >>>> drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ >>>> 4 files changed, 333 insertions(+), 172 deletions(-) >>>> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c >>>> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h >>>> >>>> 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..9f70fcf84fb9 100644 >>>> --- a/drivers/gpu/drm/vkms/vkms_composer.c >>>> +++ b/drivers/gpu/drm/vkms/vkms_composer.c >>>> @@ -9,202 +9,210 @@ >>>> #include <drm/drm_vblank.h> >>>> #include "vkms_drv.h" >>>> +#include "vkms_formats.h" >>>> -static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer, >>>> - const struct vkms_frame_info *frame_info) >>>> +static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha) >>>> { >>>> - u32 pixel; >>>> - int src_offset = frame_info->offset + (y * frame_info->pitch) >>>> - + (x * frame_info->cpp); >>>> + u32 new_color; >>>> - pixel = *(u32 *)&buffer[src_offset]; >>>> + new_color = (src * 0xffff + dst * (0xffff - alpha)); >>>> - return pixel; >>>> + return DIV_ROUND_UP(new_color, 0xffff); >>>> } >>>> /** >>>> - * compute_crc - Compute CRC value on output frame >>>> + * 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 >>>> * >>>> - * @vaddr: address to final framebuffer >>>> - * @frame_info: framebuffer's metadata >>>> + * 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. >>>> * >>>> - * returns CRC value computed using crc32 on the visible portion of >>>> - * the final framebuffer at vaddr_out >>>> + * 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 uint32_t compute_crc(const u8 *vaddr, >>>> - const struct vkms_frame_info *frame_info) >>>> +static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info, >>>> + struct line_buffer *stage_buffer, >>>> + struct line_buffer *output_buffer) >>>> { >>>> - int x, y; >>>> - u32 crc = 0, pixel = 0; >>>> - int x_src = frame_info->src.x1 >> 16; >>>> - int y_src = frame_info->src.y1 >> 16; >>>> - int h_src = drm_rect_height(&frame_info->src) >> 16; >>>> - int w_src = drm_rect_width(&frame_info->src) >> 16; >>>> - >>>> - for (y = y_src; y < y_src + h_src; ++y) { >>>> - for (x = x_src; x < x_src + w_src; ++x) { >>>> - pixel = get_pixel_from_buffer(x, y, vaddr, frame_info); >>>> - crc = crc32_le(crc, (void *)&pixel, sizeof(u32)); >>>> - } >>>> + int x, x_dst = frame_info->dst.x1; >>>> + int x_limit = drm_rect_width(&frame_info->dst); >>>> + struct line_buffer *out = output_buffer + x_dst; >>>> + struct line_buffer *in = stage_buffer; >>>> + >>>> + 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); >>>> } >>>> - >>>> - return crc; >>>> } >>>> -static u8 blend_channel(u8 src, u8 dst, u8 alpha) >>>> +static bool check_y_limit(struct vkms_frame_info *frame_info, int y) >>>> { >>>> - u32 pre_blend; >>>> - u8 new_color; >>>> - >>>> - pre_blend = (src * 255 + dst * (255 - alpha)); >>>> - >>>> - /* Faster div by 255 */ >>>> - new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8); >>>> + if (y >= frame_info->dst.y1 && y < frame_info->dst.y2) >>>> + return true; >>>> - return new_color; >>>> + return false; >>>> } >>>> /** >>>> - * alpha_blend - alpha blending equation >>>> - * @argb_src: src pixel on premultiplied alpha mode >>>> - * @argb_dst: dst pixel completely opaque >>>> - * >>>> - * blend pixels 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 alpha_blend(const u8 *argb_src, u8 *argb_dst) >>>> -{ >>>> - u8 alpha; >>>> - >>>> - alpha = argb_src[3]; >>>> - argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha); >>>> - argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha); >>>> - argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha); >>>> -} >>>> - >>>> -/** >>>> - * x_blend - blending equation that ignores the pixel alpha >>>> - * >>>> - * overwrites RGB color value from src pixel to dst pixel. >>>> - */ >>>> -static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst) >>>> -{ >>>> - memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3); >>>> -} >>>> - >>>> -/** >>>> - * blend - blend value at vaddr_src with value at vaddr_dst >>>> - * @vaddr_dst: destination address >>>> - * @vaddr_src: source address >>>> - * @dst_frame_info: destination framebuffer's metadata >>>> - * @src_frame_info: source framebuffer's metadata >>>> - * @pixel_blend: blending equation based on plane format >>>> + * @wb_frame_info: The writeback frame buffer metadata >>>> + * @wb_fmt_func: The format tranformatio function to the wb buffer >>>> + * @crtc_state: The crtc state >>>> + * @plane_fmt_func: A format tranformation function to each plane >>>> + * @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 src_compositor >>>> * >>>> - * Blend the vaddr_src value with the vaddr_dst value using a pixel blend >>>> - * equation according to the supported plane formats DRM_FORMAT_(A/XRGB8888) >>>> - * and clearing alpha channel to an completely opaque background. This function >>>> - * uses buffer's metadata to locate the new composite values at vaddr_dst. >>>> + * 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. >>>> * >>>> * TODO: completely clear the primary plane (a = 0xff) before starting to blend >>>> * pixel color values >>>> */ >>>> -static void blend(void *vaddr_dst, void *vaddr_src, >>>> - struct vkms_frame_info *dst_frame_info, >>>> - struct vkms_frame_info *src_frame_info, >>>> - void (*pixel_blend)(const u8 *, u8 *)) >>>> +static void blend(struct vkms_frame_info *wb_frame_info, >>>> + format_transform_func wb_fmt_func, >>>> + struct vkms_crtc_state *crtc_state, >>>> + format_transform_func *plane_fmt_func, >>>> + u32 *crc32, struct line_buffer *stage_buffer, >>>> + struct line_buffer *output_buffer, s64 row_size) >>>> { >>>> - int i, j, j_dst, i_dst; >>>> - int offset_src, offset_dst; >>>> - u8 *pixel_dst, *pixel_src; >>>> - >>>> - int x_src = src_frame_info->src.x1 >> 16; >>>> - int y_src = src_frame_info->src.y1 >> 16; >>>> - >>>> - int x_dst = src_frame_info->dst.x1; >>>> - int y_dst = src_frame_info->dst.y1; >>>> - int h_dst = drm_rect_height(&src_frame_info->dst); >>>> - int w_dst = drm_rect_width(&src_frame_info->dst); >>>> + 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_src = primary_plane_info->dst.y1; >>>> + int h_dst = drm_rect_height(&primary_plane_info->dst); >>>> int y_limit = y_src + h_dst; >>>> - int x_limit = x_src + w_dst; >>>> - >>>> - for (i = y_src, i_dst = y_dst; i < y_limit; ++i) { >>>> - for (j = x_src, j_dst = x_dst; j < x_limit; ++j) { >>>> - offset_dst = dst_frame_info->offset >>>> - + (i_dst * dst_frame_info->pitch) >>>> - + (j_dst++ * dst_frame_info->cpp); >>>> - offset_src = src_frame_info->offset >>>> - + (i * src_frame_info->pitch) >>>> - + (j * src_frame_info->cpp); >>>> - >>>> - pixel_src = (u8 *)(vaddr_src + offset_src); >>>> - pixel_dst = (u8 *)(vaddr_dst + offset_dst); >>>> - pixel_blend(pixel_src, pixel_dst); >>>> - /* clearing alpha channel (0xff)*/ >>>> - pixel_dst[3] = 0xff; >>>> + int y, i; >>>> + >>>> + for (y = y_src; y < y_limit; y++) { >>>> + plane_fmt_func[0](primary_plane_info, y, output_buffer); >>>> + >>>> + /* 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_fmt_func[i](plane[i]->frame_info, y, stage_buffer); >>>> + pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer, >>>> + output_buffer); >>>> } >>>> - i_dst++; >>>> + >>>> + *crc32 = crc32_le(*crc32, (void *)output_buffer, row_size); >>>> + >>>> + if (wb_frame_info) >>>> + wb_fmt_func(wb_frame_info, y, output_buffer); >>>> } >>>> } >>>> -static void compose_plane(struct vkms_frame_info *primary_plane_info, >>>> - struct vkms_frame_info *plane_frame_info, >>>> - void *vaddr_out) >>>> +static void get_format_transform_functions(struct vkms_crtc_state *crtc_state, >>>> + format_transform_func plane_funcs[]) >>>> { >>>> - struct drm_framebuffer *fb = plane_frame_info->fb; >>>> - void *vaddr; >>>> - void (*pixel_blend)(const u8 *p_src, u8 *p_dst); >>>> + struct vkms_plane_state **active_planes = crtc_state->active_planes; >>>> + u32 n_active_planes = crtc_state->num_active_planes, s_fmt; >>>> + int i; >>>> - if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) >>>> - return; >>>> + for (i = 0; i < n_active_planes; i++) { >>>> + s_fmt = active_planes[i]->frame_info->fb->format->format; >>>> + plane_funcs[i] = get_fmt_transform_function(s_fmt); >>>> + } >>>> +} >>>> - vaddr = plane_frame_info->map[0].vaddr; >>>> +static bool check_planes_x_bounds(struct vkms_crtc_state *crtc_state, >>>> + struct vkms_frame_info *wb_frame_info) >>>> +{ >>>> + struct vkms_plane_state **planes = crtc_state->active_planes; >>>> + struct vkms_frame_info *primary_plane_info = planes[0]->frame_info; >>>> + int line_width = drm_rect_width(&primary_plane_info->dst); >>>> + u32 n_active_planes = crtc_state->num_active_planes; >>>> + int i; >>>> - if (fb->format->format == DRM_FORMAT_ARGB8888) >>>> - pixel_blend = &alpha_blend; >>>> - else >>>> - pixel_blend = &x_blend; >>>> + for (i = 0; i < n_active_planes; i++) { >>>> + int x_dst = planes[i]->frame_info->dst.x1; >>>> + int x_src = planes[i]->frame_info->src.x1 >> 16; >>>> + int x2_src = planes[i]->frame_info->src.x2 >> 16; >>>> + int x_limit = drm_rect_width(&planes[i]->frame_info->dst); >>>> - blend(vaddr_out, vaddr, primary_plane_info, >>>> - plane_frame_info, pixel_blend); >>>> + if (x_dst + x_limit > line_width) >>>> + return false; >>>> + if (x_src + x_limit > x2_src) >>>> + return false; >>>> + } >>>> + >>>> + return true; >>>> } >>>> -static int compose_active_planes(void **vaddr_out, >>>> - struct vkms_frame_info *primary_plane_info, >>>> - struct vkms_crtc_state *crtc_state) >>>> +static int compose_active_planes(struct vkms_frame_info *wb_frame_info, >>>> + struct vkms_crtc_state *crtc_state, >>>> + u32 *crc32) >>>> { >>>> - 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; >>>> + format_transform_func plane_funcs[NUM_OVERLAY_PLANES], wb_func = NULL; >>>> + int line_width, ret = 0, pixel_size = sizeof(struct line_buffer); >>>> + 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 (!*vaddr_out) { >>>> - *vaddr_out = kvzalloc(gem_obj->size, GFP_KERNEL); >>>> - if (!*vaddr_out) { >>>> - DRM_ERROR("Cannot allocate memory for output frame."); >>>> - return -ENOMEM; >>>> - } >>>> + if (WARN_ON(pixel_size != 8)) >>>> + 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; >>>> } >>>> + if (!primary_plane_info) >>>> + return -EINVAL; >>>> + >>>> if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) >>>> return -EINVAL; >>>> - vaddr = primary_plane_info->map[0].vaddr; >>>> + if (WARN_ON(!check_planes_x_bounds(crtc_state, wb_frame_info))) >>>> + return -EINVAL; >>>> - memcpy(*vaddr_out, vaddr, gem_obj->size); >>>> + line_width = drm_rect_width(&primary_plane_info->dst); >>>> - /* 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 < crtc_state->num_active_planes; i++) >>>> - compose_plane(primary_plane_info, >>>> - crtc_state->active_planes[i]->frame_info, >>>> - *vaddr_out); >>>> + stage_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); >>>> + if (!stage_buffer) { >>>> + DRM_ERROR("Cannot allocate memory for the output line buffer"); >>>> + return -ENOMEM; >>>> + } >>>> - return 0; >>>> + output_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); >>>> + if (!output_buffer) { >>>> + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); >>>> + ret = -ENOMEM; >>>> + goto free_stage_buffer; >>>> + } >>>> + >>>> + get_format_transform_functions(crtc_state, plane_funcs); >>>> + >>>> + if (wb_frame_info) { >>>> + wb_format = wb_frame_info->fb->format->format; >>>> + wb_func = get_wb_fmt_transform_function(wb_format); >>>> + wb_frame_info->src = primary_plane_info->src; >>>> + wb_frame_info->dst = primary_plane_info->dst; >>>> + } >>>> + >>>> + blend(wb_frame_info, wb_func, crtc_state, plane_funcs, crc32, >>>> + stage_buffer, output_buffer, (s64)line_width * pixel_size); >>>> + >>>> + kvfree(output_buffer); >>>> +free_stage_buffer: >>>> + kvfree(stage_buffer); >>>> + >>>> + return ret; >>>> } >>>> /** >>>> @@ -222,13 +230,12 @@ 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_frame_info *wb_frame_info = &active_wb->frame_info; >>>> struct vkms_output *out = drm_crtc_to_vkms_output(crtc); >>>> - struct vkms_frame_info *primary_plane_info = NULL; >>>> - struct vkms_plane_state *act_plane = NULL; >>>> bool crc_pending, wb_pending; >>>> - void *vaddr_out = NULL; >>>> - u32 crc32 = 0; >>>> u64 frame_start, frame_end; >>>> + u32 crc32 = 0; >>>> int ret; >>>> spin_lock_irq(&out->composer_lock); >>>> @@ -248,35 +255,19 @@ void vkms_composer_worker(struct work_struct *work) >>>> if (!crc_pending) >>>> return; >>>> - 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; >>>> - } >>>> - >>>> - if (!primary_plane_info) >>>> - return; >>>> - >>>> if (wb_pending) >>>> - vaddr_out = crtc_state->active_writeback->data[0].vaddr; >>>> + ret = compose_active_planes(wb_frame_info, crtc_state, &crc32); >>>> + else >>>> + ret = compose_active_planes(NULL, crtc_state, &crc32); >>>> - ret = compose_active_planes(&vaddr_out, primary_plane_info, >>>> - crtc_state); >>>> - if (ret) { >>>> - if (ret == -EINVAL && !wb_pending) >>>> - kvfree(vaddr_out); >>>> + if (ret) >>>> return; >>>> - } >>>> - >>>> - crc32 = compute_crc(vaddr_out, primary_plane_info); >>>> 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); >>>> - } else { >>>> - kvfree(vaddr_out); >>>> } >>>> /* >>>> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c >>>> new file mode 100644 >>>> index 000000000000..0d1838d1b835 >>>> --- /dev/null >>>> +++ b/drivers/gpu/drm/vkms/vkms_formats.c >>>> @@ -0,0 +1,138 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0+ */ >>> checkpatch complains here ^ Use `\\` >> >> I change it, but: >> >> WARNING: Improper SPDX comment style for >> 'drivers/gpu/drm/vkms/vkms_formats.h', please use '/*' instead >> #660: FILE: drivers/gpu/drm/vkms/vkms_formats.h:1: >> +// SPDX-License-Identifier: GPL-2.0+ > Ok, previously checkpatch was complaining only for `vkms_format.c` but > not for the header. I got it wrong when I pointed to the .h file too, > sorry. I had two points in mind, but the second issue is not here, it is > `multiple blank lines` in the next patch. > > btw, you find more details about the comment style for SPDX here: > https://www.kernel.org/doc/html/latest/process/license-rules.html#license-identifier-syntax > >> >> I keep the change to be consitent with the rest of the vkms files. >> >>>> + >>>> +#include <drm/drm_rect.h> >>>> +#include "vkms_formats.h" >>>> + >>>> +format_transform_func get_fmt_transform_function(u32 format) >>>> +{ >>>> + if (format == DRM_FORMAT_ARGB8888) >>>> + return &ARGB8888_to_ARGB16161616; >>>> + else >>>> + return &XRGB8888_to_ARGB16161616; >>>> +} >>>> + >>>> +format_transform_func get_wb_fmt_transform_function(u32 format) >>>> +{ >>>> + if (format == DRM_FORMAT_ARGB8888) >>>> + return &convert_to_ARGB8888; >>>> + else >>>> + return &convert_to_XRGB8888; >>>> +} >>>> + >>>> +static int pixel_offset(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(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(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); >>>> +} >>>> + >>>> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *stage_buffer) >>>> +{ >>>> + u8 *src_pixels = get_packed_src_addr(frame_info, y); >>>> + int x, x_limit = drm_rect_width(&frame_info->dst); >>>> + >>>> + for (x = 0; x < x_limit; x++, src_pixels += 4) { >>>> + /* >>>> + * Organizes the channels in their respective positions and converts >>>> + * the 8 bits channel to 16. >>>> + * 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. >>>> + * And a similar idea applies to others RGB color conversions. >>>> + */ >>>> + stage_buffer[x].a = (u16)src_pixels[3] * 257; >>>> + stage_buffer[x].r = (u16)src_pixels[2] * 257; >>>> + stage_buffer[x].g = (u16)src_pixels[1] * 257; >>>> + stage_buffer[x].b = (u16)src_pixels[0] * 257; >>>> + } >>>> +} >>>> + >>>> +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *stage_buffer) >>>> +{ >>>> + u8 *src_pixels = get_packed_src_addr(frame_info, y); >>>> + int x, x_limit = drm_rect_width(&frame_info->dst); >>>> + >>>> + for (x = 0; x < x_limit; x++, src_pixels += 4) { >>>> + stage_buffer[x].a = (u16)0xffff; >>>> + stage_buffer[x].r = (u16)src_pixels[2] * 257; >>>> + stage_buffer[x].g = (u16)src_pixels[1] * 257; >>>> + stage_buffer[x].b = (u16)src_pixels[0] * 257; >>>> + } >>>> +} >>>> + >>>> +/* >>>> + * The following functions take an line of ARGB16161616 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. >>>> + */ >>>> +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, >>>> + int y, struct line_buffer *src_buffer) >>>> +{ >>>> + int x, x_dst = frame_info->dst.x1; >>>> + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); >>>> + int x_limit = drm_rect_width(&frame_info->dst); >>>> + >>>> + 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_UP(src_buffer[x].a, 257); >>>> + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); >>>> + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); >>>> + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); >>>> + } >>>> +} >>>> + >>>> +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, >>>> + int y, struct line_buffer *src_buffer) >>>> +{ >>>> + int x, x_dst = frame_info->dst.x1; >>>> + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); >>>> + int x_limit = drm_rect_width(&frame_info->dst); >>>> + >>>> + for (x = 0; x < x_limit; x++, dst_pixels += 4) { >>>> + dst_pixels[3] = (u8)0xff; >>>> + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); >>>> + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); >>>> + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); >>>> + } >>>> +} >>>> diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h >>>> new file mode 100644 >>>> index 000000000000..817e8b2124ae >>>> --- /dev/null >>>> +++ b/drivers/gpu/drm/vkms/vkms_formats.h >>>> @@ -0,0 +1,31 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0+ */ >>> and here ^ >>> >>>> + >>>> +#ifndef _VKMS_FORMATS_H_ >>>> +#define _VKMS_FORMATS_H_ >>>> + >>>> +#include "vkms_drv.h" >>>> + >>>> +struct line_buffer { >>>> + u16 a, r, g, b; >>>> +}; >>>> + >>>> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *stage_buffer); >>>> + >>>> +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *stage_buffer); >>>> + >>>> +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *src_buffer); >>>> + >>>> +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *src_buffer); >>>> + >>>> +typedef void (*format_transform_func)(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *buffer); >>>> + >>>> +format_transform_func get_fmt_transform_function(u32 format); >>>> + >>>> +format_transform_func get_wb_fmt_transform_function(u32 format); >>>> + >>>> +#endif /* _VKMS_FORMATS_H_ */ >>>> -- >>>> 2.30.2 >>>>
On Sun, 20 Feb 2022 22:02:12 -0300 Igor Torrente <igormtorrente@gmail.com> wrote: > Hi Melissa, > > On 2/9/22 18:45, Melissa Wen wrote: > > On 02/08, Igor Torrente wrote: > >> Hi Melissa, > >> > >> On 2/8/22 07:40, Melissa Wen wrote: > >>> On 01/21, Igor Torrente 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 > >>>> 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 tests `*kms_cursor_crc*`: > >>>> > >>> First, thanks for this improvement. > >>> > >>> Some recent changes in kms_cursor_crc caused VKMS to fail in most test > >>> cases (iirc, only size-change and alpha-opaque are passing currently). > >> > >> I updated my igt and kernel(from drm_misc/drm-misc-next) to the latest > >> commit[1][2] and I'm getting mixed results. Sometimes most of the test > >> passes, sometimes almost nothing passes. > > hmm.. is it happening when running kms_cursor_crc? Is the results > > variation random or is it possible to follow a set of steps to reproduce > > it? When failing, what is the reason displayed by the log? > > I investigated it a little bit and discovered that the KMS > cursor(".*kms_cursor_crc*" ) are failing after the execution of > writeback tests(".*kms_writeback.*"). > > I don't know what is causing it, but they are failing while trying to > commit the KMS changes. > > out.txt: > IGT-Version: 1.26-NO-GIT (x86_64) (Linux: 5.17.0-rc2 x86_64) > Stack trace: > #0 ../lib/igt_core.c:1754 __igt_fail_assert() > #1 ../lib/igt_kms.c:3795 do_display_commit() > #2 ../lib/igt_kms.c:3901 igt_display_commit2() > #3 ../tests/kms_cursor_crc.c:820 __igt_unique____real_main814() > #4 ../tests/kms_cursor_crc.c:814 main() > #5 ../csu/libc-start.c:308 __libc_start_main() > #6 [_start+0x2a] > Subtest pipe-A-cursor-size-change: FAIL > > err.txt: > (kms_cursor_crc:1936) igt_kms-CRITICAL: Test assertion failure function > do_display_commit, file ../lib/igt_kms.c:3795: > (kms_cursor_crc:1936) igt_kms-CRITICAL: Failed assertion: ret == 0 > (kms_cursor_crc:1936) igt_kms-CRITICAL: Last errno: 22, Invalid argument > (kms_cursor_crc:1936) igt_kms-CRITICAL: error: -22 != 0 > > > > > From my side, only the first two subtest of kms_cursor_crc is passing > > before this patch. And after your changes here, all subtests are > > successful again, except those related to 32x10 cursor size (that needs > > futher investigation). I didn't check how the recent changes in > > kms_cursor_crc affect VKMS performance on it, but I bet that clearing > > the alpha channel is the reason to have the performance back. > > Yeah, I also don't understand why the 32x10 cursor tests are failing. > Hi, are the tests putting the cursor partially outside of the CRTC area? Or partially outside of primary plane area (which IIRC you used when you should have used the CRTC area?)? Does the writeback test forget to unlink the writeback connector? Or does VKMS not handle unlinking the writeback connector? If both are a problem, the latter would be just an unrelated bug that exposes the first bug in VKMS, because whether writeback is used or not probably should not affect where the cursor plane is allowed to be. Thanks, pq
Hi Pekka, On 2/21/22 06:18, Pekka Paalanen wrote: > On Sun, 20 Feb 2022 22:02:12 -0300 > Igor Torrente <igormtorrente@gmail.com> wrote: > >> Hi Melissa, >> >> On 2/9/22 18:45, Melissa Wen wrote: >>> On 02/08, Igor Torrente wrote: >>>> Hi Melissa, >>>> >>>> On 2/8/22 07:40, Melissa Wen wrote: >>>>> On 01/21, Igor Torrente 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 >>>>>> 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 tests `*kms_cursor_crc*`: >>>>>> >>>>> First, thanks for this improvement. >>>>> >>>>> Some recent changes in kms_cursor_crc caused VKMS to fail in most test >>>>> cases (iirc, only size-change and alpha-opaque are passing currently). >>>> >>>> I updated my igt and kernel(from drm_misc/drm-misc-next) to the latest >>>> commit[1][2] and I'm getting mixed results. Sometimes most of the test >>>> passes, sometimes almost nothing passes. >>> hmm.. is it happening when running kms_cursor_crc? Is the results >>> variation random or is it possible to follow a set of steps to reproduce >>> it? When failing, what is the reason displayed by the log? >> >> I investigated it a little bit and discovered that the KMS >> cursor(".*kms_cursor_crc*" ) are failing after the execution of >> writeback tests(".*kms_writeback.*"). >> >> I don't know what is causing it, but they are failing while trying to >> commit the KMS changes. >> >> out.txt: >> IGT-Version: 1.26-NO-GIT (x86_64) (Linux: 5.17.0-rc2 x86_64) >> Stack trace: >> #0 ../lib/igt_core.c:1754 __igt_fail_assert() >> #1 ../lib/igt_kms.c:3795 do_display_commit() >> #2 ../lib/igt_kms.c:3901 igt_display_commit2() >> #3 ../tests/kms_cursor_crc.c:820 __igt_unique____real_main814() >> #4 ../tests/kms_cursor_crc.c:814 main() >> #5 ../csu/libc-start.c:308 __libc_start_main() >> #6 [_start+0x2a] >> Subtest pipe-A-cursor-size-change: FAIL >> >> err.txt: >> (kms_cursor_crc:1936) igt_kms-CRITICAL: Test assertion failure function >> do_display_commit, file ../lib/igt_kms.c:3795: >> (kms_cursor_crc:1936) igt_kms-CRITICAL: Failed assertion: ret == 0 >> (kms_cursor_crc:1936) igt_kms-CRITICAL: Last errno: 22, Invalid argument >> (kms_cursor_crc:1936) igt_kms-CRITICAL: error: -22 != 0 >> >>> >>> From my side, only the first two subtest of kms_cursor_crc is passing >>> before this patch. And after your changes here, all subtests are >>> successful again, except those related to 32x10 cursor size (that needs >>> futher investigation). I didn't check how the recent changes in >>> kms_cursor_crc affect VKMS performance on it, but I bet that clearing >>> the alpha channel is the reason to have the performance back. >> >> Yeah, I also don't understand why the 32x10 cursor tests are failing. >> > > Hi, > > are the tests putting the cursor partially outside of the CRTC area? > Or partially outside of primary plane area (which IIRC you used when you > should have used the CRTC area?)? > > Does the writeback test forget to unlink the writeback connector? Or > does VKMS not handle unlinking the writeback connector? I don't know the answer to all these questions. I did try to find the commit that introduces this issue, and I found that it's happening since the writeback was introduced in Aug 2020(dbd9d80c). And the failure related to the 32x10 cursor was happening before my changes. > > If both are a problem, the latter would be just an unrelated bug that > exposes the first bug in VKMS, because whether writeback is used or not > probably should not affect where the cursor plane is allowed to be. Yeah, I don't think those a related. Best Regards. --- Igor Torrente > > > Thanks, > pq
On Mon, 21 Feb 2022 22:13:21 -0300 Igor Torrente <igormtorrente@gmail.com> wrote: > Hi Pekka, > > On 2/21/22 06:18, Pekka Paalanen wrote: > > On Sun, 20 Feb 2022 22:02:12 -0300 > > Igor Torrente <igormtorrente@gmail.com> wrote: > > > >> Hi Melissa, > >> > >> On 2/9/22 18:45, Melissa Wen wrote: > >>> On 02/08, Igor Torrente wrote: > >>>> Hi Melissa, > >>>> > >>>> On 2/8/22 07:40, Melissa Wen wrote: > >>>>> On 01/21, Igor Torrente 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 > >>>>>> 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 tests `*kms_cursor_crc*`: > >>>>>> > >>>>> First, thanks for this improvement. > >>>>> > >>>>> Some recent changes in kms_cursor_crc caused VKMS to fail in most test > >>>>> cases (iirc, only size-change and alpha-opaque are passing currently). > >>>> > >>>> I updated my igt and kernel(from drm_misc/drm-misc-next) to the latest > >>>> commit[1][2] and I'm getting mixed results. Sometimes most of the test > >>>> passes, sometimes almost nothing passes. > >>> hmm.. is it happening when running kms_cursor_crc? Is the results > >>> variation random or is it possible to follow a set of steps to reproduce > >>> it? When failing, what is the reason displayed by the log? > >> > >> I investigated it a little bit and discovered that the KMS > >> cursor(".*kms_cursor_crc*" ) are failing after the execution of > >> writeback tests(".*kms_writeback.*"). > >> > >> I don't know what is causing it, but they are failing while trying to > >> commit the KMS changes. > >> > >> out.txt: > >> IGT-Version: 1.26-NO-GIT (x86_64) (Linux: 5.17.0-rc2 x86_64) > >> Stack trace: > >> #0 ../lib/igt_core.c:1754 __igt_fail_assert() > >> #1 ../lib/igt_kms.c:3795 do_display_commit() > >> #2 ../lib/igt_kms.c:3901 igt_display_commit2() > >> #3 ../tests/kms_cursor_crc.c:820 __igt_unique____real_main814() > >> #4 ../tests/kms_cursor_crc.c:814 main() > >> #5 ../csu/libc-start.c:308 __libc_start_main() > >> #6 [_start+0x2a] > >> Subtest pipe-A-cursor-size-change: FAIL > >> > >> err.txt: > >> (kms_cursor_crc:1936) igt_kms-CRITICAL: Test assertion failure function > >> do_display_commit, file ../lib/igt_kms.c:3795: > >> (kms_cursor_crc:1936) igt_kms-CRITICAL: Failed assertion: ret == 0 > >> (kms_cursor_crc:1936) igt_kms-CRITICAL: Last errno: 22, Invalid argument > >> (kms_cursor_crc:1936) igt_kms-CRITICAL: error: -22 != 0 > >> > >>> > >>> From my side, only the first two subtest of kms_cursor_crc is passing > >>> before this patch. And after your changes here, all subtests are > >>> successful again, except those related to 32x10 cursor size (that needs > >>> futher investigation). I didn't check how the recent changes in > >>> kms_cursor_crc affect VKMS performance on it, but I bet that clearing > >>> the alpha channel is the reason to have the performance back. > >> > >> Yeah, I also don't understand why the 32x10 cursor tests are failing. > >> > > > > Hi, > > > > are the tests putting the cursor partially outside of the CRTC area? > > Or partially outside of primary plane area (which IIRC you used when you > > should have used the CRTC area?)? > > > > Does the writeback test forget to unlink the writeback connector? Or > > does VKMS not handle unlinking the writeback connector? > > I don't know the answer to all these questions. These are just suggestions in the direction of research, just in case you had no idea. ;-) After all, the UAPI error code is EINVAL, so something in VKMS rejects the IGT-produced configuration. Figuring out what that configuration is and why it gets rejected might be useful to find out. Maybe the original writeback code did not expect planes to be partially off-screen? Guarding against that would produce EINVAL. This is just a wild guess, I've never read that code, but it also seems like the simplest possible mistake to make in good faith - not a bug in code, just a wrong initial assumption of use cases. If you found in your testing that the IGT cursor-size-change test succeeds if ran before writeback test, but fails if ran after the writeback test, then obviously something in the writeback test is leaving stray state behind. It could be the test itself, or it could be a VKMS bug. Thanks, pq
Hi Pekka, On 2/10/22 06:37, Pekka Paalanen wrote: > On Fri, 21 Jan 2022 18:38:29 -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 >> 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 tests `*kms_cursor_crc*`: >> >> | Frametime | >> |:------------------------------------------:| >> | Implementation | Current | This commit | >> |:---------------:|:---------:|:------------:| >> | frametime range | 8~22 ms | 5~18 ms | >> | Average | 10.0 ms | 7.3 ms | >> >> Reported-by: kernel test robot <lkp@intel.com> >> Signed-off-by: Igor Torrente <igormtorrente@gmail.com> >> --- >> V2: Improves the performance drastically, by perfoming 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. >> --- >> drivers/gpu/drm/vkms/Makefile | 1 + >> drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- >> drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ >> drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ >> 4 files changed, 333 insertions(+), 172 deletions(-) >> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c >> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h > > Hi Igor, > > I'm really happy to see this, thanks! > > I still have some security/robustness and other comments below. > > I've deleted all the minus lines from the patch to make the new code > more clear. > >> >> 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..9f70fcf84fb9 100644 >> --- a/drivers/gpu/drm/vkms/vkms_composer.c >> +++ b/drivers/gpu/drm/vkms/vkms_composer.c >> @@ -9,202 +9,210 @@ >> #include <drm/drm_vblank.h> >> >> #include "vkms_drv.h" >> +#include "vkms_formats.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_UP(new_color, 0xffff); > > Why round-up rather than the usual mathematical rounding? AFAIK, this is the only round that's present in the kernel. And if I understood correctly it is the round toward positive infinity that we are all used to use. > >> } >> >> /** >> + * 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; >> + int x_limit = drm_rect_width(&frame_info->dst); >> + struct line_buffer *out = output_buffer + x_dst; >> + struct line_buffer *in = stage_buffer; > > Here you would check that you don't overrun any of the arrays. At this > point, I believe an overrun would indicate a bug in VKMS, so handle it > according to the kernel conventions. I have suggestions below > how to make that check possible. In other places, I'll just say "check > for overruns" for short. > >> + >> + 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 >> + * @wb_fmt_func: The format tranformatio function to the wb buffer >> + * @crtc_state: The crtc state >> + * @plane_fmt_func: A format tranformation function to each plane > > Is it not *from* each plane? > > Each plane... does this mean that all planes must have the same pixel > format? > > Oh wait, it's a pointer, so an array, isn't it? You're passing in an > array without passing in the array size. That seems quite risky to me. > Think of someone else needing to patch something here without fully > understanding how this all works, they'd easily introduce a subtle bug. > > Looks like the array must be number of "active planes" long. So it's > not even a constant, and the size of the array is not documented here. I didn't think about it. But it makes a lot of sense to me. > > What if the fmt_func was a field in struct vkms_frame_info? So you > could set it when creating a vkms_frame_info. Wouldn't that simplify > the code in blend() and its callers? This is a great idea! I will change it to the next version. > >> + * @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 src_compositor > > I don't see src_compositor? Oops. > >> * >> + * 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. >> * >> * TODO: completely clear the primary plane (a = 0xff) before starting to blend >> * pixel color values > > Mm, you only need to clear output_buffer, not the whole writeback FB. > output_buffer will unconditionally and totally overwrite the writeback > FB, right? Right. If I understand it correctly, this was necessary to be implemented because of the way the previous code handles the alpha channel. > >> */ >> +static void blend(struct vkms_frame_info *wb_frame_info, > > Using "wb" as short for writeback is... well, it's hard for the me > remember at least. Could this not be named simply "writeback"? IMHO it's better to use wb instead of writeback for consistency. Given that wb is used throughout the vkms code. > >> + format_transform_func wb_fmt_func, > > "writeback_func" > >> + struct vkms_crtc_state *crtc_state, >> + format_transform_func *plane_fmt_func, >> + 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_src = primary_plane_info->dst.y1; > > Shouldn't this be called y_dst instead? Yes, it should. And will for v5. > >> + int h_dst = drm_rect_height(&primary_plane_info->dst); >> int y_limit = y_src + h_dst; >> + int y, i; > > It took me a while to understand that all these y-coordinates are CRTC > coordinates. Maybe call them crtc_y, crtc_y_begin, crtc_y_end, > crtc_y_height, etc. > >> + >> + for (y = y_src; y < y_limit; y++) { >> + plane_fmt_func[0](primary_plane_info, y, output_buffer); > > This is initializing output_buffer, right? So why do you have the TODO > comment about clearing the primary plane above? > > Is it because the primary plane may not cover the CRTC exactly, the > destination rectangle might be bigger or smaller? > > The output_buffer length should be the CRTC width, right? > > Maybe the special-casing the primary plane in this code is wrong. > crtc_y needs to iterate over the CRTC height starting from zero. Then, > you explicitly clear output_buffer to opaque background color, and > primary plane becomes just another plane in the array of active planes > with no special handling here. > > That will allow you to support overlay planes *below* the primary plane > (as is fairly common in non-PC hardware), and you can even support the > background color KMS property. I thought that the primary would always cover the entire screen exactly. So yeah, my patch code assumes that CRTC is the same size as the primary plane. (and if I'm not mistaken the current version also assumes it). But If this is not the case, where are the CRTC dimensions? Are they in the CRTC properties? drm_mode_config? I couldn't find them. > >> + >> + /* 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_fmt_func[i](plane[i]->frame_info, y, stage_buffer); >> + pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer, >> + output_buffer); >> } >> + >> + *crc32 = crc32_le(*crc32, (void *)output_buffer, row_size); >> + >> + if (wb_frame_info) >> + wb_fmt_func(wb_frame_info, y, output_buffer); >> } >> } >> >> +static void get_format_transform_functions(struct vkms_crtc_state *crtc_state, >> + format_transform_func plane_funcs[]) >> { >> + struct vkms_plane_state **active_planes = crtc_state->active_planes; >> + u32 n_active_planes = crtc_state->num_active_planes, s_fmt; >> + int i; >> >> + for (i = 0; i < n_active_planes; i++) { >> + s_fmt = active_planes[i]->frame_info->fb->format->format; >> + plane_funcs[i] = get_fmt_transform_function(s_fmt); >> + } >> +} >> >> +static bool check_planes_x_bounds(struct vkms_crtc_state *crtc_state, >> + struct vkms_frame_info *wb_frame_info) >> +{ >> + struct vkms_plane_state **planes = crtc_state->active_planes; >> + struct vkms_frame_info *primary_plane_info = planes[0]->frame_info; >> + int line_width = drm_rect_width(&primary_plane_info->dst); >> + u32 n_active_planes = crtc_state->num_active_planes; >> + int i; >> >> + for (i = 0; i < n_active_planes; i++) { >> + int x_dst = planes[i]->frame_info->dst.x1; >> + int x_src = planes[i]->frame_info->src.x1 >> 16; >> + int x2_src = planes[i]->frame_info->src.x2 >> 16; >> + int x_limit = drm_rect_width(&planes[i]->frame_info->dst); >> >> + if (x_dst + x_limit > line_width) >> + return false; >> + if (x_src + x_limit > x2_src) >> + return false; >> + } > > That's interesting. Looks like you reject everything if any plane is > not fully inside the primary plane destination rectangle. But that's > not the right check, is it? If you want to check this, you would check > against the CRTC dimensions. The same wrong assumption here. > > Then again, I think some hardware do allow planes to reach outside of > the CRTC dimensions. Cursor plane is probably the best example. The > cursor can be partly off-screen. So this is something that would need > to be supported both ways I suppose, but going with the "all plane > destination rectangles must be strictly inside the CRTC dimensions" is > a good start. > > But why only x-coordinate check? y should have the same rules, right? My code is inconsistent in this regard. I created this function to prevent out-of-bound memory access by checking all the X-axis limits, but because the blend loop ends, no matter what, at the primary Y-limit (which until now I assumed to be exactly the CRTC dimensions), I don't check the Y-axis because it's not possible to cause any out-of-bound access. So, unintentionally, we have the partial off-screen for the Y-axis but nor the X-axis. > >> + >> + return true; >> } >> >> +static int compose_active_planes(struct vkms_frame_info *wb_frame_info, >> + struct vkms_crtc_state *crtc_state, >> + u32 *crc32) >> { >> + format_transform_func plane_funcs[NUM_OVERLAY_PLANES], wb_func = NULL; >> + int line_width, ret = 0, pixel_size = sizeof(struct line_buffer); >> + 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)) >> + 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; >> } >> >> + 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_planes_x_bounds(crtc_state, wb_frame_info))) >> + return -EINVAL; >> >> + line_width = drm_rect_width(&primary_plane_info->dst); > > This needs to be CRTC width, not primary plane width. > >> >> + stage_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); >> + if (!stage_buffer) { >> + DRM_ERROR("Cannot allocate memory for the output line buffer"); >> + return -ENOMEM; >> + } >> >> + output_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); >> + if (!output_buffer) { >> + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); >> + ret = -ENOMEM; >> + goto free_stage_buffer; >> + } >> + >> + get_format_transform_functions(crtc_state, plane_funcs); >> + >> + if (wb_frame_info) { >> + wb_format = wb_frame_info->fb->format->format; >> + wb_func = get_wb_fmt_transform_function(wb_format); >> + wb_frame_info->src = primary_plane_info->src; >> + wb_frame_info->dst = primary_plane_info->dst; >> + } >> + >> + blend(wb_frame_info, wb_func, crtc_state, plane_funcs, crc32, >> + stage_buffer, output_buffer, (s64)line_width * pixel_size); >> + >> + kvfree(output_buffer); >> +free_stage_buffer: >> + kvfree(stage_buffer); >> + >> + return ret; >> } >> >> /** >> @@ -222,13 +230,12 @@ 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_frame_info *wb_frame_info = &active_wb->frame_info; >> 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 +255,19 @@ void vkms_composer_worker(struct work_struct *work) >> if (!crc_pending) >> return; >> >> if (wb_pending) >> + ret = compose_active_planes(wb_frame_info, 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..0d1838d1b835 >> --- /dev/null >> +++ b/drivers/gpu/drm/vkms/vkms_formats.c >> @@ -0,0 +1,138 @@ >> +/* SPDX-License-Identifier: GPL-2.0+ */ >> + >> +#include <drm/drm_rect.h> >> +#include "vkms_formats.h" >> + >> +format_transform_func get_fmt_transform_function(u32 format) >> +{ >> + if (format == DRM_FORMAT_ARGB8888) >> + return &ARGB8888_to_ARGB16161616; >> + else >> + return &XRGB8888_to_ARGB16161616; > > In functions like this you should prepare for caller errors. Use a > switch, and fail any attempt to use a pixel format it doesn't support. > Failing is much better than silently producing garbage or worse: buffer > overruns when bytes-per-pixel is not what you expected. > > What to do on failure depends on whether the failure here is never > supposed to happen (follow the kernel style) e.g. malicious userspace > cannot trigger it, or if you actually use this function to define the > supported for pixel formats. No, I don't use this function to define supported formats, It's defined: - vkms_writeback.c:15 - vkms_plane.c:14 and 22 And if I'm not mistaken the DRM framework takes care of validation. > > The latter means you'd have a list of all DRM pixel formats and then > you'd ask for each one if this function knows it, and if yes, you add > the format to the list of supported formats advertised to userspace. I > don't know if that would be fine by DRM coding style. > >> +} >> + >> +format_transform_func get_wb_fmt_transform_function(u32 format) >> +{ >> + if (format == DRM_FORMAT_ARGB8888) >> + return &convert_to_ARGB8888; >> + else >> + return &convert_to_XRGB8888; >> +} > > I think you could move the above getter functions to the bottom of the > .c file, and make all the four *_to_* functions static, and remove them > from the header. OK. I will do that. Question, what's the benefits of using static functions? > >> + >> +static int pixel_offset(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(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(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); >> +} >> + >> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer) > > I'm fairly sure that DRM will one day add exactly ARGB16161616 format. > But that will not be the format you use here (or it might be, but > purely accidentally and depending on machine endianess and whatnot), so > I would suggest inventing a new name. Also use the same name for the > struct to hold a single pixel. > > E.g. struct pixel_argb_u16 I'm terrible with names of variables, functions, etc. I will end-up with ARGB8888_to_argb_u16. > > So that it is clear it is not meant to be any specific DRM_FORMAT_* format. > >> +{ >> + u8 *src_pixels = get_packed_src_addr(frame_info, y); >> + int x, x_limit = drm_rect_width(&frame_info->dst); >> + >> + for (x = 0; x < x_limit; x++, src_pixels += 4) { >> + /* >> + * Organizes the channels in their respective positions and converts >> + * the 8 bits channel to 16. >> + * 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. >> + * And a similar idea applies to others RGB color conversions. >> + */ >> + stage_buffer[x].a = (u16)src_pixels[3] * 257; >> + stage_buffer[x].r = (u16)src_pixels[2] * 257; >> + stage_buffer[x].g = (u16)src_pixels[1] * 257; >> + stage_buffer[x].b = (u16)src_pixels[0] * 257; >> + } >> +} >> + >> +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer) >> +{ >> + u8 *src_pixels = get_packed_src_addr(frame_info, y); >> + int x, x_limit = drm_rect_width(&frame_info->dst); >> + >> + for (x = 0; x < x_limit; x++, src_pixels += 4) { >> + stage_buffer[x].a = (u16)0xffff; >> + stage_buffer[x].r = (u16)src_pixels[2] * 257; >> + stage_buffer[x].g = (u16)src_pixels[1] * 257; >> + stage_buffer[x].b = (u16)src_pixels[0] * 257; >> + } >> +} >> + >> +/* >> + * The following functions take an line of ARGB16161616 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. >> + */ >> +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, >> + int y, struct line_buffer *src_buffer) > > Please, use consistent function naming style. These are using "convert" > while the other ones are using "ARGB16161616". > >> +{ >> + int x, x_dst = frame_info->dst.x1; >> + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); >> + int x_limit = drm_rect_width(&frame_info->dst); >> + >> + 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_UP(src_buffer[x].a, 257); >> + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); >> + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); >> + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); >> + } >> +} >> + >> +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, >> + int y, struct line_buffer *src_buffer) >> +{ >> + int x, x_dst = frame_info->dst.x1; >> + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); >> + int x_limit = drm_rect_width(&frame_info->dst); >> + >> + for (x = 0; x < x_limit; x++, dst_pixels += 4) { >> + dst_pixels[3] = (u8)0xff; >> + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); >> + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); >> + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); >> + } >> +} >> diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h >> new file mode 100644 >> index 000000000000..817e8b2124ae >> --- /dev/null >> +++ b/drivers/gpu/drm/vkms/vkms_formats.h >> @@ -0,0 +1,31 @@ >> +/* SPDX-License-Identifier: GPL-2.0+ */ >> + >> +#ifndef _VKMS_FORMATS_H_ >> +#define _VKMS_FORMATS_H_ >> + >> +#include "vkms_drv.h" >> + >> +struct line_buffer { > > As I mentioned above, this would be called pixel_argb_u16 or something > like that. > >> + u16 a, r, g, b; >> +}; > > I was trying to suggest that a line_buffer would actually hold a whole > line, something like the pseudo code: > > struct line_buffer { > size_t len_pixels; > struct my_pixel_type pixels[]; > } > > or whatever the kernel style for a variable length array at the end of > a struct is. Field names are suggestions. > > Then it is easy to check that you don't overflow any line_buffer when > operating on them. Ok. I will change it. > >> + >> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer); >> + >> +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *stage_buffer); >> + >> +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *src_buffer); >> + >> +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *src_buffer); > > You should only need the below functions and not the above ones in this header. > >> + >> +typedef void (*format_transform_func)(struct vkms_frame_info *frame_info, int y, >> + struct line_buffer *buffer); > > The arguments for this function-pointer should be documented, > especially that y is the y-coordinate in CRTC coordinate space, i.e. > plane destination rectangle. You might even call it crtc_y. > > I think you should use two different function-pointer types for the two > different kinds of functions: > - reads arbitrary pixel format and writes to rgba_u16 > - reads rgba_u16 and writes to arbitrary pixel format > > This will prevent any mistakes in accidentally using the wrong kind of > function. If you also have the argument order different between the two > types of functions, getting them mixed up is even less likely. I > presume the kernel uses the function(destination, source) style of > argument ordering. You can also use 'const' on the source, that is a > good way to document things too. > > The consequence of using the wrong function could be the leak of kernel > memory content to userspace, which is pretty bad. So preventing that > kind of problems before they happen is nice. Okay, all of this makes a lot of sense. I will change it to the next version. Last question for this email, I have a patch with the implementation of nv12 and YUV420 formats, but I don't know how to test it because the ".*kms_plane@pixel-format*" igt test doesn't support these formats (And also it isn't working anymore with my hack). Do you know how to test it? Best Regards, --- Igor Torrente > >> + >> +format_transform_func get_fmt_transform_function(u32 format); >> + >> +format_transform_func get_wb_fmt_transform_function(u32 format); >> + >> +#endif /* _VKMS_FORMATS_H_ */ > > > Good work! > > > Thanks, > pq
On Thu, 24 Feb 2022 21:43:01 -0300 Igor Torrente <igormtorrente@gmail.com> wrote: > Hi Pekka, > > On 2/10/22 06:37, Pekka Paalanen wrote: > > On Fri, 21 Jan 2022 18:38:29 -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 > >> 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 tests `*kms_cursor_crc*`: > >> > >> | Frametime | > >> |:------------------------------------------:| > >> | Implementation | Current | This commit | > >> |:---------------:|:---------:|:------------:| > >> | frametime range | 8~22 ms | 5~18 ms | > >> | Average | 10.0 ms | 7.3 ms | > >> > >> Reported-by: kernel test robot <lkp@intel.com> > >> Signed-off-by: Igor Torrente <igormtorrente@gmail.com> > >> --- > >> V2: Improves the performance drastically, by perfoming 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. > >> --- > >> drivers/gpu/drm/vkms/Makefile | 1 + > >> drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- > >> drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ > >> drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ > >> 4 files changed, 333 insertions(+), 172 deletions(-) > >> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c > >> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h > > > > Hi Igor, > > > > I'm really happy to see this, thanks! > > > > I still have some security/robustness and other comments below. > > > > I've deleted all the minus lines from the patch to make the new code > > more clear. > > > >> > >> 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..9f70fcf84fb9 100644 > >> --- a/drivers/gpu/drm/vkms/vkms_composer.c > >> +++ b/drivers/gpu/drm/vkms/vkms_composer.c > >> @@ -9,202 +9,210 @@ > >> #include <drm/drm_vblank.h> > >> > >> #include "vkms_drv.h" > >> +#include "vkms_formats.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_UP(new_color, 0xffff); > > > > Why round-up rather than the usual mathematical rounding? > > AFAIK, this is the only round that's present in the kernel. And if I > understood correctly it is the round toward positive infinity that we are > all used to use. Should be pretty easy to round-up from 0.5 and round-down otherwise. Just add a different offset than DIV_ROUND_UP does. Not having a ready-made macro and habits are not good justifications. The justification needs to be mathematical. The problem with DIV_ROUND_UP that I see, is that 0x00000001 gets rounded to 0x0001, and anything that is even slightly above 0xfffe0000 gets rounded to 0xffff. So it seems to me that this adds a bias to the result. Is my intuition right or wrong, I'm not sure. I do know that 0xffff * 0xffff = 0xfffe0001 so values greater than 0xfffe0001 cannot occur. That seems to mean that there is exactly one 32-bit value that DIV_ROUND_UPs to 0x0000 and exactly one 32-bit value that DIV_ROUND_UPs to 0xffff. That doesn't feel right to me. Would need to compare to how the blending with real numbers would work. > >> */ > >> +static void blend(struct vkms_frame_info *wb_frame_info, > > > > Using "wb" as short for writeback is... well, it's hard for the me > > remember at least. Could this not be named simply "writeback"? > > IMHO it's better to use wb instead of writeback for consistency. Given that wb > is used throughout the vkms code. Right, so that's a problem for me. Is any other driver using wb for writeback? I don't mind using wb in local variables, but in type names I would personally prefer more descriptive names. > >> + int h_dst = drm_rect_height(&primary_plane_info->dst); > >> int y_limit = y_src + h_dst; > >> + int y, i; > > > > It took me a while to understand that all these y-coordinates are CRTC > > coordinates. Maybe call them crtc_y, crtc_y_begin, crtc_y_end, > > crtc_y_height, etc. > > > >> + > >> + for (y = y_src; y < y_limit; y++) { > >> + plane_fmt_func[0](primary_plane_info, y, output_buffer); > > > > This is initializing output_buffer, right? So why do you have the TODO > > comment about clearing the primary plane above? > > > > Is it because the primary plane may not cover the CRTC exactly, the > > destination rectangle might be bigger or smaller? > > > > The output_buffer length should be the CRTC width, right? > > > > Maybe the special-casing the primary plane in this code is wrong. > > crtc_y needs to iterate over the CRTC height starting from zero. Then, > > you explicitly clear output_buffer to opaque background color, and > > primary plane becomes just another plane in the array of active planes > > with no special handling here. > > > > That will allow you to support overlay planes *below* the primary plane > > (as is fairly common in non-PC hardware), and you can even support the > > background color KMS property. > > I thought that the primary would always cover the entire screen exactly. Nope. Maybe PC hardware has such limitations, but I'm quite sure there are display controllers that do not require this. Therefore VKMS should support the more generic case, and possible offer a configuration knob to reject atomic state where primary plane is not active or not covering the whole CRTC in order to be able to test userspace against such driver behaviour. After all, background color KMS property exists. > > So yeah, my patch code assumes that CRTC is the same size as the primary plane. > (and if I'm not mistaken the current version also assumes it). > > But If this is not the case, where are the CRTC dimensions? > Are they in the CRTC properties? drm_mode_config? > > I couldn't find them. It's the active area of the current video mode, I believe. How that translated to DRM code, I don't know. > >> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c > >> new file mode 100644 > >> index 000000000000..0d1838d1b835 > >> --- /dev/null > >> +++ b/drivers/gpu/drm/vkms/vkms_formats.c > >> @@ -0,0 +1,138 @@ > >> +/* SPDX-License-Identifier: GPL-2.0+ */ > >> + > >> +#include <drm/drm_rect.h> > >> +#include "vkms_formats.h" > >> + > >> +format_transform_func get_fmt_transform_function(u32 format) > >> +{ > >> + if (format == DRM_FORMAT_ARGB8888) > >> + return &ARGB8888_to_ARGB16161616; > >> + else > >> + return &XRGB8888_to_ARGB16161616; > > > > In functions like this you should prepare for caller errors. Use a > > switch, and fail any attempt to use a pixel format it doesn't support. > > Failing is much better than silently producing garbage or worse: buffer > > overruns when bytes-per-pixel is not what you expected. > > > > What to do on failure depends on whether the failure here is never > > supposed to happen (follow the kernel style) e.g. malicious userspace > > cannot trigger it, or if you actually use this function to define the > > supported for pixel formats. > > No, I don't use this function to define supported formats, It's defined: > - vkms_writeback.c:15 > - vkms_plane.c:14 and 22 > > And if I'm not mistaken the DRM framework takes care of validation. Then someone else comes, adds a new pixel format to those files, and does not even realize get_fmt_transform_function() exists. If you know that something must already ensure you cannot get unsupported pixel formats in this function, then I guess some kind of kernel panic here if you do get an unsupported pixel format would be appropriate? Or an oops. That would tell loud and clear to that other person they overlooked something. Assuming they test the code the new format. > > > > > The latter means you'd have a list of all DRM pixel formats and then > > you'd ask for each one if this function knows it, and if yes, you add > > the format to the list of supported formats advertised to userspace. I > > don't know if that would be fine by DRM coding style. > > > >> +} > >> + > >> +format_transform_func get_wb_fmt_transform_function(u32 format) > >> +{ > >> + if (format == DRM_FORMAT_ARGB8888) > >> + return &convert_to_ARGB8888; > >> + else > >> + return &convert_to_XRGB8888; > >> +} > > > > I think you could move the above getter functions to the bottom of the > > .c file, and make all the four *_to_* functions static, and remove them > > from the header. > > OK. I will do that. > > Question, what's the benefits of using static functions? Making code more contained. When people see that a function is static, they know it won't be directly referenced from any other file. This makes understanding easier. It's hygiene too: make everything static that could be static. Sometimes it can also have other benefits, like the compiler automatically inlining the whole thing, and not even emitting the independent function code. It might also speed up linking, as a static function cannot be a target. > > > >> + > >> +static int pixel_offset(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(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(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); > >> +} > >> + > >> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, > >> + struct line_buffer *stage_buffer) > > > > I'm fairly sure that DRM will one day add exactly ARGB16161616 format. Oops, I think the format already exists. > > But that will not be the format you use here (or it might be, but > > purely accidentally and depending on machine endianess and whatnot), so > > I would suggest inventing a new name. Also use the same name for the > > struct to hold a single pixel. > > > > E.g. struct pixel_argb_u16 > > I'm terrible with names of variables, functions, etc. I will end-up with > ARGB8888_to_argb_u16. Sounds fine. > > I have a patch with the implementation of nv12 and YUV420 formats, but > I don't know how to test it because the ".*kms_plane@pixel-format*" igt test > doesn't support these formats (And also it isn't working anymore with my hack). > > Do you know how to test it? I think the best way would be to teach IGT to test it. Then everyone will automatically benefit from it. I don't really know anything about IGT code. FWIW, Weston has some YUV testing code I wrote in tests/yuv-buffer-test.c for the color conversions, but it's very limited scope (only BT.601, only limited range, and ignores chroma siting). Thanks, pq
Hi Pekka, On 2/25/22 05:38, Pekka Paalanen wrote: > On Thu, 24 Feb 2022 21:43:01 -0300 > Igor Torrente <igormtorrente@gmail.com> wrote: > >> Hi Pekka, >> >> On 2/10/22 06:37, Pekka Paalanen wrote: >>> On Fri, 21 Jan 2022 18:38:29 -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 >>>> 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 tests `*kms_cursor_crc*`: >>>> >>>> | Frametime | >>>> |:------------------------------------------:| >>>> | Implementation | Current | This commit | >>>> |:---------------:|:---------:|:------------:| >>>> | frametime range | 8~22 ms | 5~18 ms | >>>> | Average | 10.0 ms | 7.3 ms | >>>> >>>> Reported-by: kernel test robot <lkp@intel.com> >>>> Signed-off-by: Igor Torrente <igormtorrente@gmail.com> >>>> --- >>>> V2: Improves the performance drastically, by perfoming 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. >>>> --- >>>> drivers/gpu/drm/vkms/Makefile | 1 + >>>> drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- >>>> drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ >>>> drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ >>>> 4 files changed, 333 insertions(+), 172 deletions(-) >>>> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c >>>> create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h >>> >>> Hi Igor, >>> >>> I'm really happy to see this, thanks! >>> >>> I still have some security/robustness and other comments below. >>> >>> I've deleted all the minus lines from the patch to make the new code >>> more clear. >>> >>>> >>>> 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..9f70fcf84fb9 100644 >>>> --- a/drivers/gpu/drm/vkms/vkms_composer.c >>>> +++ b/drivers/gpu/drm/vkms/vkms_composer.c >>>> @@ -9,202 +9,210 @@ >>>> #include <drm/drm_vblank.h> >>>> >>>> #include "vkms_drv.h" >>>> +#include "vkms_formats.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_UP(new_color, 0xffff); >>> >>> Why round-up rather than the usual mathematical rounding? >> >> AFAIK, this is the only round that's present in the kernel. And if I >> understood correctly it is the round toward positive infinity that we are >> all used to use. > > Should be pretty easy to round-up from 0.5 and round-down otherwise. > Just add a different offset than DIV_ROUND_UP does. > > Not having a ready-made macro and habits are not good > justifications. The justification needs to be mathematical. Actually, I wasn't trying to argue about anything. Sorry if it sounded that way. Also, I had some confusion and I have to correct what I said. The DIV_ROUND_UP isn't the usual mathematical rounding, it's more like a round and ceiling. I don't know why I thought that was the usual rounding. > > The problem with DIV_ROUND_UP that I see, is that 0x00000001 gets > rounded to 0x0001, and anything that is even slightly above 0xfffe0000 > gets rounded to 0xffff. So it seems to me that this adds a bias to the > result. > > Is my intuition right or wrong, I'm not sure. I do know that > > 0xffff * 0xffff = 0xfffe0001 > > so values greater than 0xfffe0001 cannot occur. > > That seems to mean that there is exactly one 32-bit value that > DIV_ROUND_UPs to 0x0000 and exactly one 32-bit value that DIV_ROUND_UPs > to 0xffff. That doesn't feel right to me. > > Would need to compare to how the blending with real numbers would work. Yeah, I agree, it makes sense to me. I will change that, thanks! > > >>>> */ >>>> +static void blend(struct vkms_frame_info *wb_frame_info, >>> >>> Using "wb" as short for writeback is... well, it's hard for the me >>> remember at least. Could this not be named simply "writeback"? >> >> IMHO it's better to use wb instead of writeback for consistency. Given that wb >> is used throughout the vkms code. > > Right, so that's a problem for me. > > Is any other driver using wb for writeback? Apparently, yes. rcar_du_writeback.c:24:struct rcar_du_wb_conn_state { rcar_du_writeback.c:29:#define to_rcar_wb_conn_state rcar_du_writeback.c:219: struct rcar_du_wb_job *rjob; q1 komeda_wb_connector.c:111:komeda_wb_connector_detect(...) komeda_wb_connector.c:78:static const struct drm_encoder_helper_funcs komeda_wb_encoder_helper_funcs = {qq amdgpu_device.c:1095:static void amdgpu_device_wb_fini(...) > > I don't mind using wb in local variables, but in type names I would > personally prefer more descriptive names. > > >>>> + int h_dst = drm_rect_height(&primary_plane_info->dst); >>>> int y_limit = y_src + h_dst; >>>> + int y, i; >>> >>> It took me a while to understand that all these y-coordinates are CRTC >>> coordinates. Maybe call them crtc_y, crtc_y_begin, crtc_y_end, >>> crtc_y_height, etc. >>> >>>> + >>>> + for (y = y_src; y < y_limit; y++) { >>>> + plane_fmt_func[0](primary_plane_info, y, output_buffer); >>> >>> This is initializing output_buffer, right? So why do you have the TODO >>> comment about clearing the primary plane above? >>> >>> Is it because the primary plane may not cover the CRTC exactly, the >>> destination rectangle might be bigger or smaller? >>> >>> The output_buffer length should be the CRTC width, right? >>> >>> Maybe the special-casing the primary plane in this code is wrong. >>> crtc_y needs to iterate over the CRTC height starting from zero. Then, >>> you explicitly clear output_buffer to opaque background color, and >>> primary plane becomes just another plane in the array of active planes >>> with no special handling here. >>> >>> That will allow you to support overlay planes *below* the primary plane >>> (as is fairly common in non-PC hardware), and you can even support the >>> background color KMS property. >> >> I thought that the primary would always cover the entire screen exactly. > > Nope. Maybe PC hardware has such limitations, but I'm quite sure there > are display controllers that do not require this. Therefore VKMS should > support the more generic case, and possible offer a configuration knob > to reject atomic state where primary plane is not active or not > covering the whole CRTC in order to be able to test userspace against > such driver behaviour. > > After all, background color KMS property exists. Ok, makes sense. > >> >> So yeah, my patch code assumes that CRTC is the same size as the primary plane. >> (and if I'm not mistaken the current version also assumes it). >> >> But If this is not the case, where are the CRTC dimensions? >> Are they in the CRTC properties? drm_mode_config? >> >> I couldn't find them. > > It's the active area of the current video mode, I believe. How that > translated to DRM code, I don't know. I will try to find it. > > >>>> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c >>>> new file mode 100644 >>>> index 000000000000..0d1838d1b835 >>>> --- /dev/null >>>> +++ b/drivers/gpu/drm/vkms/vkms_formats.c >>>> @@ -0,0 +1,138 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0+ */ >>>> + >>>> +#include <drm/drm_rect.h> >>>> +#include "vkms_formats.h" >>>> + >>>> +format_transform_func get_fmt_transform_function(u32 format) >>>> +{ >>>> + if (format == DRM_FORMAT_ARGB8888) >>>> + return &ARGB8888_to_ARGB16161616; >>>> + else >>>> + return &XRGB8888_to_ARGB16161616; >>> >>> In functions like this you should prepare for caller errors. Use a >>> switch, and fail any attempt to use a pixel format it doesn't support. >>> Failing is much better than silently producing garbage or worse: buffer >>> overruns when bytes-per-pixel is not what you expected. >>> >>> What to do on failure depends on whether the failure here is never >>> supposed to happen (follow the kernel style) e.g. malicious userspace >>> cannot trigger it, or if you actually use this function to define the >>> supported for pixel formats. >> >> No, I don't use this function to define supported formats, It's defined: >> - vkms_writeback.c:15 >> - vkms_plane.c:14 and 22 >> >> And if I'm not mistaken the DRM framework takes care of validation. > > Then someone else comes, adds a new pixel format to those files, and > does not even realize get_fmt_transform_function() exists. > > If you know that something must already ensure you cannot get > unsupported pixel formats in this function, then I guess some kind of > kernel panic here if you do get an unsupported pixel format would be > appropriate? Or an oops. > > That would tell loud and clear to that other person they overlooked > something. Assuming they test the code the new format. Ok, got it. I will change it. > >> >>> >>> The latter means you'd have a list of all DRM pixel formats and then >>> you'd ask for each one if this function knows it, and if yes, you add >>> the format to the list of supported formats advertised to userspace. I >>> don't know if that would be fine by DRM coding style. >>> >>>> +} >>>> + >>>> +format_transform_func get_wb_fmt_transform_function(u32 format) >>>> +{ >>>> + if (format == DRM_FORMAT_ARGB8888) >>>> + return &convert_to_ARGB8888; >>>> + else >>>> + return &convert_to_XRGB8888; >>>> +} >>> >>> I think you could move the above getter functions to the bottom of the >>> .c file, and make all the four *_to_* functions static, and remove them >>> from the header. >> >> OK. I will do that. >> >> Question, what's the benefits of using static functions? > > Making code more contained. When people see that a function is static, > they know it won't be directly referenced from any other file. This > makes understanding easier. It's hygiene too: make everything static > that could be static. > > Sometimes it can also have other benefits, like the compiler > automatically inlining the whole thing, and not even emitting the > independent function code. It might also speed up linking, as a static > function cannot be a target. > >>> >>>> + >>>> +static int pixel_offset(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(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(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); >>>> +} >>>> + >>>> +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, >>>> + struct line_buffer *stage_buffer) >>> >>> I'm fairly sure that DRM will one day add exactly ARGB16161616 format. > > Oops, I think the format already exists. > >>> But that will not be the format you use here (or it might be, but >>> purely accidentally and depending on machine endianess and whatnot), so >>> I would suggest inventing a new name. Also use the same name for the >>> struct to hold a single pixel. >>> >>> E.g. struct pixel_argb_u16 >> >> I'm terrible with names of variables, functions, etc. I will end-up with >> ARGB8888_to_argb_u16. > > Sounds fine. > >> >> I have a patch with the implementation of nv12 and YUV420 formats, but >> I don't know how to test it because the ".*kms_plane@pixel-format*" igt test >> doesn't support these formats (And also it isn't working anymore with my hack). >> >> Do you know how to test it? > > I think the best way would be to teach IGT to test it. Then everyone > will automatically benefit from it. > > I don't really know anything about IGT code. > > FWIW, Weston has some YUV testing code I wrote in > tests/yuv-buffer-test.c for the color conversions, but it's very > limited scope (only BT.601, only limited range, and ignores chroma > siting). Right. I will do it later, As this patch series is already big enough. Best Regards, --- Igor Torrente > > > Thanks, > pq
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..9f70fcf84fb9 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -9,202 +9,210 @@ #include <drm/drm_vblank.h> #include "vkms_drv.h" +#include "vkms_formats.h" -static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer, - const struct vkms_frame_info *frame_info) +static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha) { - u32 pixel; - int src_offset = frame_info->offset + (y * frame_info->pitch) - + (x * frame_info->cpp); + u32 new_color; - pixel = *(u32 *)&buffer[src_offset]; + new_color = (src * 0xffff + dst * (0xffff - alpha)); - return pixel; + return DIV_ROUND_UP(new_color, 0xffff); } /** - * compute_crc - Compute CRC value on output frame + * 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 * - * @vaddr: address to final framebuffer - * @frame_info: framebuffer's metadata + * 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. * - * returns CRC value computed using crc32 on the visible portion of - * the final framebuffer at vaddr_out + * 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 uint32_t compute_crc(const u8 *vaddr, - const struct vkms_frame_info *frame_info) +static void pre_mul_alpha_blend(struct vkms_frame_info *frame_info, + struct line_buffer *stage_buffer, + struct line_buffer *output_buffer) { - int x, y; - u32 crc = 0, pixel = 0; - int x_src = frame_info->src.x1 >> 16; - int y_src = frame_info->src.y1 >> 16; - int h_src = drm_rect_height(&frame_info->src) >> 16; - int w_src = drm_rect_width(&frame_info->src) >> 16; - - for (y = y_src; y < y_src + h_src; ++y) { - for (x = x_src; x < x_src + w_src; ++x) { - pixel = get_pixel_from_buffer(x, y, vaddr, frame_info); - crc = crc32_le(crc, (void *)&pixel, sizeof(u32)); - } + int x, x_dst = frame_info->dst.x1; + int x_limit = drm_rect_width(&frame_info->dst); + struct line_buffer *out = output_buffer + x_dst; + struct line_buffer *in = stage_buffer; + + 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); } - - return crc; } -static u8 blend_channel(u8 src, u8 dst, u8 alpha) +static bool check_y_limit(struct vkms_frame_info *frame_info, int y) { - u32 pre_blend; - u8 new_color; - - pre_blend = (src * 255 + dst * (255 - alpha)); - - /* Faster div by 255 */ - new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8); + if (y >= frame_info->dst.y1 && y < frame_info->dst.y2) + return true; - return new_color; + return false; } /** - * alpha_blend - alpha blending equation - * @argb_src: src pixel on premultiplied alpha mode - * @argb_dst: dst pixel completely opaque - * - * blend pixels 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 alpha_blend(const u8 *argb_src, u8 *argb_dst) -{ - u8 alpha; - - alpha = argb_src[3]; - argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha); - argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha); - argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha); -} - -/** - * x_blend - blending equation that ignores the pixel alpha - * - * overwrites RGB color value from src pixel to dst pixel. - */ -static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst) -{ - memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3); -} - -/** - * blend - blend value at vaddr_src with value at vaddr_dst - * @vaddr_dst: destination address - * @vaddr_src: source address - * @dst_frame_info: destination framebuffer's metadata - * @src_frame_info: source framebuffer's metadata - * @pixel_blend: blending equation based on plane format + * @wb_frame_info: The writeback frame buffer metadata + * @wb_fmt_func: The format tranformatio function to the wb buffer + * @crtc_state: The crtc state + * @plane_fmt_func: A format tranformation function to each plane + * @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 src_compositor * - * Blend the vaddr_src value with the vaddr_dst value using a pixel blend - * equation according to the supported plane formats DRM_FORMAT_(A/XRGB8888) - * and clearing alpha channel to an completely opaque background. This function - * uses buffer's metadata to locate the new composite values at vaddr_dst. + * 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. * * TODO: completely clear the primary plane (a = 0xff) before starting to blend * pixel color values */ -static void blend(void *vaddr_dst, void *vaddr_src, - struct vkms_frame_info *dst_frame_info, - struct vkms_frame_info *src_frame_info, - void (*pixel_blend)(const u8 *, u8 *)) +static void blend(struct vkms_frame_info *wb_frame_info, + format_transform_func wb_fmt_func, + struct vkms_crtc_state *crtc_state, + format_transform_func *plane_fmt_func, + u32 *crc32, struct line_buffer *stage_buffer, + struct line_buffer *output_buffer, s64 row_size) { - int i, j, j_dst, i_dst; - int offset_src, offset_dst; - u8 *pixel_dst, *pixel_src; - - int x_src = src_frame_info->src.x1 >> 16; - int y_src = src_frame_info->src.y1 >> 16; - - int x_dst = src_frame_info->dst.x1; - int y_dst = src_frame_info->dst.y1; - int h_dst = drm_rect_height(&src_frame_info->dst); - int w_dst = drm_rect_width(&src_frame_info->dst); + 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_src = primary_plane_info->dst.y1; + int h_dst = drm_rect_height(&primary_plane_info->dst); int y_limit = y_src + h_dst; - int x_limit = x_src + w_dst; - - for (i = y_src, i_dst = y_dst; i < y_limit; ++i) { - for (j = x_src, j_dst = x_dst; j < x_limit; ++j) { - offset_dst = dst_frame_info->offset - + (i_dst * dst_frame_info->pitch) - + (j_dst++ * dst_frame_info->cpp); - offset_src = src_frame_info->offset - + (i * src_frame_info->pitch) - + (j * src_frame_info->cpp); - - pixel_src = (u8 *)(vaddr_src + offset_src); - pixel_dst = (u8 *)(vaddr_dst + offset_dst); - pixel_blend(pixel_src, pixel_dst); - /* clearing alpha channel (0xff)*/ - pixel_dst[3] = 0xff; + int y, i; + + for (y = y_src; y < y_limit; y++) { + plane_fmt_func[0](primary_plane_info, y, output_buffer); + + /* 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_fmt_func[i](plane[i]->frame_info, y, stage_buffer); + pre_mul_alpha_blend(plane[i]->frame_info, stage_buffer, + output_buffer); } - i_dst++; + + *crc32 = crc32_le(*crc32, (void *)output_buffer, row_size); + + if (wb_frame_info) + wb_fmt_func(wb_frame_info, y, output_buffer); } } -static void compose_plane(struct vkms_frame_info *primary_plane_info, - struct vkms_frame_info *plane_frame_info, - void *vaddr_out) +static void get_format_transform_functions(struct vkms_crtc_state *crtc_state, + format_transform_func plane_funcs[]) { - struct drm_framebuffer *fb = plane_frame_info->fb; - void *vaddr; - void (*pixel_blend)(const u8 *p_src, u8 *p_dst); + struct vkms_plane_state **active_planes = crtc_state->active_planes; + u32 n_active_planes = crtc_state->num_active_planes, s_fmt; + int i; - if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) - return; + for (i = 0; i < n_active_planes; i++) { + s_fmt = active_planes[i]->frame_info->fb->format->format; + plane_funcs[i] = get_fmt_transform_function(s_fmt); + } +} - vaddr = plane_frame_info->map[0].vaddr; +static bool check_planes_x_bounds(struct vkms_crtc_state *crtc_state, + struct vkms_frame_info *wb_frame_info) +{ + struct vkms_plane_state **planes = crtc_state->active_planes; + struct vkms_frame_info *primary_plane_info = planes[0]->frame_info; + int line_width = drm_rect_width(&primary_plane_info->dst); + u32 n_active_planes = crtc_state->num_active_planes; + int i; - if (fb->format->format == DRM_FORMAT_ARGB8888) - pixel_blend = &alpha_blend; - else - pixel_blend = &x_blend; + for (i = 0; i < n_active_planes; i++) { + int x_dst = planes[i]->frame_info->dst.x1; + int x_src = planes[i]->frame_info->src.x1 >> 16; + int x2_src = planes[i]->frame_info->src.x2 >> 16; + int x_limit = drm_rect_width(&planes[i]->frame_info->dst); - blend(vaddr_out, vaddr, primary_plane_info, - plane_frame_info, pixel_blend); + if (x_dst + x_limit > line_width) + return false; + if (x_src + x_limit > x2_src) + return false; + } + + return true; } -static int compose_active_planes(void **vaddr_out, - struct vkms_frame_info *primary_plane_info, - struct vkms_crtc_state *crtc_state) +static int compose_active_planes(struct vkms_frame_info *wb_frame_info, + struct vkms_crtc_state *crtc_state, + u32 *crc32) { - 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; + format_transform_func plane_funcs[NUM_OVERLAY_PLANES], wb_func = NULL; + int line_width, ret = 0, pixel_size = sizeof(struct line_buffer); + 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 (!*vaddr_out) { - *vaddr_out = kvzalloc(gem_obj->size, GFP_KERNEL); - if (!*vaddr_out) { - DRM_ERROR("Cannot allocate memory for output frame."); - return -ENOMEM; - } + if (WARN_ON(pixel_size != 8)) + 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; } + if (!primary_plane_info) + return -EINVAL; + if (WARN_ON(dma_buf_map_is_null(&primary_plane_info->map[0]))) return -EINVAL; - vaddr = primary_plane_info->map[0].vaddr; + if (WARN_ON(!check_planes_x_bounds(crtc_state, wb_frame_info))) + return -EINVAL; - memcpy(*vaddr_out, vaddr, gem_obj->size); + line_width = drm_rect_width(&primary_plane_info->dst); - /* 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 < crtc_state->num_active_planes; i++) - compose_plane(primary_plane_info, - crtc_state->active_planes[i]->frame_info, - *vaddr_out); + stage_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); + if (!stage_buffer) { + DRM_ERROR("Cannot allocate memory for the output line buffer"); + return -ENOMEM; + } - return 0; + output_buffer = kvmalloc(line_width * pixel_size, GFP_KERNEL); + if (!output_buffer) { + DRM_ERROR("Cannot allocate memory for intermediate line buffer"); + ret = -ENOMEM; + goto free_stage_buffer; + } + + get_format_transform_functions(crtc_state, plane_funcs); + + if (wb_frame_info) { + wb_format = wb_frame_info->fb->format->format; + wb_func = get_wb_fmt_transform_function(wb_format); + wb_frame_info->src = primary_plane_info->src; + wb_frame_info->dst = primary_plane_info->dst; + } + + blend(wb_frame_info, wb_func, crtc_state, plane_funcs, crc32, + stage_buffer, output_buffer, (s64)line_width * pixel_size); + + kvfree(output_buffer); +free_stage_buffer: + kvfree(stage_buffer); + + return ret; } /** @@ -222,13 +230,12 @@ 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_frame_info *wb_frame_info = &active_wb->frame_info; struct vkms_output *out = drm_crtc_to_vkms_output(crtc); - struct vkms_frame_info *primary_plane_info = NULL; - struct vkms_plane_state *act_plane = NULL; bool crc_pending, wb_pending; - void *vaddr_out = NULL; - u32 crc32 = 0; u64 frame_start, frame_end; + u32 crc32 = 0; int ret; spin_lock_irq(&out->composer_lock); @@ -248,35 +255,19 @@ void vkms_composer_worker(struct work_struct *work) if (!crc_pending) return; - 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; - } - - if (!primary_plane_info) - return; - if (wb_pending) - vaddr_out = crtc_state->active_writeback->data[0].vaddr; + ret = compose_active_planes(wb_frame_info, crtc_state, &crc32); + else + ret = compose_active_planes(NULL, crtc_state, &crc32); - ret = compose_active_planes(&vaddr_out, primary_plane_info, - crtc_state); - if (ret) { - if (ret == -EINVAL && !wb_pending) - kvfree(vaddr_out); + if (ret) return; - } - - crc32 = compute_crc(vaddr_out, primary_plane_info); 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); - } else { - kvfree(vaddr_out); } /* diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c new file mode 100644 index 000000000000..0d1838d1b835 --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_formats.c @@ -0,0 +1,138 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#include <drm/drm_rect.h> +#include "vkms_formats.h" + +format_transform_func get_fmt_transform_function(u32 format) +{ + if (format == DRM_FORMAT_ARGB8888) + return &ARGB8888_to_ARGB16161616; + else + return &XRGB8888_to_ARGB16161616; +} + +format_transform_func get_wb_fmt_transform_function(u32 format) +{ + if (format == DRM_FORMAT_ARGB8888) + return &convert_to_ARGB8888; + else + return &convert_to_XRGB8888; +} + +static int pixel_offset(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(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(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); +} + +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, + struct line_buffer *stage_buffer) +{ + u8 *src_pixels = get_packed_src_addr(frame_info, y); + int x, x_limit = drm_rect_width(&frame_info->dst); + + for (x = 0; x < x_limit; x++, src_pixels += 4) { + /* + * Organizes the channels in their respective positions and converts + * the 8 bits channel to 16. + * 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. + * And a similar idea applies to others RGB color conversions. + */ + stage_buffer[x].a = (u16)src_pixels[3] * 257; + stage_buffer[x].r = (u16)src_pixels[2] * 257; + stage_buffer[x].g = (u16)src_pixels[1] * 257; + stage_buffer[x].b = (u16)src_pixels[0] * 257; + } +} + +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, + struct line_buffer *stage_buffer) +{ + u8 *src_pixels = get_packed_src_addr(frame_info, y); + int x, x_limit = drm_rect_width(&frame_info->dst); + + for (x = 0; x < x_limit; x++, src_pixels += 4) { + stage_buffer[x].a = (u16)0xffff; + stage_buffer[x].r = (u16)src_pixels[2] * 257; + stage_buffer[x].g = (u16)src_pixels[1] * 257; + stage_buffer[x].b = (u16)src_pixels[0] * 257; + } +} + +/* + * The following functions take an line of ARGB16161616 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. + */ +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, + int y, struct line_buffer *src_buffer) +{ + int x, x_dst = frame_info->dst.x1; + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); + int x_limit = drm_rect_width(&frame_info->dst); + + 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_UP(src_buffer[x].a, 257); + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); + } +} + +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, + int y, struct line_buffer *src_buffer) +{ + int x, x_dst = frame_info->dst.x1; + u8 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y); + int x_limit = drm_rect_width(&frame_info->dst); + + for (x = 0; x < x_limit; x++, dst_pixels += 4) { + dst_pixels[3] = (u8)0xff; + dst_pixels[2] = DIV_ROUND_UP(src_buffer[x].r, 257); + dst_pixels[1] = DIV_ROUND_UP(src_buffer[x].g, 257); + dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257); + } +} diff --git a/drivers/gpu/drm/vkms/vkms_formats.h b/drivers/gpu/drm/vkms/vkms_formats.h new file mode 100644 index 000000000000..817e8b2124ae --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_formats.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef _VKMS_FORMATS_H_ +#define _VKMS_FORMATS_H_ + +#include "vkms_drv.h" + +struct line_buffer { + u16 a, r, g, b; +}; + +void ARGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, + struct line_buffer *stage_buffer); + +void XRGB8888_to_ARGB16161616(struct vkms_frame_info *frame_info, int y, + struct line_buffer *stage_buffer); + +void convert_to_ARGB8888(struct vkms_frame_info *frame_info, int y, + struct line_buffer *src_buffer); + +void convert_to_XRGB8888(struct vkms_frame_info *frame_info, int y, + struct line_buffer *src_buffer); + +typedef void (*format_transform_func)(struct vkms_frame_info *frame_info, int y, + struct line_buffer *buffer); + +format_transform_func get_fmt_transform_function(u32 format); + +format_transform_func get_wb_fmt_transform_function(u32 format); + +#endif /* _VKMS_FORMATS_H_ */
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 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 tests `*kms_cursor_crc*`: | Frametime | |:------------------------------------------:| | Implementation | Current | This commit | |:---------------:|:---------:|:------------:| | frametime range | 8~22 ms | 5~18 ms | | Average | 10.0 ms | 7.3 ms | Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Igor Torrente <igormtorrente@gmail.com> --- V2: Improves the performance drastically, by perfoming 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. --- drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 335 +++++++++++++-------------- drivers/gpu/drm/vkms/vkms_formats.c | 138 +++++++++++ drivers/gpu/drm/vkms/vkms_formats.h | 31 +++ 4 files changed, 333 insertions(+), 172 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h