[PATCH v3] drm/plane: Add documentation about software color conversion.

[Jocelyn Falempe]

On 12/09/2023 17:57, Michel Dänzer wrote:
> On 9/11/23 10:38, Pekka Paalanen wrote:
>> On Fri, 8 Sep 2023 17:10:46 +0200
>> Thomas Zimmermann <tzimmermann at suse.de> wrote:
>>> Am 08.09.23 um 16:41 schrieb Pekka Paalanen:
>>>> On Fri, 8 Sep 2023 15:56:51 +0200
>>>> Thomas Zimmermann <tzimmermann at suse.de> wrote:
>>>>>
>>>>> I have a number of concerns. My point it not that we shouldn't optimize.
>>>>> I just don't want it in the kernel. Mgag200 can export DRM_FORMAT_RGB888
>>>>> for userspace to use.
>>>>>
>>>>> AFAICT the main argument against userspace is that Mesa doesn't like
>>>>> 3-byte pixels. But I don't see how this conversion cannot be a
>>>>> post-processing step within Mesa: do the rendering in RGB32 and then
>>>>> convert to a framebuffer in RGB24.
> 
> Even assuming the conversion could be handled transparently in Mesa, it would still require the KMS client to pick RGB888 instead of XRGB8888. Most (all?) KMS clients support XRGB8888, many of them will realistically never support RGB888. (Or even if they did, they might prefer XRGB8888 anyway, if RGB888 requires a final conversion step)
> 
> 
>>>>> Another point of concern is CPU consumption: Slow I/O buses may stall
>>>>> the display thread, but the CPU could do something else in the meantime.
>>>>> Doing format conversion on the CPU prevents that, hence affecting other
>>>>> parts of the system negatively. Of course, that's more of a gut feeling
>>>>> than hard data.
> 
> Jocelyn, have you measured if the XRGB8888 -> RGB888 conversion copy takes longer than a straight RGB888 -> RGB888 copy in the kernel?
> 
> 

At least on my Matrox system, the conversion is really negligible 
compared to the copy, due to slow memory bandwidth. I wasn't able to see 
a difference, using ktime_get_ns().

The CPU is an old Intel(R) Core(TM) i3 CPU 540  @ 3.07GHz
in 1280x1024, the RGB888 copy takes 95ms.
and the XRGB8888->RGB888 takes also 95ms.
(and the full XRGB8888 copy takes 125ms)

Also we say "conversion", but when talking about XRGB8888->RGB888, there 
is no math involved, only dropping one bytes every 4.

But really performance is not the main concern here as it is obvious 
that it's much faster in RGB888. I tried to summarize the other 
arguments below, which I still find not convincing:
  * The driver is already fast enough, if you want faster, buy another GPU.
  * This adds too much complexity in the driver (about ~20 lines of code)
  * It breaks an unwritten rule of not changing the color format inside 
the kernel (which I tried to write with this patch, while adding an 
exception for legitimate use cases, like this one).

But let's admit that this discussion is going nowhere, and that I failed 
to reach a consensus, so I'm now focusing on other things.

Best regards,

-- 

Jocelyn