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

[Michel Dänzer]

On 9/13/23 10:14, Jocelyn Falempe wrote:
> 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:
>>>>>>
>>>>>> 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)

Then any XRGB8888 → RGB888 conversion in user space has to result in worse performance.


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

I see consensus, with one person disagreeing.


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer