Monday, 28 October 2013

I.MX6 Ubuntu 13.04 Debugging GPU Acceleration

You've probably reached here because your having problems getting the rootfs in my previous post to work for X11. So here some debugging tips to help you out:

1. The kernel I used is 4.1.0  and can be found in my repo and is a branch of the FSL repo. An additional patch to set the correct busid for the vivante driver may need to be made if not present in the kernel:

--- a/drivers/gpu/drm/vivante/vivante_drv.c
+++ b/drivers/gpu/drm/vivante/vivante_drv.c
@@ -55,7 +55,7 @@

#include "drm_pciids.h"

-static char platformdevicename[] = "Vivante GCCore";
+static char platformdevicename[] = "Vivante GCCore:00";
static struct platform_device *pplatformdev;

static struct drm_driver driver = {

Here is my  defconfig (I'm compiling for a custom board). Note: the FSL patch (ENGR00264288-1) to upgrade the Vivante libraries to 4.6.9p12.

2. Once you have a booting kernel, you should first test that kernel works against the Vivante framebuffer libraries. To do this we simply switch to the fb libraries (need to be root):

cd /usr/lib
rm libEGL.so.1.0 libEGL.so.1 libEGL.so
ln -s libEGL-fb.so libEGL.so.1.0
ln -s libEGL-fb.so libEGL.so.1
ln -s libEGL-fb.so libEGL.so 

rm libGAL.so
ln -s libGAL-fb.so libGAL.so

rm libVIVANTE.so 
ln -s libVIVANTE-fb.so libVIVANTE.so 

Now test with one of the Vivante tutorial examples (pick any of the tutorials)

cd /root/gpu-viv-bin-mx6q-3.5.7-1.0.0-alpha.2-hfp/opt/viv_samples/vdk
./tutorial7

If the tutorial doesn't run it may indicate there is a mismatch between the kernel Vivante code and the libraries or the Vivante libraries may be missing a dependency.

3. If everything is fine with the framebuffer libraries we can now switch back to x11:

cd /usr/lib

rm libEGL.so.1.0 libEGL.so.1 libEGL.so
ln -s libEGL-x11.so libEGL.so.1.0
ln -s libEGL-x11.so libEGL.so.1
ln -s libEGL-x11.so libEGL.so 

rm libGAL.so
ln -s libGAL-x11.so libGAL.so

rm libVIVANTE.so 
ln -s libVIVANTE-x11.so libVIVANTE.so 

Now reboot.

4. Before we test with X, we need to check that kernel vivante/drm modules are loaded:

root@ubuntu-imx6:~# lsmod
Module                  Size  Used by
vivante                  947  1 
drm                   137567  2 vivante

If the modules aren't loaded then X will revert to software rendering because the device /dev/dri/card0 does not exist. The loading of the module is configured in /etc/modules

5. I suggest starting a simple X server to test that the Vivante drivers get correctly loaded:

startx &

The output of the /var/log/Xorg.0.log should be similar to this. If errors are reported it may be because:

1. The vivante kernel module didn't load
2. Check the exa driver is present /usr/lib/xorg/modules/drivers/vivante_drv.so
3. Least likely, missing permissions on the gpu device, these should be setup in  /etc/udev/rules.d/10-imx.rules.

6. Validate the output of glxinfo and es2_info (they should show the presence of the Vivante drivers):

export DISPLAY=:0
glxinfo
es2_info

If you are not seeing "OpenGL renderer string: GC2000 Graphics Engine" and/or "EGL_VENDOR = Vivante Corporation" in the output then it may be possible that the mesa libraries are being picked up. If the directories /usr/lib/arm-linux-gnueabihf/mesa and/or /usr/lib/arm-linux-gnueabihf/mesa-egl are present then move these to another location. They shouldn't be present on my rootfs unless the mesa packages were reinstalled.




55 comments:

  1. Hi Jas,

    No dice. I checked all of this and I'm seeing failures from glxinfo:

    root@ubuntu-imx6:~# export DISPLAY=:0
    root@ubuntu-imx6:~# export LIBGL_DEBUG=verbose
    root@ubuntu-imx6:~# glxinfo | less
    root@ubuntu-imx6:~# glxinfo
    name of display: :0
    libGL: OpenDriver: trying /usr/lib/dri/vivante_dri.so
    drmOpenByBusid: Searching for BusID platform:Vivante GCCore:00
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is 5, (OK)
    drmOpenByBusid: drmOpenMinor returns 5
    drmOpenByBusid: drmGetBusid reports platform:Vivante GCCore
    drmOpenDevice: node name is /dev/dri/card1
    drmOpenDevice: open result is -1, (No such device)

    ReplyDelete
    Replies
    1. Hi,

      I think the Busid is not being set correctly in the kernel, drmGetBusid should report:

      name of display: :0
      libGL: OpenDriver: trying /usr/lib/dri/vivante_dri.so
      drmOpenByBusid: Searching for BusID platform:Vivante GCCore:00
      drmOpenDevice: node name is /dev/dri/card0
      drmOpenDevice: open result is 5, (OK)
      drmOpenByBusid: drmOpenMinor returns 5
      drmOpenByBusid: drmGetBusid reports platform:Vivante GCCore:00

      Do you have this patch in your kernel?

      --- a/drivers/gpu/drm/vivante/vivante_drv.c
      +++ b/drivers/gpu/drm/vivante/vivante_drv.c
      @@ -55,7 +55,7 @@

      #include "drm_pciids.h"

      -static char platformdevicename[] = "Vivante GCCore";
      +static char platformdevicename[] = "Vivante GCCore:00";
      static struct platform_device *pplatformdev;

      static struct drm_driver driver = {

      Delete
    2. Many thanks Jas,

      I finally got around to testing this, and this is exactly right. I was missing this patch.

      BTW, glmark-es2 ran to completion on a Nitrogen6x board and gave pretty impressive results: (glmark score of 305).

      Delete
    3. Great you got it working! 305 is a good score but at what resolution?

      Delete
    4. The screen resolution was 1280x720, but the glmark-es2 window was less than half of that.

      Delete
  2. Will there be again a readymade image just for writing onto a SD-Card? So we get the most updated thing of your great work.

    ReplyDelete
    Replies
    1. Hi, there won't be an SD card image due to the fact the rootfs was meant to be deployable on any imx6d/q device. All that is required is a uboot and kernel image for your device.

      Delete
  3. I thought you already did a GK802 image in past... so i am sorry... my mistake.

    ReplyDelete
  4. When you have some time, can you make a small guide with the commands to configure the kernel for wandboard and make it ?
    Thanks

    ReplyDelete
  5. By the way, are there a branch for wandboard ? In the branch list, I dont see a wandboard branch, only udoo, utilite, solidrun etc...

    ReplyDelete
    Replies
    1. Hi,

      As I don't have a wandboard it is difficult for me test, although I did create the UDOO one without a udoo :) but with the help of some guys with a wandboard. You could try the wandboard 4.1.0 release https://groups.google.com/forum/#!topic/wandboard/7C_JpfVWRuE

      Delete
  6. Hi,
    I'm part of the UDOO team, we would like to send you a UDOO Quad to test your Ubuntu 13.04 and the support for armhf.
    if you are interested please contact us from UDOO contact form: http://www.udoo.org/support/contact-us/

    ReplyDelete
    Replies
    1. Hi, sent you a message via your contact page.

      Delete
    2. What does this imply from your X log?

      [ 31.033] (II) AIGLX: Screen 0 is not DRI2 capable
      [ 31.033] drmOpenDevice: node name is /dev/dri/card0
      [ 31.033] drmOpenDevice: open result is 11, (OK)
      [ 31.033] drmOpenByBusid: Searching for BusID platform:Vivante GCCore:00
      [ 31.033] drmOpenDevice: node name is /dev/dri/card0
      [ 31.033] drmOpenDevice: open result is 11, (OK)
      [ 31.034] drmOpenByBusid: drmOpenMinor returns 11
      [ 31.034] drmOpenByBusid: Interface 1.4 failed, trying 1.1
      [ 31.034] drmOpenByBusid: drmGetBusid reports platform:Vivante GCCore:00
      [ 31.035] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/vivante_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/v)
      [ 31.035] (EE) AIGLX: reverting to software rendering

      Delete
    3. If your asking about the 'AIGLX error' then is it not an issue. AIGLX is for glx non-DRI implementation. The vivante library shouldn't make use of AIGLX.

      Delete
    4. What is the ENGR00264288 patch? I can't find an on line reference to it - it seems to have been taken off-line by Freescale.

      Delete
    5. Ignore my previous question - Apparently the freescale repository was down when I was trying to get it. I am trying to understand your repo relative to the large change set added by Otavio Salvador as per:

      https://lists.yoctoproject.org/pipermail/meta-freescale/2013-July/003802.html

      I am trying to determine if the boundary devices 4.1.0 release tracks your repo relative to this change set. I will ask Eric Nelson as well but I wanted your thoughts. I am desperately trying to get X acceleration working on the nitrogen6x boards.

      Delete
    6. Hi, Eric has got my rootfs working on the Nitrogen6x.

      Delete
    7. I placed an image on our cloud storage site. Because it contains Freescale content, we do require registration and acceptance of the EULA.

      http://boundarydevices.com/eula?file=xubuntu_13.04_gpu-nitrogen6x-20131203.tar.gz

      Delete
    8. I forgot to mention that this includes our latest (3.0.35_4.1.0) kernel. It required a patch to support the latest GPU binaries:
      https://github.com/boundarydevices/linux-imx6/commits/boundary-imx_3.0.35_4.1.0

      Delete
  7. Hi Jas,

    Can you comment on how you cross-compiled vivante_drv.so?

    I'm trying to reproduce your results on a Linaro Raring baseline, and it appears that the API has changed somewhere.

    ReplyDelete
  8. Hi Jas,
    I got OpenGL renderer Mesa as you mentioned , I was using debian7.1 with gpu-viv-bin-imx6q installed on it . the gpu tutorials runs well , but even I've re-link the libGL.so.1 , in glxinfo it still does recognize GC2000 OpenGL, I tried 头reinstall mesa-utils, but durning the installation it installs mesa glew glu gl as well, I really need your help, many thanks!

    ReplyDelete
    Replies
    1. Hi,

      For debian, the mesa libraries are probably in different locations compared to ubuntu.

      Delete
  9. This comment has been removed by the author.

    ReplyDelete
  10. Hi Jas,
    I read your blog completely and thank you, it helped me a lot. But on my system I still can't get acceletation both for desktop and glx. I have:
    - wandboard quad board
    - debootstraped ubuntu 14.04 armhf + lxde
    - I built kernel 3.10.17_ga from github.com/wandboard-org
    - kernel arg video=mxcfb0:dev=hdmi,1920x1080@60,bpp=32 fbmem=32M
    - gpu libs gpu-viv-bin-mx6q-3.10.17-1.0.0-hfp in /usr/lib
    - I built and installed xserver-xorg-video-imx-viv-3.10.17-1.0.0
    - mesa libs were moved to unreachable place
    - I built libvpu 1.045 and libfslwpuwrap
    - I build gstreamer-imx-plugins without any errors and with all elements
    - /dev/dri/card0 exists
    - lsmod doesn't show drm and vivante modules, because they are bultin
    - In my Xorg.0.log I see vivante driver log without vivante errors (completely as yours)
    - Gstreamer hw acceleration works (I see in console output from imx elements)

    But with all this configuration lxde rendering is extremely slow:
    - windows dragging are really slow and with tails
    - gstreamer window output is about 1-2fps with lot of dropped frames
    - glxinfo and glxgears aren't working: saying no GLX extensions available (in Xorg.0.log I also see error that no GLX extensions available)
    - chromium webgl isn't working as well (I checked - it enabled in browser)
    - with enabled chromium setting "override software rendering list" it becomes completely unusable with ~1 fps, so I disabled this option.
    - I tried both libEGL-fb and libEGL-x11 - they both are working, but no acceleration

    I saw your videos and everything is pretty smooth and I think that I missed something in configuration. Could you please say your opinion on my configuration? Thanks!!!

    ReplyDelete
    Replies
    1. It won't with work xserver versions greater than 1.14.

      Delete
    2. Oh, you are right. I completely forgot to check xserver version. Thanks!

      I switched to 13.10 and got it working. Now glxinfo shows vivante gc2000 strings, but when I run any glx app, xserver hangs. Seems I need libdrm patch. Did you patched libdrm for your rootfs?

      Delete
  11. Hi Jas,

    I am using a root fs with X11 backend. when i am compiling the freescale samples using Makefile.x11, they are compiling fine but when i compile them with Makefile.fbdev, they are giving errors like:

    gcc -o ./01_SimpleTriangle SimpleTriangle.o ../common/src/fsl_egl.o ../common/src/glu3.o -lstdc++ -lm -lGLESv1_CM -lEGL -ldl -Wl,--library-path=/usr/lib,-rpath-link=/usr/lib
    ../common/src/fsl_egl.o: In function `fsl_getNativeDisplay':
    /sdk/Samples/GLES1.1/01_SimpleTriangle/../common/src/fsl_egl.c:50: undefined reference to `fbGetDisplayByIndex'
    ../common/src/fsl_egl.o: In function `fsl_createwindow':
    /sdk/Samples/GLES1.1/01_SimpleTriangle/../common/src/fsl_egl.c:77: undefined reference to `fbCreateWindow'
    /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libEGL.so: undefined reference to `gcoOS_DrawSurface'
    /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libEGL.so: undefined reference to `XSync'
    /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libEGL.so: undefined reference to `gcoOS_ResizeWindow'
    /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libEGL.so: undefined reference to `gcoOS_SwapBuffersGeneric_Async'
    collect2: error: ld returned 1 exit status
    make[1]: *** [01_SimpleTriangle] Error 1
    make[1]: Leaving directory `/sdk/Samples/GLES1.1/01_SimpleTriangle'
    make: *** [all] Error 2


    I require to compile them with fbdev.Help me.

    Regards,
    Sudipta

    ReplyDelete
    Replies
    1. You need to ensure the fb versions of FSL libraries (eg libEGL.so, liblGLESv1_CM.so) are deployed not the X11 instances.

      Delete
    2. You need to ensure the fb versions of FSL libraries (eg libEGL.so, liblGLESv1_CM.so) are deployed not the X11 instances.

      Delete
    3. I have the fb versions of FSL libararies.

      root@nitrogen:/usr/lib# ls -l libGLESv1*
      lrwxrwxrwx 1 root root 21 Apr 14 03:33 libGLESv1_CL.so -> libGLESv1_CL.so.1.1.0
      lrwxrwxrwx 1 root root 21 Apr 14 03:33 libGLESv1_CL.so.1 -> libGLESv1_CL.so.1.1.0
      -rwxr-xr-x 1 root root 1742753 Apr 14 05:16 libGLESv1_CL.so.1.1.0
      -rwxr-xr-x 1 root root 21 Apr 14 07:24 libGLESv1_CM.so
      -rwxr-xr-x 1 root root 21 Apr 14 07:24 libGLESv1_CM.so.1
      -rwxr-xr-x 1 root root 1742753 Apr 14 07:24 libGLESv1_CM.so.1.1.0
      root@nitrogen:/usr/lib# ls -l libEGL*
      -rwxr-xr-x 1 root root 616552 Apr 14 07:19 libEGL-dfb.so
      -rwxr-xr-x 1 root root 379514 Apr 14 07:19 libEGL-fb.so
      -rwxr-xr-x 1 root root 391904 Apr 14 07:19 libEGL-wl.so
      lrwxrwxrwx 1 root root 12 Apr 14 07:20 libEGL.so -> libEGL-fb.so
      lrwxrwxrwx 1 root root 12 Apr 14 07:20 libEGL.so.1 -> libEGL-fb.so
      lrwxrwxrwx 1 root root 12 Apr 14 07:20 libEGL.so.1.0 -> libEGL-fb.so
      root@nitrogen:/usr/lib#


      Is this fine or i have to symlink libGLESv1_CM.so?

      Delete
    4. It is giving errors while compiling:

      gcc -o ./01_SimpleTriangle SimpleTriangle.o ../common/src/fsl_egl.o ../common/src/glu3.o -lstdc++ -lm -lGLESv1_CM -lEGL -ldl -Wl,--library-path=/usr/lib,-rpath-link=/usr/lib
      /usr/bin/ld:/usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../../lib/libGLESv1_CM.so: file format not recognized; treating as linker script
      /usr/bin/ld:/usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../../lib/libGLESv1_CM.so:1: syntax error
      collect2: error: ld returned 1 exit status
      make: *** [01_SimpleTriangle] Error 1

      Delete
    5. The following should be symlinks to libGLESv1_CM.so.1.1.0, but they are not:

      -rwxr-xr-x 1 root root 21 Apr 14 07:24 libGLESv1_CM.so
      -rwxr-xr-x 1 root root 21 Apr 14 07:24 libGLESv1_CM.so.1

      Delete
    6. I tried with this:

      root@nitrogen:/usr/lib# ls -l libGLESv1_CM*
      lrwxrwxrwx 1 root root 21 Apr 14 08:47 libGLESv1_CM.so -> libGLESv1_CM.so.1.1.0
      lrwxrwxrwx 1 root root 21 Apr 14 08:47 libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0
      -rwxr-xr-x 1 root root 1755534 Apr 14 08:46 libGLESv1_CM.so.1.1.0

      But, still the errors are as my first post. Has this anything to do with the root fs i am using with X11 backend?

      Delete
    7. I'm not sure about yout rootfs because I'd not' know about it. The compiler is complaining because some symbols are missing from libEGL.so (eg gcoOS_ResizeWindow, gcoOS_SwapBuffersGeneric_Async etc).

      Can you check if libEGL.so has its dependency libraries by:

      ldd /usr/lib/libEGL.so

      Delete
    8. The following should be symlinks to libGLESv1_CM.so.1.1.0, but they are not:

      -rwxr-xr-x 1 root root 21 Apr 14 07:24 libGLESv1_CM.so
      -rwxr-xr-x 1 root root 21 Apr 14 07:24 libGLESv1_CM.so.1

      Delete
    9. This is what i got.Is it right or something is missing?

      ubuntu@nitrogen:/usr/lib$ ldd libEGL.so
      libGAL.so => /usr/lib/arm-linux-gnueabihf/vivante/libGAL.so (0xb6e57000)
      librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6e48000)
      libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d61000)
      libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6cf5000)
      libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6cda000)
      libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6ccf000)
      /lib/ld-linux-armhf.so.3 (0xb6f66000)

      Delete
    10. symlinks to libGLESv1_CM.so.1.1.0 are present.

      ubuntu@nitrogen:/usr/lib$ ls -l libGLESv1_CM.so*
      lrwxrwxrwx 1 root root 21 Apr 16 04:35 libGLESv1_CM.so -> libGLESv1_CM.so.1.1.0
      lrwxrwxrwx 1 root root 21 Apr 16 04:35 libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0
      -rwxr-xr-x 1 root root 1755534 Apr 16 04:33 libGLESv1_CM.so.1.1.0

      Delete
    11. If you look at the error it is reporting:

      /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libEGL.so: undefined reference to `gcoOS_DrawSurface'

      It has found a libEGL.so in ../arm-linux-gnueabihf/ not /usr/lib directory. Can you search to see in which paths libEGL.so exists in.

      Delete
    12. Thanks Jasbir. I got it right.
      I prepared a fresh sd card with all the libraries correctly symlinked as per you and finally i removed one package
      gpu-viv-bin-mx6q-x11 and installed gpu-viv-bin-mx6q-fb(from boundary devices) and the samples got working fine.

      Regards,
      Sudipta

      Delete
    13. Sudipta, great you it working!

      Delete
  12. Hi Jasbir. I am compiling the samples using framebuffer libraries. But, i am not able to get the hardware acceleration.Load on my cpu is near about 47%.How can i acheive it?

    ReplyDelete
    Replies
    1. I have drm.ko and vivante.ko modules loaded. I have vivante_dri.so present in /usr/lib/dri. I have fbdev_drv.so present in /usr/lib/xorg/modules/drivers.

      Is there anything i need to check for?

      Delete
    2. Framebuffer libraries don't need vivante_dri.so or fbdev_drv.so that is for X11.

      Unfortunately it is difficult to diagnose without knowing more about your environment setup and how you are launching the samples.

      Delete
    3. Hi Jasbir. I am using LXDE ubuntu root fs from boundary devices with linux 3.10.17. I have installed gpu-viv-bin-mx6q-3.10.17-1.0.0. Then, i have prepared symlinks to framebuffer libraries(libEGL-fb.so,libGAL-fb.so, libVIVANTE-fb.so).Then, i am compiling the gpu samples using fbdev and then running the binaries.

      The problem is the binaries are running on the cpu. I am facing difficulty in finding to accelerate them hardware wise. Is there anything else you need to know about the environment setup?

      Delete
    4. How are you trying to validate that acceleration is working using the fb libraries?

      Delete
    5. using "top" command i am trying to see if the binary is running

      Delete
    6. There i can see if it is running on cpu , if it is not there then it is sure to be running on the gpu.

      Delete
    7. The binary will still be using CPU so it's not an indicator of that acceleration is not working. The main indicator will be the fps rate the application requires or is trying to achieve.

      Delete
    8. Ok. Thanks Jasbir. But, will the percentage usage of cpu come down if it hits the gpu?
      And what will be the approx fps rate if it hits and do not hit the gpu, i just want to check and confirm?
      Please help

      Delete
    9. Unfortunately I can't give you figures because it depends on many factors eg resolution, dual/quad core, board vendor .. etc.

      If your a commercial venture then as a suggestion, I can provide short term consultancy to aid your development.

      Delete
    10. Anyway thanks Jasbir.

      But, will the percentage usage of cpu come down if it hits the gpu?

      Delete
    11. Unfortunately your question is difficult to answer ! It all depends on the what the application is doing and how well it is coded to use Open GL ES. A highly optimised application Open GL ES application should off load processing to the GPU, however the application itself my still require CPU for other processing.

      Delete
    12. This comment has been removed by the author.

      Delete
    13. This comment has been removed by the author.

      Delete