A bit of a followup to my previous question about writeback connectors: On the Pi5/32Bit userland, I'm placing a 4K HEVC video together with a 3840x1080 GL framebuffer across two screens. The kmsprint output looks like this:
When I try to take a snapshot of (say) the first display, the next atomic commit enables the writeback CRTC, copies the display connector's mode and then assigns the framebuffers used on that display to the writeback CRTC. This works well with lower resolution content or with only a single display. When I try to do that with the above configuration, drmModeAtomicCommit fails with "No space left on device" and in dmesg I see
So I took a look at the kernel code. The line generating that error:
https://github.com/raspberrypi/linux/bl ... ane.c#L957
It seems to try to use drm_mm_insert_node_generic to insert something into &hvs->upm. Looking that up gets me to where I think that structure is initialized:
https://github.com/raspberrypi/linux/bl ... vs.c#L1773
The comment there made me wonder: It seems to use 1024 as a factor. But looking at /sys/kernel/debug/dri/1/hvs_regs gives meWhich is 2048, not 1024. I'm probably completely wrong about this, but is there maybe more memory available than currently used?
Code:
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 4 (100) fb-id: 304 (crtcs: 0 1 2 3) 0,0 1920x1080 -> 0,0 1920x1080 (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 304 3840x1080 AR24 Plane 6 (120) fb-id: 305 (crtcs: 0 1 2 3) 0,0 1920x1080 -> 0,0 1920x1080 (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 305 3840x2160 P030Connector 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 5 (110) fb-id: 304 (crtcs: 0 1 2 3) 1920,0 1920x1080 -> 0,0 1920x1080 (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 304 3840x1080 AR24 Plane 7 (130) fb-id: 305 (crtcs: 0 1 2 3) 1920,0 1920x1080 -> 0,0 1920x1080 (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 305 3840x2160 P030Code:
[ 5520.552495] vc4-drm axi:gpu: [drm] *ERROR* Failed to allocate UPM entry: -28https://github.com/raspberrypi/linux/bl ... ane.c#L957
It seems to try to use drm_mm_insert_node_generic to insert something into &hvs->upm. Looking that up gets me to where I think that structure is initialized:
https://github.com/raspberrypi/linux/bl ... vs.c#L1773
The comment there made me wonder: It seems to use 1024 as a factor. But looking at /sys/kernel/debug/dri/1/hvs_regs gives me
Code:
SCALER6_UBM_SIZE = 0x00000800Statistics: Posted by dividuum — Wed Jan 17, 2024 11:57 pm — Replies 0 — Views 102