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

[Pekka Paalanen]

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?

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230823/63c37301/attachment.sig>