On Tue, 22 Aug 2023 17:49:08 +0200 Jocelyn Falempe <jfalempe@xxxxxxxxxx> wrote: > On 22/08/2023 10:20, Pekka Paalanen wrote: > > On Mon, 21 Aug 2023 17:55:33 +0200 > > Maxime Ripard <mripard@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> > >>>>> --- > >>>>> 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? > 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. Thanks, pq
Attachment:
pgpFhUikF8bnZ.pgp
Description: OpenPGP digital signature
