Re: [PATCH v5 9/9] drm: vkms: Add support to the RGB565 format

[Igor Torrente <igormtorrente@gmail.com>]

On 5/9/22 04:53, Pekka Paalanen wrote:
> On Fri, 6 May 2022 20:05:39 -0300
> Igor Torrente <igormtorrente@gmail.com> wrote:
> 
>> Hi Pekka,
>>
>> On 4/27/22 04:55, Pekka Paalanen wrote:
>>> On Tue, 26 Apr 2022 21:53:19 -0300
>>> Igor Torrente <igormtorrente@gmail.com> wrote:
>>>    
>>>> Hi Pekka,
>>>>
>>>> On 4/21/22 07:58, Pekka Paalanen wrote:
>>>>> On Mon,  4 Apr 2022 17:45:15 -0300
>>>>> Igor Torrente <igormtorrente@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 <igormtorrente@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.
>>>
>>> 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.
>>
>> ohhh. Got it!
>>
>>>
>>> I wonder if the kernel doesn't already have something like this
>>> available in general...
>>
>> After some time searching I found `include/drm/drm_fixed.h`[1].
>>
>> It seems fine. There are minor things to consider:
>>
>> 1. It doesn't have a `FIXED_TO_INT_ROUND` equivalent.
>> 2. We can use `fixed20_12` for rgb565 but We have to use s64 for YUV
>> formats or add a `sfixed20_12` with s32.
>>
>> In terms of consistency, do you think worth using this "library" given
>> that we may need to use two distinct ways to represent the fixed point
>> soonish? Or it's better to implement `sfixed20_12`? Or just continue
>> with the
>> current macros?
>>
>> [1] - https://elixir.bootlin.com/linux/latest/source/include/drm/drm_fixed.h
> 
> I think that is something the kernel people should weigh in on.
> 
> The one thing I would definitely avoid is ending up using multiple
> fixed point formats in VKMS.
> 
> In the mean time, your current macros seem good enough, if there is no
> community interest in better type safety nor sharing the fixed point
> code.

OK. Thanks!

> 
> 
> Thanks,
> pq