On Tue, 26 Apr 2022 21:53:19 -0300
Igor Torrente <igormtorrente@xxxxxxxxx> wrote:
> Hi Pekka,
>
> On 4/21/22 07:58, Pekka Paalanen wrote:
> > On Mon, 4 Apr 2022 17:45:15 -0300
> > Igor Torrente <igormtorrente@xxxxxxxxx> 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 <igormtorrente@xxxxxxxxx>
> >> ---
> >> 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.
That's not all.
If you want it type-safe, then you need something like
struct vkms_fixed_point {
s32 value;
};
And use `struct vkms_fixed_point` (by value) everywhere where you pass
a fixed point value, and never as a plain s32 type. Then it will be
impossible to do incorrect arithmetic or conversions by accident on
fixed point values.
Is it worth it? I don't know, since it's limited into this one file.
A simple 'typedef s32 vkms_fixed_point' does not work, because it does
not prevent computing with vkms_fixed_point as if it was just a normal
s32. Using a struct prevents that.
I wonder if the kernel doesn't already have something like this
available in general...
> >> + 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.
Good point.
>
> >
> > 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.
...
> >> 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?
If it's a good thing, then it belongs in this series, because those
function getters are introduced in this series, opening the door for
the mistakes that the tests would prevent. I don't mean IGT tests but
kernel internal tests. I think there is a unit test framework?
You really should get a kernel maintainer's opinion on these questions,
as I am not a kernel developer.
Thanks,
pq
Attachment:
pgp0GkLNvqhsF.pgp
Description: OpenPGP digital signature
