i.MX6QP + Qt5 Cinematic graphics issue

[gary_bisson]

Hi,

Running the Qt5 Cinematic Experience shows some graphics issues on 6QP only.

Here are some details on the setup to reproduce the issue:

- Qt5.5 or Qt5.6 (tested with both)

- Yocto Jethro or Buildroot master (as of today, for latest graphics libraries support)

- Using a platform that supports both 6Q and 6QP, in my case the Nitrogen6_MAX and Nitrogen6QP_MAX, the cpu is the only difference

- Kernel 3.14.53, in my case:

GitHub - boundarydevices/linux-imx6 at boundary-imx_3.14.52_1.1.0_ga: Boundary Devices Kernel tree f...

   -> this issue was also present with 3.14.38-6qp-beta + p6.x libraries, but at the time it was beta so not worth mentioning

- imx-gpu-viv + kernel-module-imx-gpu-viv version 5.0.11 p7.4

- Qt5 Cinematic Experience:

http://quitcoding.com/download/Qt5_CinematicExperience_rpi_1.0.tgz

meta-qt5/cinematicexperience_1.0.bb at master · meta-qt5/meta-qt5 · GitHub

Please find attached two screenshots, one shows the output when running on a 6Q, the other is running on the 6QP, using the exact same SDCard, exact same kernel, only the device tree differs (includes imx6q.dtsi in one case, imx6qp.dtsi in the other).

Please dismiss the tearing that can be seen in those screenshots, this is due to the software used to grab the framebuffer (fbgrab) which doesn't wait for vsync. Instead, focus on the rectangles around the different stars that appears on the background. It sounds like some alpha blending isn't managed properly on the 6QP.

Let me know if you have any question regarding the issue, which hopefully will be fixed in next Vivante release.

Regards,

Gary

[chingling_wang]

I can understand that customer still have the issue.  But, I cannot reproduce.  First we need to reproduce it so that we can debug. I need help to reproduce this issue.

I built my sd card image following this fsl yoctor release  link

fsl-arm-yocto-bsp.git - Freescale i.MX Yocto Project manifests

I didn't change anything, just copy the image and boot. Is there any step I missed?

_ In my build, QT is 5.5, should be ok.

_ for YoctoJethro or Buildroot master,  is it the same as in the fsl yocto link fsl-arm-yocto-bsp.git - Freescale i.MX Yocto Project manifests?  if not, please specify clearly where you got the source and how you built it, what do you mean by latest libraries support? 3.14.52 should use gpu p7, I am using p7 ga release which goes with 3.14.52-1.1.0_ga

_ I only have our reference board imx6qp or imx6q, I don't know how to get what you called boundary device that support both imx6qp and imx6q.

_I am using 3.14.52 ga release, I don't know when we release 3.14.53 and where to get it.

_ Qt5 cinematic is built in our yocto image card, I am using this to reproduce the issue, but I cannot reproduce the issue.

[gary_bisson]

Hi Chingling,

I'm confused, gusarambula​ said the issue has been reproduced, was it not the case?

Yes please use the 3.14.52-1.1.0_ga release, the 3.14.53 I mention was obviously a typo.

Regarding the BSP, it was using jethro + the community manifest as explained here:

FSL Community BSP Release Notes 2.0 documentation

With your current image, please launch Qt5 cinematic experience on NXP SabreSD iMX6Q, take a screenshot. Then do the exact same procedure on iMX6QP and post both screenshots here.

You should see that the fps are different due to the switch from 6Q and 6QP and also see the alpha blending issue on 6QP.

Regards,

Gary

[chingling_wang]

I can  reproduce this with X11 backend for 3.14.52.

export GPU_VIV_EXT_RESOLVE=1 , this issue will be gone

For my FB backend, the GPU_VIV_EXT_RESOLVE=1 by default, so I cannot reproduce it.  But if I put GPU_VIV_EXT_RESOLVE=0, I saw the issue.

Anyway, export GPU_VIV_EXT_RESOLVE=1 , the issue will be gone

[gary_bisson]

Hi Chingling Wang,

I confirm setting GPU_VIV_EXT_RESOLVE to 1 fixes the issue, thanks!

However I'm not sure to understand how it was set to this value by default on your FB environment. I've looked/grep'd into all the meta-fsl* repos as well as meta-qt5 but couldn't find any reference of GPU_VIV_EXT_RESOLVE.

Could you point me to where in the BSP this variable is set for FB environment?

Regards,

Gary

[chingling_wang]

on your terminal,

export GPU_VIV_EXT_RESOLVE=1

then run your application

FB or X11, I used hfp both.  This shouldn't be an issue

[gary_bisson]

Hi chinglingwang​,

Thanks but I had the command right the first time and I confirm that in my case:

- Working with X11 + vivante 5.0.11p7.4 HFP + Qt5.5

- NOT working with FB + vivante 5.0.11p7.4 SFP + Qt5.6

I am going to build a yocto image again with Qt5.5, but since GPU_VIV_EXT_RESOLVE is something internal of the graphics libraries I don't expect Qt version to be an issue. That is why it makes me think there might be a difference between SFP and HFP versions. Especially since all your tests have been done with HFP.

Regards,

Gary

[gary_bisson]

Hi chinglingwang​,

After some testing with the current Jethro branch of the community BSP I still see the issue in FB mode:

- Yocto Jethro + vivante 5.0.11p7.4 HFP + Qt5.5 + GPU_VIV_EXT_RESOLVE=1 => NOT working

So it is definitely not a problem between HFP and SFP since it still doesn't work on HFP for me.

Could you send the output of the command 'env' on your setup? Are you using eglfs (QT_QPA_PLATFORM)?

danielleloader​, does GPU_VIV_EXT_RESOLVE fix the problem in your case?

In case this is useful, here is my env + some eglfs debug information:

root@nitrogen6x:~# env
USER=root
SHLVL=1
HOME=/home/root
HUSHLOGIN=FALSE
QT_QPA_EGLFS_DEBUG=1
PS1=\u@\h:\w\$ 
LOGNAME=root
TERM=linux
FB_MULTI_BUFFER=3
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
SHELL=/bin/sh
HZ=100
QT_QPA_PLATFORM=eglfs
PWD=/home/root
GPU_VIV_EXT_RESOLVE=1
TZ=UTC
EDITOR=vi
root@nitrogen6x:~# /usr/share/cinematicexperience-1.0/Qt5_CinematicExperience
mxc_sdc_fb fb.21: 1280x800 h_sync,r,l: 32,48,80  v_sync,l,u: 6,2,15 pixclock=71108000 Hz
imx-ipuv3 2400000.ipu: use special clk parent
imx-ipuv3 2400000.ipu: disp=1, pixel_clk=71108000 71458646 parent=71458646 div=1
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Created context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0) with config:
  EGL_BUFFER_SIZE: 12
  EGL_ALPHA_SIZE: 0
  EGL_BLUE_SIZE: 4
  EGL_GREEN_SIZE: 4
  EGL_RED_SIZE: 4
  EGL_DEPTH_SIZE: 24
  EGL_STENCIL_SIZE: 8
  EGL_CONFIG_CAVEAT: 12344
  EGL_CONFIG_ID: 5
  EGL_LEVEL: 0
  EGL_MAX_PBUFFER_HEIGHT: 8064
  EGL_MAX_PBUFFER_PIXELS: 65028096
  EGL_MAX_PBUFFER_WIDTH: 8064
  EGL_NATIVE_RENDERABLE: 0
  EGL_NATIVE_VISUAL_ID: 0
  EGL_NATIVE_VISUAL_TYPE: 12344
  EGL_SAMPLES: 0
  EGL_SAMPLE_BUFFERS: 0
  EGL_SURFACE_TYPE: 1285
  EGL_TRANSPARENT_TYPE: 12344
  EGL_TRANSPARENT_BLUE_VALUE: -1
  EGL_TRANSPARENT_GREEN_VALUE: -1
  EGL_TRANSPARENT_RED_VALUE: -1
  EGL_BIND_TO_TEXTURE_RGB: 1
  EGL_BIND_TO_TEXTURE_RGBA: 1
  EGL_MIN_SWAP_INTERVAL: 0
  EGL_MAX_SWAP_INTERVAL: 10

Regards,

Gary

[danielleloader]

Hi Gary,

No that did not solve our problem here. We're using HFP and rendering to FB, no X11.

Debug output:

root@imx6qp:~# GPU_VIV_EXT_RESOLVE=1 QT_QPA_EGLFS_DEBUG=1 Qt5_CinematicExperience
QEglFSVivIntegration will set environment variable FB_MULTI_BUFFER=2 to enable double buffering and vsync.
 If this is not desired, you can override this via: export QT_EGLFS_IMX6_NO_FB_MULTI_BUFFER=1
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Created context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0) with config:
    EGL_BUFFER_SIZE: 12
    EGL_ALPHA_SIZE: 0
    EGL_BLUE_SIZE: 4
    EGL_GREEN_SIZE: 4
    EGL_RED_SIZE: 4
    EGL_DEPTH_SIZE: 24
    EGL_STENCIL_SIZE: 8
    EGL_CONFIG_CAVEAT: 12344
    EGL_CONFIG_ID: 5
    EGL_LEVEL: 0
    EGL_MAX_PBUFFER_HEIGHT: 8064
    EGL_MAX_PBUFFER_PIXELS: 65028096
    EGL_MAX_PBUFFER_WIDTH: 8064
    EGL_NATIVE_RENDERABLE: 0
    EGL_NATIVE_VISUAL_ID: 0
    EGL_NATIVE_VISUAL_TYPE: 12344
    EGL_SAMPLES: 0
    EGL_SAMPLE_BUFFERS: 0
    EGL_SURFACE_TYPE: 1413
    EGL_TRANSPARENT_TYPE: 12344
    EGL_TRANSPARENT_BLUE_VALUE: -1
    EGL_TRANSPARENT_GREEN_VALUE: -1
    EGL_TRANSPARENT_RED_VALUE: -1
    EGL_BIND_TO_TEXTURE_RGB: 1
    EGL_BIND_TO_TEXTURE_RGBA: 1
    EGL_MIN_SWAP_INTERVAL: 0
    EGL_MAX_SWAP_INTERVAL: 10

[chingling_wang]

I just confirmed with GPU South team. This issue should be fixed in gpu imx_gpu_viv_5.0.11.p8.4 release, just replacing the gpu lib and gpu kernel source for 5.0.11.8.4 and rebuild gpu kernel,  this issue shall be gone.

This p8 gpu also goes with bsp 4.1.15.

You don'nt need to export any varibale.

I just tested on x11 backend .  The issue is gone.

[gary_bisson]

Hi chinglingwang​,

Good to hear that next version will be fixed.

But I'd like to understand why it still doesn't work in my case with FB version whereas it works on your setup. Can you provide your env output? I'm fine with setting a variable if that fixes the issue for now, but my FB setup seems to require more than that.

Regards,

Gary

[chingling_wang]

imx_gpu_viv_5.0.11.p8.4 has been released.

My env is simple, and for FB be default GPU_VIV_EXT_RESOLVE is 1 for imx6qp, I confirmed with GPU south. I don't know why FB is not working in your case either.

root@imx6qpsabreauto:~# env

HZ=100

SHELL=/bin/sh

TERM=vt100

HUSHLOGIN=FALSE

USER=root

PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

PWD=/home/root

EDITOR=vi

TZ=UTC

FB_MULTI_BUFFER=3

PS1=\u@\h:\w\$

SHLVL=1

HOME=/home/root

LOGNAME=root

_=/usr/bin/env

Then I run,

Qt5_CinematicExperience -platform eglfs -plugin evdevtouch:/dev/input/event0

It is OK

[gary_bisson]

Hi,

Your colleague says p8.4 is not released yet but that p8.3 already takes care of this issue, do you confirm?

https://lists.yoctoproject.org/pipermail/meta-freescale/2016-April/017666.html

I'll try using p8.3 and let you know of the outcome.

Regards,

Gary

[gary_bisson · Accepted solution]

Hi,

Just tried using 5.0.11p8.3 Vivante libraries + kernel module on top of my 3.14.52 kernel and I couldn't reproduce the issue with FB libraries (X11 libraries already working with p7.4 + GPU_VIV_EXT_RESOLVE=1).

Also tried to set GPU_VIV_EXT_RESOLVE to 0 in order to see if it could trigger it back and it seems the problem is gone for good.

danielleloader​, you can grab this mbox to be applied on top of jethro meta-fsl-arm (until it gets merged):

http://patches.openembedded.org/bundle/gbisson/viv_5.0.11-p8.3/mbox/

Once you confirm this works for you too, I'll mark the thread as resolved.

There is still this mystery of p7.4 where it works for chinglingwang​ in FB mode but does not for Danielle and I. But if it is confirmed that p8.3 is a solution that works for everyone I think it is safe to close that issue.

Regards,

Gary

[danielleloader]

Hi Gary,

I can confirm this fixes the issue for us, replacing driver with http://cache.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-gpu-viv-5.0.11.p8.3-hfp.bin and the kernel driver from the imx_4.1.15_1.0.0_ga branch of git://git.freescale.com/imx/linux-2.6-imx.git solves the glitches.

uname-a shows

Linux imx6qp 3.14.38-6QP_ga+g75a0111 #32 SMP PREEMPT Mon Apr 4 11:36:49 BST 2016 armv7l GNU/Linux

Thanks all

[gary_bisson]

Hi Chingling Wang,

Sorry I actually take it back. It indeed works for X environment but not for FB in my case.

One difference to notice between my X and FB environment is that X is using the hfp version of the libs whereas my FB image relies on sfp. Which version of the libraries has been used in your FB test?

Regards,

Gary

[chingling_wang]

Let's sync up the code source and set up,

1. This link FSL Community BSP Release Notes 2.0 documentation  is long,  could you verify that the link I am using for yocto image build is the same as yours?

fsl-arm-yocto-bsp.git - Freescale i.MX Yocto Project manifests

2. when you said NXP iMX6QP, is it imx6qpsabreauto or imx6qpsabre SDB board? I was told to try on imx6qpsabre SDB board on another thred by Vladan Javanvic.

3. From my understanding, it is  happening on both FB and X11 backend.  Do I need to try on X11 backend. I was told in another thread by vladan to try on X11.

I used this link, fsl-arm-yocto-bsp.git - Freescale i.MX Yocto Project manifests,  build my image for FB backend for imx6qpsabreauto board,  I cannont reprocduce it , the Qt5_CinemaExperienc screen shot is the same as you attached in qt5_cinematic_6q.png, no alpha blending issue.

[gary_bisson]

Hi Chingling Wang,

Here are my answers:

1. I am actually using this manifest:

GitHub - Freescale/fsl-community-bsp-platform: BSP platform manifest

2. I said SabreSD but if you use SabreAuto that is fine too, the important part is that you use the same board (SDB or Auto), one with the i.MX6Q, the other with the i.MX6QP.

3. Yes it happens with both FB and X11 so use the one you prefer.

Please send your screenshots for both 6Q and 6QP.

Regards,

Gary

[gusarambula]

Hello Gary Bisson,

I apologize. It was my understanding that this issue was reproduced but I was wrong. Chingling Wang is trying to reproduce the issue to find the root cause of the problem.

Regards,

[danielleloader]

Hi gusarambula​

I received an email from our NXP FAE stating this too, but I believe the support team have looked at Gary's screen grabs without noticing his comment about the tearing.

Please see attached screens from our application running on iMX6Q and then iMX6Q Plus. Both are confirmed to be using triple buffering and a vertically synced frame buffer grab. The iMX6Q Plus device clearly exhibits the same issues that Gary's attachments above do despite FB_MULTI_BUFFER=3. Also attached is Qt scene graph debug information showing this.

FB_MULTI_BUFFER=3

QSG: threaded render loop

QSG: texture atlas dimensions: 4096 x 1024

R/G/B/A Buffers:    4 4 4 0

Depth Buffer:       24

Stencil Buffer:     8

Samples:            0

GL_VENDOR:          Vivante Corporation

GL_RENDERER:        Vivante GC2000+

GL_VERSION:         OpenGL ES 3.0 V5.0.11.p7.33433

GL_EXTENSIONS:      GL_EXT_read_format_bgra  GL_OES_packed_depth_stencil GL_OES_fragment_precision_high GL_OES_surfaceless_context GL_OES_texture_npot GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth_texture_cube_map GL_EXT_multisampled_render_to_texture GL_OES_vertex_half_float GL_VIV_direct_texture GL_OES_compressed_paletted_texture GL_OES_rgb8_rgba8 GL_EXT_texture_format_BGRA8888 GL_KHR_texture_compression_astc_ldr GL_EXT_texture_type_2_10_10_10_REV GL_EXT_multi_draw_arrays GL_OES_depth_texture GL_OES_get_program_binary GL_OES_fbo_render_mipmap GL_EXT_frag_depth GL_OES_EGL_sync GL_OES_required_internalformat GL_OES_element_index_uint GL_OES_vertex_array_object GL_OES_depth32 GL_OES_vertex_type_10_10_10_2 GL_EXT_texture_filter_anisotropic GL_OES_mapbuffer GL_EXT_discard_framebuffer GL_EXT_blend_minmax GL_OES_depth24 GL_OES_standard_derivatives GL_OES_EGL_image GL_EXT_robustness

[gusarambula]

Hello Danielle Loader,

Thanks for the further information on this issue, I've added it to the internal escalation. We will let you know when we have more information.

Regards,