Black rendering of windowed Open GLES applications on iMX6 Vivante under X11

[DiegoFSL]

Hi everybody.

I'm experiencing a very strange issue with Vivante driver on i.MX6 platform (Boundary Nitrogen6X).

I've experienced that these assertions are always true with the tests I've made:

1. OpenGL ES applications render correctly in windowed mode as long as "unity-2d-launcher" process is running;
2. OpenGL ES applications render solid black in windowed mode as long as "unity-2d-launcher" process is not running.

This holds true even if you change the window manager (I've tested metacity with compiz, openbox and xfwm4). For example if you start the process "unity-2d-launcher" under an openbox session you get correct rendering; if you kill "unity-2d-launcher" you get black rendering.

This holds true even changing OS: it's valid under both Freescale Ubuntu BSP 4.0.0 and Yocto with BSP 4.0.0. Obviously only the second part (black rendering) is verifiable under Yocto, as Unity2D is available only in Ubuntu.

Unity2D Launcher depends on some runtime libraries. I thought that there were some weird dependencies in the Unity2D Launcher libraries chain; however, if you load in memory the entire library dependency-chain but not the final Unity2D Launcher binary, and if you render a scene
in a window (using for example glmark2-es2, a popular benchmark tool), the window is black. If I finally load the Unity2D Launcher binary the windowed rendering works.

How is possible that a such component (Unity2D Launcher) influences the rendering of a scene in a X11 environment?

This bug prevent using other desktop environment to render OpenGL ES scenes in a window.

Bests,

Diego

[DiegoFSL]

Weird news: Otavio has a weird "fix" for the issue, but performance is horrible.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4950#c2

[LaurenPost]

Yes the windowing performance is a known issue and will hopefully be fixed in next kernel upgrade release.

[davecbluechip]

That's good news - have you any idea when that is likely to happen?

[LaurenPost]

Very soon.   We are testing an update for 3.5.7 with the fix now.

[OtavioSalvador · Accepted solution]

This has been fixed already and applied to master branch.

[davecbluechip]

Hello Otavio,

I have a very similar problem to this, which I was hoping had also been fixed in 3.5.7

However, I have just tried the latest code and it still has the problem. Can you tell me if I am doing something wrong (or suggest other approaches)?

1) I have built the Freescale / Yocto 3.5.7-1.0.0-alpha using the Freescale instructions with image "fsl-image-x11"

This runs OK on my Sabre SD and shows the Qt X11 desktop

2) I have copied the GPU SDK v1.00 onto the fs and tried to build

- had to add EXTRA_IMAGE_FEATURES += "tools-sdk" to my conf/local.conf file to get the build tools added to the image

- had to modify the Makefile.x11 file to specify "-mfloat-api=hard"

- had to copy various include files from fsl-community-bsp/build/tmp/sysroots/imx6qsabresd/usr/include to the rootfs created by bitbake:

GLES2/*

EGL/*

KHR/*

X11/*

- had to create symlink to /usr/lib/libX11.so.6 so the linker could see it "ln -s /usr/lib/libX11.so.6 /usr/lib/libX11.so"

The GPU SDK samples ~/gpu_sdk/Samples/GLES2.0/... now build OK

3) When I run the code, I get a large X11 window (full screen except for the window decoration) which is all white. The mouse pointer flickers if I hover over this window, as if it is updating rapidly. When I cancel the window, the code reports an impressive frame rate (e.g. 250fps) but no triangles / spinning cubes / textures have appeared on the screen. This is the same behaviour as I saw using L3.0.35_1.1.0 several months ago (but then I was using Ubuntu desktop rather than Qt)

4) Other things that may be useful to know:

- Vivante samples in /opt/viv_samples/vdk run correctly and with good frame rates (but full screen, not windowed) under L3.5.7-1.0.0-alpha (same as with old L3.0.35_1.1.0)

- L3.5.7-1.0.0-alpha desktop doesn't run the Qt OpenGL demo (when I click on it, it is selected but never starts).

Any ideas or suggestions? All help gratefully received :-)

[OtavioSalvador]

You seem to have used the release layer provided by Freescale, it does not have the 3.5.7-1.0.0-alpha.2 binaries on it.

Please use our master branch (which will become Dora in coming days).

[davecbluechip]

Hello Otavio,

I'm still struggling with this, I'm afraid. Any advice or suggestions would be most welcome.

I have started again using the yocto "master" branch, and my image does appear to have the alpha.2 binaries now. However, the build is for L3.0.35 kernel, and does not appear to support the X11 OpenGL ES. I thought this was an issue with the kernel version, so I added a line to conf/local.conf as follows:

PREFERRED_VERSION_linux-imx = "3.5.7"

This seems to build the L3.5.7 kernel as expected, but now it doesn't boot on my Sabre-SD.

My commands are:

mkdir ~/yocto-master

cd ~/yocto-master

repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master

repo sync

. setup-environment build

<add “PREFERRED_VERSION_linux-imx = "3.5.7"” to conf/local.conf>

bitbake fsl-image-gui

dd if=tmp/deploy/images/imx6qsabresd/fsl-image-gui-imx6qsabresd.sdcard of=/dev/sdc bs=1M

My U-Boot result is:

U-Boot 2013.10-rc3 (Oct 01 2013 - 09:57:08)

CPU:   Freescale i.MX6Q rev1.2 at 792 MHz

Reset cause: POR

Board: MX6-SabreSD

DRAM:  1 GiB

MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2

*** Warning - bad CRC, using default environment

In:    serial

Out:   serial

Err:   serial

Net:   FEC [PRIME]

Hit any key to stop autoboot:  0

mmc1 is current device

reading boot.scr

** Unable to read file boot.scr **

reading uImage

4686240 bytes read in 219 ms (20.4 MiB/s)

Booting from mmc ...

reading imx6q-sabresd.dtb

46128 bytes read in 20 ms (2.2 MiB/s)

## Booting kernel from Legacy Image at 12000000 ...

   Image Name:   Linux-3.5.7-1.0.0+g3285970

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    4686176 Bytes = 4.5 MiB

   Load Address: 10008000

   Entry Point:  10008000

   Verifying Checksum ... OK

## Flattened Device Tree blob at 11000000

   Booting using the fdt blob at 0x11000000

   Loading Kernel Image ... OK

   Using Device Tree in place at 11000000, end 1100e42f

Starting kernel ...

And then it hangs. Any ideas?

[petersuciu]

Yes.

1) a - Use putty (or similar) and connect to the board via Serial to USB cable.

     or

1) b - Connect a keyboard to the board.

2) boot up and wait for the "Press any key to stop boot" message and press a key to cancel boot

3) wait 5-10 mins for the board to "warm up"

4) enter "boot" in terminal from putty

5) magic....at least that's how it worked for me

Also, 1 question: do you get the same issue (ie black screen) when using 1920x1080 resolution?? That's what I'm seeing...