On 23/08/2023 10:11, Pekka Paalanen wrote:
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?
Yes VRAM is between 4MB to 16MB, so the driver only expose dumb buffers
in system RAM, and PREFER_SHADOW is set to false.
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.
Ok thanks, I will move it to drm_plane then.
Thanks,
pq
Best regards,
--
Jocelyn
