AnsweredAssumed Answered

iMX6DL Vivante (5.0.11.p8) banding (gradient) issue

Question asked by Rostyslav Khudolii on Feb 2, 2017
Latest reply on Feb 11, 2017 by Rostyslav Khudolii

Dear All,

 

Recently we've updated Vivante from 4.6.9 to 5.0.11.p8 by backporting it from the 3.14.52_1.1.0_ga branch (located in the official git repo). The corresponding userspace drivers (OpenGL implementation etc) were downloaded and installed from http://downloads.yoctoproject.org/mirror/sources/

We've managed to run our sw stack (a video streaming application) after the update and it seemed to work well, except that we've noticed a banding issue, when displaying color gradients (framebuffer dumps attached).

 

We have a custom device based on iMX6DL running a customized Linux Kernel 3.10.53 (originally taken from the official git repo) + Fedora 23. We're not using any video backends such as X11, QT, Wayland or DFB, just a plain framebuffer with 16bpp color depth.

The video relate command line parameters: 

video=mxcfb0:dev=hdmi,bpp=16

 

We've managed to reproduce the issue by downloading the latest gpu samples from Freescale (fsl-gpu-sdk-2.3) compiling and running the one (S09_VIV_direct_texture) we'd got inspired from. The original image was moving so we just modified code to display a gradient picture without any rotation.

It turned out, that the issue disappears if we remove this line

glClear(GL_COLOR_BUFFER_BIT);

which is unacceptable.

Here is the modified sample code (from S09_VIV_direct_texture::Draw() method):

...

// glClearColor(0.0f, 0.5f, 0.5f, 1.0f);
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT); // commenting this line makes the issue disappear
glUniformMatrix4fv(m_locTransformMat, 1, GL_FALSE, g_transformMatrix /*m_matTransform.DirectAccess()*/);

...

To eliminate a possibility of our HW and SW stack "malicious" impact we've tested the same sample on iMX6DL Solo Sabre SD (running the corresponding images/filesystem from fsl-L3.14.28_1.0.0_iMX6qdls_Bundle) and managed to reproduce the issue.

 

However, with the latest iMX6QP Sabre SD (running the corresponding images/filesystem from L4.1.15-1.0.0-ga_images_MX6QPSABRESD) the issue isn't being observed anymore.

 

Both boards had color depth = 16bpp set.

 

We've tried chaning the color depth from 16 to 32 and it seemed to fix the issue, however it's not acceptable for us at the moment since we started observing some weird IPU behaviour (after ~1h rendering, image starts flickering and we see some warning in the kernel log) + everything worked well with the old vivante version and 16bpp depth. 

 

Any help will be appreciated!

Attachments

Outcomes