Hi Pekka,
On 4/21/22 07:58, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:15 -0300
Igor Torrente <igormtorre...@gmail.com> wrote:
Adds this common format to vkms.
This commit also adds new helper macros to deal with fixed-point
arithmetic.
It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.
V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements
Signed-off-by: Igor Torrente <igormtorre...@gmail.com>
---
drivers/gpu/drm/vkms/vkms_formats.c | 70 +++++++++++++++++++++++++++
drivers/gpu/drm/vkms/vkms_plane.c | 6 ++-
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +-
3 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 8d913fa7dbde..4af8b295f31e 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -5,6 +5,23 @@
#include "vkms_formats.h"
+/* The following macros help doing fixed point arithmetic. */
+/*
+ * With Fixed-Point scale 15 we have 17 and 15 bits of integer and fractional
+ * parts respectively.
+ * | 0000 0000 0000 0000 0.000 0000 0000 0000 |
+ * 31 0
+ */
+#define FIXED_SCALE 15
I think this would usually be called a "shift" since it's used in
bit-shifts.
Ok, I will rename this.
+
+#define INT_TO_FIXED(a) ((a) << FIXED_SCALE)
+#define FIXED_MUL(a, b) ((s32)(((s64)(a) * (b)) >> FIXED_SCALE))
+#define FIXED_DIV(a, b) ((s32)(((s64)(a) << FIXED_SCALE) / (b)))
A truncating div, ok.
+/* This macro converts a fixed point number to int, and round half up it */
+#define FIXED_TO_INT_ROUND(a) (((a) + (1 << (FIXED_SCALE - 1))) >> FIXED_SCALE)
Yes.
+/* Convert divisor and dividend to Fixed-Point and performs the division */
+#define INT_TO_FIXED_DIV(a, b) (FIXED_DIV(INT_TO_FIXED(a), INT_TO_FIXED(b)))
Ok, this is obvious to read, even though it's the same as FIXED_DIV()
alone. Not sure the compiler would optimize that extra bit-shift away...
If one wanted to, it would be possible to write type-safe functions for
these so that fixed and integer could not be mixed up.
Ok, I will move to a function.
+
static int pixel_offset(const struct vkms_frame_info *frame_info, int x, int
y)
{
return frame_info->offset + (y * frame_info->pitch)
@@ -112,6 +129,30 @@ static void XRGB16161616_to_argb_u16(struct line_buffer
*stage_buffer,
}
}
+static void RGB565_to_argb_u16(struct line_buffer *stage_buffer,
+ const struct vkms_frame_info *frame_info, int y)
+{
+ struct pixel_argb_u16 *out_pixels = stage_buffer->pixels;
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x, x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ stage_buffer->n_pixels);
+
+ for (x = 0; x < x_limit; x++, src_pixels++) {
+ u16 rgb_565 = le16_to_cpu(*src_pixels);
+ int fp_r = INT_TO_FIXED((rgb_565 >> 11) & 0x1f);
+ int fp_g = INT_TO_FIXED((rgb_565 >> 5) & 0x3f);
+ int fp_b = INT_TO_FIXED(rgb_565 & 0x1f);
+
+ int fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+ int fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
These two should be outside of the loop since they are constants.
Likely no difference for performance because the compiler is probably
doing that already, but I think it would read better.
I will move it.
+
+ out_pixels[x].a = (u16)0xffff;
+ out_pixels[x].r = FIXED_TO_INT_ROUND(FIXED_MUL(fp_r,
fp_rb_ratio));
+ out_pixels[x].g = FIXED_TO_INT_ROUND(FIXED_MUL(fp_g,
fp_g_ratio));
+ out_pixels[x].b = FIXED_TO_INT_ROUND(FIXED_MUL(fp_b,
fp_rb_ratio));
Looks good.
+ }
+}
+
/*
* The following functions take an line of argb_u16 pixels from the
@@ -199,6 +240,31 @@ static void argb_u16_to_XRGB16161616(struct
vkms_frame_info *frame_info,
}
}
+static void argb_u16_to_RGB565(struct vkms_frame_info *frame_info,
+ const struct line_buffer *src_buffer, int y)
+{
+ int x, x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ struct pixel_argb_u16 *in_pixels = src_buffer->pixels;
+ int x_limit = min_t(size_t, drm_rect_width(&frame_info->dst),
+ src_buffer->n_pixels);
+
+ for (x = 0; x < x_limit; x++, dst_pixels++) {
+ int fp_r = INT_TO_FIXED(in_pixels[x].r);
+ int fp_g = INT_TO_FIXED(in_pixels[x].g);
+ int fp_b = INT_TO_FIXED(in_pixels[x].b);
+
+ int fp_rb_ratio = INT_TO_FIXED_DIV(65535, 31);
+ int fp_g_ratio = INT_TO_FIXED_DIV(65535, 63);
Move these out of the loop.
+
+ u16 r = FIXED_TO_INT_ROUND(FIXED_DIV(fp_r, fp_rb_ratio));
+ u16 g = FIXED_TO_INT_ROUND(FIXED_DIV(fp_g, fp_g_ratio));
+ u16 b = FIXED_TO_INT_ROUND(FIXED_DIV(fp_b, fp_rb_ratio));
+
+ *dst_pixels = cpu_to_le16(r << 11 | g << 5 | b);
Looks good.
You are using signed variables (int, s64, s32) when negative values
should never occur. It doesn't seem wrong, just unexpected.
I left the signal so I can reuse them in the YUV formats.
The use of int in code vs. s32 in the macros is a bit inconsistent as
well.
Right. I think I will stick with s32 and s64 then.
+ }
+}
+
plane_format_transform_func get_plane_fmt_transform_function(u32 format)
{
if (format == DRM_FORMAT_ARGB8888)
@@ -209,6 +275,8 @@ plane_format_transform_func
get_plane_fmt_transform_function(u32 format)
return &ARGB16161616_to_argb_u16;
else if (format == DRM_FORMAT_XRGB16161616)
return &XRGB16161616_to_argb_u16;
+ else if (format == DRM_FORMAT_RGB565)
+ return &RGB565_to_argb_u16;
else
return NULL;
}
@@ -223,6 +291,8 @@ wb_format_transform_func get_wb_fmt_transform_function(u32
format)
return &argb_u16_to_ARGB16161616;
else if (format == DRM_FORMAT_XRGB16161616)
return &argb_u16_to_XRGB16161616;
+ else if (format == DRM_FORMAT_RGB565)
+ return &argb_u16_to_RGB565;
Now it's starting to become clear that a switch statement would be nice.
else
return NULL;
}
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index 60054a85204a..94a8e412886f 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -14,14 +14,16 @@
static const u32 vkms_formats[] = {
DRM_FORMAT_XRGB8888,
- DRM_FORMAT_XRGB16161616
+ DRM_FORMAT_XRGB16161616,
+ DRM_FORMAT_RGB565
};
static const u32 vkms_plane_formats[] = {
DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
DRM_FORMAT_XRGB16161616,
- DRM_FORMAT_ARGB16161616
+ DRM_FORMAT_ARGB16161616,
+ DRM_FORMAT_RGB565
};
static struct drm_plane_state *
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index cb63a5da9af1..98da7bee0f4b 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -16,7 +16,8 @@
static const u32 vkms_wb_formats[] = {
DRM_FORMAT_XRGB8888,
DRM_FORMAT_XRGB16161616,
- DRM_FORMAT_ARGB16161616
+ DRM_FORMAT_ARGB16161616,
+ DRM_FORMAT_RGB565
};
static const struct drm_connector_funcs vkms_wb_connector_funcs = {
I wonder, would it be possible to add a unit test to make sure that
get_plane_fmt_transform_function() or get_wb_fmt_transform_function()
does not return NULL for any of the listed formats, respectively?
Or is that too paranoid?
I'm not opposed to it. But I also don't think it needs to be in this
series of patches either.
A new todo maybe?
Thanks,
pq
