[PATCH 1/1] drm/fourcc: Add documentation about software color conversion.

[Jocelyn Falempe]

On 23/08/2023 10:11, Pekka Paalanen wrote:
> On Tue, 22 Aug 2023 17:49:08 +0200
> Jocelyn Falempe <jfalempe at redhat.com> wrote:
> 
>> On 22/08/2023 10:20, Pekka Paalanen wrote:
>>> On Mon, 21 Aug 2023 17:55:33 +0200
>>> Maxime Ripard <mripard at kernel.org> wrote:
>>>    
>>>> Hi Pekka,
>>>>
>>>> Thanks for answering
>>>>
>>>> On Fri, Aug 18, 2023 at 04:24:15PM +0300, Pekka Paalanen wrote:
>>>>> On Thu, 10 Aug 2023 09:45:27 +0200
>>>>> Maxime Ripard <mripard at kernel.org> wrote:
>>>>>> On Mon, Aug 07, 2023 at 03:45:15PM +0200, Jocelyn Falempe wrote:
>>>>>>> After discussions on IRC, the consensus is that the DRM drivers should
>>>>>>> not do software color conversion, and only advertise the supported formats.
>>>>>>> Update the doc accordingly so that the rule and exceptions are clear for
>>>>>>> everyone.
>>>>>>>
>>>>>>> Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com>
>>>>>>> ---
>>>>>>>    include/uapi/drm/drm_fourcc.h | 7 +++++++
>>>>>>>    1 file changed, 7 insertions(+)
> 
> ...
> 
>>> In the XRGB8888 to RGB888 case, the kernel doing the conversion may
>>> allow for higher resolutions, but it may also hurt framerate more than
>>> userspace doing conversion, theoretically. For lower resolution where
>>> XRGB8888 could be scanned out directly from VRAM, the conversion would
>>> be strictly hurting.
>>>    
>> I think that depends on the hardware. For the Matrox, the bandwidth
>> between system RAM and VRAM is so low, that doing the conversion is much
>> faster than copying XRGB8888 to the VRAM. It also uses less CPU cycles,
>> because the copy is done with memcpy(), (DMA is broken or even slower on
>> most mgag200 hardware).
>> To get numbers, on my test machine, copying the 5MB framebuffer XRGB8888
>> to VRAM takes 125ms. Copying 3.75MB RGB888 framebuffer takes 95ms. The
>> conversion has no measurable impact, as it is done on the fly during the
>> memcpy, when the CPU is waiting for the bus to accept more data.
>> Doing the conversion in user-space would actually be slower, even with
>> SSE, because they won't use the "wasted" cpu cycle. But anyway the
>> conversion can take a few micro-seconds on the CPU, which is still
>> negligible compared to the memory transfer.
> 
> I stand corrected!
> 
> Always exceptions. :-)
> 
> I suppose you have dumb alloc returning sysmem, and PREFER_SHADOW set
> to false to go with that? Sounds good for XRGB8888. I guess there is
> not enough VRAM to alloc dumb buffers from there anyway?

Yes VRAM is between 4MB to 16MB, so the driver only expose dumb buffers 
in system RAM, and PREFER_SHADOW is set to false.

> 
>> Before sending the v2, Simon Ser proposed to move the paragraph to
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_plane.c#L132
>> instead of fourcc.h.
>> I'm wondering what other thinks about this.
> 
> I like moving it out of drm_fourcc.h. drm_fourcc.h is about format
> definitions which are used by things like EGL, Wayland, and whatnot
> which are not KMS specific.

Ok thanks, I will move it to drm_plane then.

> 
> 
> Thanks,
> pq


Best regards,

-- 

Jocelyn