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.
Hi Jas,
ReplyDeleteNo 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)
Hi,
DeleteI 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 = {
Many thanks Jas,
DeleteI 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).
Great you got it working! 305 is a good score but at what resolution?
DeleteThe screen resolution was 1280x720, but the glmark-es2 window was less than half of that.
DeleteWill there be again a readymade image just for writing onto a SD-Card? So we get the most updated thing of your great work.
ReplyDeleteHi, 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.
DeleteI thought you already did a GK802 image in past... so i am sorry... my mistake.
ReplyDeleteWhen you have some time, can you make a small guide with the commands to configure the kernel for wandboard and make it ?
ReplyDeleteThanks
By the way, are there a branch for wandboard ? In the branch list, I dont see a wandboard branch, only udoo, utilite, solidrun etc...
ReplyDeleteHi,
DeleteAs 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
Hi,
ReplyDeleteI'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/
Hi, sent you a message via your contact page.
DeleteWhat does this imply from your X log?
Delete[ 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
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.
DeleteWhat is the ENGR00264288 patch? I can't find an on line reference to it - it seems to have been taken off-line by Freescale.
DeleteIgnore 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:
Deletehttps://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.
Hi, Eric has got my rootfs working on the Nitrogen6x.
DeleteI placed an image on our cloud storage site. Because it contains Freescale content, we do require registration and acceptance of the EULA.
Deletehttp://boundarydevices.com/eula?file=xubuntu_13.04_gpu-nitrogen6x-20131203.tar.gz
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:
Deletehttps://github.com/boundarydevices/linux-imx6/commits/boundary-imx_3.0.35_4.1.0
Hi Jas,
ReplyDeleteCan 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.
Hi Jas,
ReplyDeleteI 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!
Hi,
DeleteFor debian, the mesa libraries are probably in different locations compared to ubuntu.
This comment has been removed by the author.
ReplyDeleteHi Jas,
ReplyDeleteI 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!!!
It won't with work xserver versions greater than 1.14.
DeleteOh, you are right. I completely forgot to check xserver version. Thanks!
DeleteI 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?
Hi jas,
Deletei am also trying same and my xserver is able to load vivante driver es2gears i am able to run but when i am running glxinfo and glxgears my xserver is getting crashed.my xserver version is 1.15.As you mentioned it will not work after 1.13.just want to know why it will not work with version greater than 1.14
It depends which BSP you are using to which Xserver version is supported.
DeleteHi Jas,
DeleteI just tried with xserver version1.13 and also tried Xorg 1.15 with BSP xserver-xorg-video-imx-viv-5.0.11.p7.4 but didnt worked i tried gmem_info it is giving the information.
BSP imx-gpu-viv_5.0.11.p8.4 is for Xorg 1.18 or Xorg 1.17
DeleteHi Jas,
ReplyDeleteI 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
You need to ensure the fb versions of FSL libraries (eg libEGL.so, liblGLESv1_CM.so) are deployed not the X11 instances.
DeleteYou need to ensure the fb versions of FSL libraries (eg libEGL.so, liblGLESv1_CM.so) are deployed not the X11 instances.
DeleteI have the fb versions of FSL libararies.
Deleteroot@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?
It is giving errors while compiling:
Deletegcc -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
The following should be symlinks to libGLESv1_CM.so.1.1.0, but they are not:
Delete-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
I tried with this:
Deleteroot@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?
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).
DeleteCan you check if libEGL.so has its dependency libraries by:
ldd /usr/lib/libEGL.so
The following should be symlinks to libGLESv1_CM.so.1.1.0, but they are not:
Delete-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
This is what i got.Is it right or something is missing?
Deleteubuntu@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)
symlinks to libGLESv1_CM.so.1.1.0 are present.
Deleteubuntu@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
If you look at the error it is reporting:
Delete/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.
Thanks Jasbir. I got it right.
DeleteI 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
Sudipta, great you it working!
DeleteHi 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?
ReplyDeleteI 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.
DeleteIs there anything i need to check for?
Framebuffer libraries don't need vivante_dri.so or fbdev_drv.so that is for X11.
DeleteUnfortunately it is difficult to diagnose without knowing more about your environment setup and how you are launching the samples.
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.
DeleteThe 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?
How are you trying to validate that acceleration is working using the fb libraries?
Deleteusing "top" command i am trying to see if the binary is running
DeleteThere i can see if it is running on cpu , if it is not there then it is sure to be running on the gpu.
DeleteThe 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.
DeleteOk. Thanks Jasbir. But, will the percentage usage of cpu come down if it hits the gpu?
DeleteAnd 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
Unfortunately I can't give you figures because it depends on many factors eg resolution, dual/quad core, board vendor .. etc.
DeleteIf your a commercial venture then as a suggestion, I can provide short term consultancy to aid your development.
Anyway thanks Jasbir.
DeleteBut, will the percentage usage of cpu come down if it hits the gpu?
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.
DeleteThis comment has been removed by the author.
DeleteThis comment has been removed by the author.
Delete