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@xxxxxxx> wrote: >>>> Am 08.09.23 um 16:41 schrieb Pekka Paalanen: >>>>> On Fri, 8 Sep 2023 15:56:51 +0200 >>>>> Thomas Zimmermann <tzimmermann@xxxxxxx> 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
