Re: [PATCH v3 2/7] drm/format-helper: Add drm_fb_{xrgb8888, gray8}_to_mono_reversed()

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 4500 bytes --]

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@suse.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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]