Visual artifacts when placing transparent planes across multiple CRTCs on Pi5

[dividuum]

Describe the bug

When running my software info-beamer I noticed an odd flickering when using transparent planes across multiple CRTCs. This only happens on the Pi5. The same SD card on the Pi4 works as expected. Basically the output looks like this:

The artifacts are not always the same. Restarting the program results in a different output. For example like this:

It's also only static when the plane placement doesn't change. Once I change the plane's coordinates, things look even stranger: Here's a short (1.4MB) video showing the effect.

What my software is doing is placing a DRM framebuffer (in this case a YU12, but the same thing happens with P030) onto both CRTCs. kmsprint looks like this:

Connector 0 (32) HDMI-A-1 (connected)
  Encoder 0 (31) TMDS
    Crtc 2 (88) 1920x1080@60.00 148.500 1920/88/44/148/+ 1080/4/5/36/+ 60 (60.00) P|D 
      Plane 6 (120) fb-id: 308 (crtcs: 0 1 2 3) 0,0 560x320 -> 25,10 1870x1060 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12)
        FB 308 560x320 YU12
Connector 1 (42) HDMI-A-2 (connected)
  Encoder 1 (41) TMDS
    Crtc 3 (99) 1920x1080@60.00 148.500 1920/88/44/148/+ 1080/4/5/36/+ 60 (60.00) P|D 
      Plane 7 (130) fb-id: 308 (crtcs: 0 1 2 3) 0,0 560x320 -> 25,10 1870x1060 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12)
        FB 308 560x320 YU12

The commands I use for my drm atomic commits look like this:

atomic (plane->plane_id) 120 (plane->FB_ID prop-id:17) (layer->fb_id) => 308
atomic (plane->plane_id) 120 (plane->CRTC_ID prop-id:20) (layer->crtc_id) => 88
atomic (plane->plane_id) 120 (plane->SRC_X prop-id:9) (layer->src.x << 16) => 0
atomic (plane->plane_id) 120 (plane->SRC_Y prop-id:10) (layer->src.y << 16) => 0
atomic (plane->plane_id) 120 (plane->SRC_W prop-id:11) (layer->src.w << 16) => 36700160 // that's 560
atomic (plane->plane_id) 120 (plane->SRC_H prop-id:12) (layer->src.h << 16) => 20971520 // that's 320
atomic (plane->plane_id) 120 (plane->CRTC_X prop-id:13) (layer->crtc.x) => 25
atomic (plane->plane_id) 120 (plane->CRTC_Y prop-id:14) (layer->crtc.y) => 10
atomic (plane->plane_id) 120 (plane->CRTC_W prop-id:15) (layer->crtc.w) => 1870
atomic (plane->plane_id) 120 (plane->CRTC_H prop-id:16) (layer->crtc.h) => 1060
atomic (plane->plane_id) 120 (plane->rotation prop-id:124) (rotation) => 1
atomic (plane->plane_id) 120 (plane->zpos prop-id:129) (layer->zpos) => 4
atomic (plane->plane_id) 120 (plane->alpha prop-id:122) ((int)(layer->alpha * 0xffff)) => 58981
[.. same values for the other plane on the other crtc...]

In /sys/kernel/debug/dri/1/state it looks like this:

plane[120]: plane-6
        crtc=crtc-2
        fb=308
                allocated by = info-beamer
                refcount=3
                format=YU12 little-endian (0x32315559)
                modifier=0x0
                size=560x320
                layers:
                        size[0]=560x320
                        pitch[0]=576
                        offset[0]=0
                        obj[0]:
                                name=0
                                refcount=3
                                start=00101bb0
                                size=278528
                                imported=no
                                dma_addr=0x0000000a7d780000
                                vaddr=00000000ac06717a
                        size[1]=280x160
                        pitch[1]=288
                        offset[1]=184320
                        obj[1]:
                                name=0
                                refcount=3
                                start=00101bb0
                                size=278528
                                imported=no
                                dma_addr=0x0000000a7d780000
                                vaddr=00000000ac06717a
                        size[2]=280x160
                        pitch[2]=288
                        offset[2]=230400
                        obj[2]:
                                name=0
                                refcount=3
                                start=00101bb0
                                size=278528
                                imported=no
                                dma_addr=0x0000000a7d780000
                                vaddr=00000000ac06717a
        crtc-pos=1870x1060+25+10
        src-pos=560.000000x320.000000+0.000000+0.000000
        rotation=1
        normalized-zpos=0
        color-encoding=ITU-R BT.709 YCbCr
        color-range=YCbCr limited range

Using alpha 1, so 0xffff as plane alpha property value seems to work. Similarly only using a single CRTC also works regardless of alpha used.

Adding another opaque plane behind the transparent plane also does not make any difference.

Steps to reproduce the behaviour

Created a minimal test case bundle. Download issue-5912.tgz and extract it anywhere. Stop X/Wayland, so KMS/DRM is free to use and connect two FullHD capable displays, then run ./run-testcase.

Device (s)

Raspberry Pi 5

System

32bit userland Raspberry Pi OS, all updates installed:

pi@raspberrypi:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2023-10-10
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, fb56ad562991cf3ae5c96ab50983e1deeaefc7b6, stage4

pi@raspberrypi:~ $ vcgencmd version
2024/01/22 14:44:36 
Copyright (c) 2012 Broadcom
version e891ded6 (release) (embedded)

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.1.0-rpi8-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux

Logs

No response

Additional context

No response

[dividuum]

I've added a testcase, so this should hopefully be easily reproducible.

[popcornmix]

I can reproduce this. On a quick look I suspect the LBM (line buffer memory used for vertical scaling) is being overwritten by the second display.

I'll dig some more.

[popcornmix]

I believe I have a fix. if you wait about an hour for github CI to complete build, you can run:

sudo rpi-update pulls/5963

to install a test kernel with the fix in. Please report if it helps.

[dividuum]

I can hopefully test this next week, but from the description/diff it sounds good. Thanks a lot!

[dividuum]

Got around to finally test this (in a local 6.1 branch) and it fixes the issue as expected. Thanks! Would it be possible to also have an official fix for the 6.1 version?