10bittest on the Raspberry Pi 3

[carlonluca]

Hello,
I would like to test how DRM writeback works on the Raspberry Pi 3. I therefore tried to run 10bittest on a Raspberry Pi 3, and this is what I got:

$ sudo ./10bittest -w -v
../drmu/drmu_xlease.c:26:get_lease_fd: Failed to get XCB RandR version
../drmu/drmu_xlease.c:138:drmu_env_new_xlease: Failed to get xlease
../drmu/drmu_output.c:512:drmu_output_add_writeback: 0: try HDMI-A-1
../drmu/drmu_output.c:512:drmu_output_add_writeback: 1: try WRITEBACK-1
../drmu/drmu_output.c:532:drmu_output_add_writeback: try Crtc 0
Try writeback 1920x1080
../drmu/drmu.c:1576:drmu_fb_new_dumb_mod: Create dumb 0x5616c8 AR24 1920x1080 / 1920x1080 size: 8294400
Use hi bits per channel: yes
Colorspace: BT2020_RGB, Broadcast RGB: Full
Cannot find plane to support AB30 mod 0

I therefore tried:

$ sudo ./10bittest -P AB24 -w -v
../drmu/drmu_xlease.c:26:get_lease_fd: Failed to get XCB RandR version
../drmu/drmu_xlease.c:138:drmu_env_new_xlease: Failed to get xlease
../drmu/drmu_output.c:512:drmu_output_add_writeback: 0: try HDMI-A-1
../drmu/drmu_output.c:512:drmu_output_add_writeback: 1: try WRITEBACK-1
../drmu/drmu_output.c:532:drmu_output_add_writeback: try Crtc 0
Try writeback 1920x1080
../drmu/drmu.c:1576:drmu_fb_new_dumb_mod: Create dumb 0x168d6c8 AR24 1920x1080 / 1920x1080 size: 8294400
Use hi bits per channel: yes
Colorspace: BT2020_RGB, Broadcast RGB: Full
../drmu/drmu.c:1576:drmu_fb_new_dumb_mod: Create dumb 0x168d8b8 AB24 1920x1080 / 1920x1080 size: 8294400
RGB encoding: ITU-R BT.2020 YCbCr, range YCbCr full range
Failed to commit writeback

Do you happen to know if the Raspberry Pi 3 supports DRM writeback? Or maybe do you have any idea of what changes could be applied to 10bittest to make it run on the Raspberry Pi 3?

Thank you for your work!

[jc-kynesim]

I'm not surprised by the 1st failure - it is tying to use a 10-bit plane and the Pi3 won't support that (the hint is in the test name!). I admit it now does a lot more than when I first wrote it, but the default still does that. The writeback fail is a bit unexpected - I'll investigate.

[jc-kynesim]

The writeback fail may be a DRM driver issue on the Pi3 (your command line works fine on Pi4/5) - I believe it should work. I've kicked the problem on to someone who knows more than I do and will report back when I know more.

[carlonluca]

Thank you very much for your help.

[jc-kynesim]

OK - it is the DRM driver which, as I understand it, thinks it doesn't have enough free cycles to complete the request. It can be forced to ignore that with sudo -c 'echo N > /sys/kernel/debug/dri/0/hvs_load_tracker' and the code will work. However I strongly recommend you only use that command as proof of concept as the load tracker is there for a reason, I'm not sure what the consequences are but random system lockups don't seem implausible. I believe that a proper fix will be `forthcoming - wait for that for any real use. If at all possible use a Pi4 for now.

[carlonluca]

I see, thanks!

My next question will probably be a bit OT in this issue, but I take my chances anyway: would you say DRM writeback is the only reasonable alternative to the old vc_dispmanx_snapshot + vc_dispmanx_resource_read_data? Other options that I tried seem to be extremely slow.

Thank you very much for your time. At this point, the issue can probably be closed.

[jc-kynesim]

Honestly I dunno. I don't actually know what exactly those calls did, but I'm going to guess that writeback is pretty much equivalent. I don't think that you can simply use this to snapshot the current output as I don't think you can attach the writeback connector to the current output in addition to an active display (on a Pi). This is certainly a fast way of compositing a number of planes. If you care about arm performance on the buffer then you might want to use fbs from the dmabuf allocator (drmu_dmabuf_env_new_fd - sorry about the lack of docn in that api currently) rather than the dumb allocator as dmabuf fbs will be cached in arm space and dumb ones won't - however you must remember to use drmu_fb_read_start/end to ensure contents are correctly flushed if you are using dmabufs.

[carlonluca]

My idea was to attach the writeback when my DRM master (an OpenGL app) was starting. It would be my DRM master to do everything. Isn't this possible?

My current implementation opens the dri device, uses drmPrimeHandleToFD and then mmaps the buffer. Unfortunately this is extremely slow as I need to handle a tiled buffer. To give you an idea, dispmanx required around 10ms, now I am at 130ms.

DRM writeback seemed faster, but at this point it seems I need to look for something else.

[jc-kynesim]

Actually writeback might work for that give it a go - if you have a buffer in you hand that the HVS can read then it'll convert it to RGB.
But having said that GL should be able to produce scanout (linear) buffers directly - the standard .kmscube demo does this - it passes linear ARGB buffers to DRM.

[jc-kynesim]

There is a somewhat mutilated (it doesn't make it more readable) version of kmscube here in the cube subdir and I'm sure that GL is rendering the cube to ARGB for that.

[carlonluca]

I'm not sure if I'm getting this last message properly, but I suspect you are referring to using glReadPixels to read the block of pixels from the fb. Tried that, but for some reason it was very slow. I should investigate that further.

Are you also saying it may be possible to pass the tiled buffer to the HVS for conversion to linear?

[jc-kynesim]

No... You can provide your own framebuffer for GL to write to code to do so can be found in cube/drm-offscreen, GL setup is in cube/common.c:init_egl which creates an appropriate surface (or lack thereof). If you find this code hard to follow, I sympathise - I do too (95% not my code).

[popcornmix]

This should be fix for this issue: raspberrypi/linux#6345

[carlonluca]

Thank you very much!