Qt Quick application corrupting the output of a separate OpenCL process?

[tomikyöstilä]

I'm having an issue with a Qt Quick process corrupting the output of a separate OpenCL process when they are running at the same time in a specific starting order. One process reads frames from a CSI camera with Video4Linux2, does some processing to them with OpenCL and displays the output on an LVDS display on /dev/fb0 with GStreamer. The other process is just a Qt Quick Hello World type application with a color key transparent background that renders to the overlay framebuffer /dev/fb1 (using OpenGL ES 2.0 according to the Qt Documentation).

When the OpenCL process is run by itself, it works as expected: the processed camera feed appears correctly on the display. The Qt application also overlays correctly when run by itself (tested by first filling the underlay framebuffer /dev/fb0 with data from /dev/urandom). Everything's fine also when the Qt application is started while the OpenCL process is already running. The issue arises if the OpenCL process is started when the Qt application is already running. In that case the Qt application appears correctly overlaid on the display, but the OpenCL process output is incorrect (different kind of incorrect on an i.MX6QuadPlus compared to an i.MX6Quad, see attachments and their description at the end). Some/most of the data from the original camera frames are still there (motion and shapes can be seen when a hand is waved in front of the camera). This occurs even if the OpenCL process outputs to /dev/fb2 to an HDMI display without the Qt application overlaying it, so it's not an issue of the Qt application drawing over the camera feed or an alpha blending issue or something like that. I've also verified the corruption of the OpenCL output by dumping the OpenCL buffer to a file and analyzing it. This is all consistently reproducible.

Here are some test cases where the OpenCL process is indicated with P1 and the Qt process is indicated with P2:

1. Run P1 -> correct output
2. Run P1, run P2 -> correct output
3. Run P2, run P1 -> invalid output
4. Run P2, run P1, kill P2 -> invalid output
5. Run P2, kill P2, run P1 -> correct output

The issue is observed on two Boundary Devices Nitrogen6_MAX boards (i.MX6QuadPlus and i.MX6Quad), using the FSL Community BSP 2.0 (Jethro) with kernel version 3.14.52-1.1.0_ga+yocto+ga139368, Qt version 5.5.1 and imx-gpu-viv package version 5.0.11.p7.4.

The attachments show the expected output and the corrupted output on an i.MX6QuadPlus and an i.MAX6Quad. The camera is pointing at a fluorescent lamp on the ceiling (the oversaturated flat colored rectangle in top left corners of the photos). On an i.MX6Quad, the corruption is most noticeable in the oversaturated area: it is black instead of gray. On an i.MX6QuadPlus, the corruption is more severe: most of the image is black with some blue and red pixel clusters.

How can one process affect the OpenCL output another process like this? Shouldn't the driver prevent this? What could be done to fix this?

[Bio_TICFSL]

Hi Tomi,

Could you please provide the test code to reproduce the issue with latest BSP?

Thanks