I followed the example at https://github.com/raspberrypi/libpisp/ ... onvert.cpp and adapted it to read from memory instead of from a file.
This is my modified version:
https://pastebin.com/MqFdDm1b
Everything works, but I’m confused about the actual benefit of this approach.
The CPU load is still around 40%, slightly higher than the last optimizations using the provided do32bitConversion.
The code reads from the dmabuf provided by GStreamer’s v4l2src and writes into a mapped GBM BO using gbm_bo_map.
Since the final buffer is not a real dmabuf, I don’t have an FD that I can pass directly to EGL (e.g., EGL_DMA_BUF_PLANE0_FD_EXT).
Is this expected?
I only want to understand whether, in theory, this whole process should allow me to build a fully zero-copy pipeline where the data flows from my TC358743, through GStreamer (which my entire application is based on and which keeps audio and video in sync), and finally into the GPU texture—going from RGB888 to RGBX8888—without any CPU copies or intermediate processing.
This is my modified version:
https://pastebin.com/MqFdDm1b
Everything works, but I’m confused about the actual benefit of this approach.
The CPU load is still around 40%, slightly higher than the last optimizations using the provided do32bitConversion.
The code reads from the dmabuf provided by GStreamer’s v4l2src and writes into a mapped GBM BO using gbm_bo_map.
Since the final buffer is not a real dmabuf, I don’t have an FD that I can pass directly to EGL (e.g., EGL_DMA_BUF_PLANE0_FD_EXT).
Is this expected?
I only want to understand whether, in theory, this whole process should allow me to build a fully zero-copy pipeline where the data flows from my TC358743, through GStreamer (which my entire application is based on and which keeps audio and video in sync), and finally into the GPU texture—going from RGB888 to RGBX8888—without any CPU copies or intermediate processing.
Statistics: Posted by Bundan — Fri Dec 05, 2025 1:51 am