You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Anyway, the driver resides completely in kernel space, and thus must be modified there. Probably the first thing to do would be proper profiling to identify any delays that could be improved.
Another thing would be to work on facilitating the rga2 hardware of the rk3566 chip to do Y4 and dithering in hardware, instead of software. However, this is a user space issue and must be tackled in the compositor.
There are reports of slightly differing drawing speed between the 6.3 kernel (e.g., https://github.com/m-weigand/linux/tree/branch_pinenote_6-6-37) and the newer 6.9 and 6.12 kernels (e.g., https://github.com/m-weigand/linux/tree/branch_pinenote_6-12-rc3_v1). This is probably due to reworked buffer handling, which was aimed at ensuring in-order handling of screen updates. While these changes were probably correct, we should think about introducing additional code paths in the driver for optimal (i.e., fastest) drawing performance.
mweigand: I did some early testing on using the rga hardware from within wlroots for these tasks, but this, so far, failed due to any knowledge regarding the internals of wlroots...and time. A dump of what I have can be found here: https://github.com/m-weigand/wlroots_rk_rga/tree/pn_rga_wip . The basic approach was to use the headless backend and basically add rga and basic drm support in there. rga upbringing already worked, all that was left was providing the final, converted buffer to the drm system.
The text was updated successfully, but these errors were encountered:
This is just a meta issue aimed at providing some collected thoughts on the issue.
Note for contributors Any relevant information should probably be centralised in the Pine wiki (https://wiki.pine64.org/index.php?title=PineNote).
Random thoughts on improving the ebc driver:
Anyway, the driver resides completely in kernel space, and thus must be modified there. Probably the first thing to do would be proper profiling to identify any delays that could be improved.
Another thing would be to work on facilitating the rga2 hardware of the rk3566 chip to do Y4 and dithering in hardware, instead of software. However, this is a user space issue and must be tackled in the compositor.
There are reports of slightly differing drawing speed between the 6.3 kernel (e.g., https://github.com/m-weigand/linux/tree/branch_pinenote_6-6-37) and the newer 6.9 and 6.12 kernels (e.g., https://github.com/m-weigand/linux/tree/branch_pinenote_6-12-rc3_v1). This is probably due to reworked buffer handling, which was aimed at ensuring in-order handling of screen updates. While these changes were probably correct, we should think about introducing additional code paths in the driver for optimal (i.e., fastest) drawing performance.
RGA2e and EBC hardware
The text was updated successfully, but these errors were encountered: