Date:   Wed, 9 Feb 2022 16:21:07 +0100
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Javier Martinez Canillas <javierm@...hat.com>,
        linux-kernel@...r.kernel.org
Cc:     linux-fbdev@...r.kernel.org, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel@...ts.freedesktop.org,
        Noralf Trønnes <noralf@...nnes.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Maxime Ripard <maxime@...no.tech>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH v3 2/7] drm/format-helper: Add drm_fb_{xrgb8888,
 gray8}_to_mono_reversed()

Hi

Am 09.02.22 um 14:26 schrieb Javier Martinez Canillas:
> Hello Thomas,
> 
> Thanks a lot for your feedback.
> 
> On 2/9/22 13:51, Thomas Zimmermann wrote:
>> Hi
>>
> 
> [snip]
> 
>>> +
>>> +		if (xb == pixels - 1 && end_offset)
>>> +			end = end_offset;
>>
>> end_offset should be called end_len, because it is the number of bits in
>> the final byte; but not the offset of the final bit.
>>
> 
> Indeed.
> 
> [snip]
> 
>>> +void drm_fb_gray8_to_mono_reversed(void *dst, unsigned int dst_pitch, const void *vaddr,
>>> +				   const struct drm_framebuffer *fb,
>>> +				   const struct drm_rect *clip)
> 
> [snip]
> 
>>
>> Do you really need that function. It's not exported and if it's not
>> otherwise used, I'd just remove it.  We don't keep unused interfaces around.
>>
> 
> At the end after your suggestion of doing line-per-line conversions it is not
> needed, but since I already typed it and we were talking about adding other
> formats besides the fake XRGB8888 as an optimization (R8 for grayscale and
> Dx or something like that for reversed mono), I thought that would be useful
> to have it as a helper.
> 
> Also other drivers that want to advertise a R8 format could just use it and
> not having to add their own helper. But I'm happy to drop it in v4 if you
> think that's better to not have unused helpers.
> 
> It could be taken from this patch-set anyways if someone wants to wire the
> needed support for R8.

I think, policy is to not keep unused code around.

> 
> [snip]
> 
>>> +
>>> +	/*
>>> +	 * The reversed mono destination buffer contains 1 bit per pixel
>>> +	 * and destination scanlines have to be in multiple of 8 pixels.
>>> +	 */
>>> +	if (!dst_pitch)
>>> +		dst_pitch = DIV_ROUND_UP(linepixels, 8);
>>
>> I'd do a warn_once if (dst_pitch % 8 != 0).
>>
> 
> Agreed. I'll add a warning an mention that will be rounded up.
> 
>>
>>> +
>>> +	/*
>>> +	 * The cma memory is write-combined so reads are uncached.
>>> +	 * Speed up by fetching one line at a time.
>>
>> I once had a patchset that adds caching information to struct
>> dma_buf_map (soon to be named struct iosys_map).  Blitting helpers would
>> be able to enable/disable this optimization as needed.
>>
>> However, your driver doesn't use CMA. It's backed by SHMEM. Do you
>> really want to keep that code in?
>>
> 
> It doesn't but the repaper does. And since the plan was to make that driver
> to use the helper instead of having their own, I wanted to also make sure
> that would work well with CMA.

That makes sense then.

> 
>>
>>> +	 */
>>> +	src32 = kmalloc(len_src32, GFP_KERNEL);
>>> +	if (!src32)
>>> +		return;
>>> +
>>> +	/*
>>> +	 * Copies are done line-by-line, allocate an intermediate
>>> +	 * buffer to copy the gray8 lines and then convert to mono.
>>> +	 */
>>> +	gray8 = kmalloc(linepixels, GFP_KERNEL);
>>> +	if (!gray8)
>>> +		goto free_src32;
>>
>> If might be faster to allocate both buffers in one step and set the
>> pointers into the allocated buffer.
>>
> 
> Not sure I got this. Do you mean to have a single buffer with length
> linepixels + len_src32 and point src32 and gray8 to the same buffer ?

That's the idea. I don't know the exact overhead for kalloc(), but at 
least the in userspace, malloc() in hot code paths is not a good idea. 
There's usually some searching for free space involved.

In the long term, we could add a field in struct drm_framebuffer to keep 
such buffers around for reuse.

> 
>>> +
>>> +	/*
>>> +	 * For damage handling, it is possible that only parts of the source
>>> +	 * buffer is copied and this could lead to start and end pixels that
>>> +	 * are not aligned to multiple of 8.
>>> +	 *
>>> +	 * Calculate if the start and end pixels are not aligned and set the
>>> +	 * offsets for the reversed mono line conversion function to adjust.
>>> +	 */
>>> +	start_offset = clip->x1 % 8;
>>> +	end_offset = clip->x2 % 8;
>>
>> end_len, again. If you have 1 single bit set in the final byte, the
>> offset is 0, but the length is 1.
>>
> 
> Agreed, will change it too.

Feel free to add my

Reviewed-by: Thomas Zimmermann <tzimmermann@...e.de>

to the next version.

Best regards
Thomas

> 
> Best regards,

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)

Powered by blists - more mailing lists