Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 7503

Advanced users • VC4 LBM memory size too small on Pi5?

$
0
0
Hi.

I'm trying to run two 90 degree rotated 4K displays. The logical canvas size across both display is therefore a 90 degree rotated output of 3840x(2*2160) => 3840x4320 pixels. Unfortunately that exceeds the maximum GL texture/viewport size which is seems to be limited to 4096x4096. While I can create a GBM surface larger than that, I don't seem to be able to render anything

I then render this framebuffer to both displays:

One with:

Code:

crtc-pos=3840x2160+0+0src-pos=3640.000000x2048.000000+0.000000+0.000000
The other with:

Code:

crtc-pos=3840x2160+0+0src-pos=3640.000000x2048.000000+0.000000+2048.000000
This works well, although the non-integer scaling is definitely visible. Looking at the DRM log, each plane seems to consume 455 bytes(?) of LBM memory:

Code:

[PLANE:116:plane-5] LBM Allocation Size: 455
In the hvs_lbm debug output, I see:

Code:

...handle 1: refcount 2, size 455 [00000000 + 000001c7]handle 2: refcount 2, size 455 [000001c7 + 000001c7]...
So a total of 910 bytes is used to render this configuration. Now looking at the source code, it seems 1024 bytes is available in total:

Code:

case VC4_GEN_6_C:case VC4_GEN_6_D:    /*     * If we are running a test, it means that we can't     * access a register. Use a plausible size then.     */    lbm_size = 1024;
My code also allows snapshotting the output using the writeback connector. Doing this now requires rendering a third plane. The resulting total LBM size is 3*455, which then exceeds the 1024 bytes available:

Code:

vc4-drm axi:gpu: [drm:vc4_plane_atomic_check [vc4]] [PLANE:46:plane-0] LBM Allocation Size: 455vc4-drm axi:gpu: [drm] *ERROR* Failed to allocate LBM entry: -28vc4-drm axi:gpu: [drm:drm_atomic_helper_check_planes [drm_kms_helper]] [PLANE:46:plane-0] atomic driver check failedvc4-drm axi:gpu: [drm:drm_atomic_check_only [drm]] atomic driver check for 00000000600257b8 failed: -2
Now looking at the 1024 bytes limit, I'm not sure it's correct. The comment "If we are running a test" seems wrong as there's no condition that checks for a test, unlike a similar construct in another function of the same file where the comment makes more sense:

Code:

/* * If we are running a test, it means that we can't * access a register. Use a plausible size then. */if (!kunit_get_current_test())    dlist_size = HVS_READ(SCALER6_CXM_SIZE);else    dlist_size = 4096;
So 1024 seems the plausible size, but is it also the correct one? Looking at sysfs hvs_regs debug output, there's:

Code:

SCALER6_LBM_SIZE = 0x00000800
which seems to indicate that the LBM_SIZE is 2048 bytes instead of 1024, which would solve my problem above? Should the lbm_size initialization probe for kunit_get_current_test() and then also read the size with something like HVS_READ(SCALER6_LBM_SIZE) instead of using a hardcoded constant?

Statistics: Posted by dividuum — Wed Jan 21, 2026 5:16 pm — Replies 2 — Views 43



Viewing all articles
Browse latest Browse all 7503

Trending Articles