Fixed memory leak in pgge

Nasty memory leak has been present for the last 10 months! It was found by running on the Android device, after about 10 minutes the fireworks start:

D/dalvikvm: GC_FOR_ALLOC freed 3603K, 14% free 31246K/36280K, paused 176ms, total 176ms
D/dalvikvm: GC_FOR_ALLOC freed 3585K, 14% free 31666K/36684K, paused 183ms, total 183ms
W/Adreno-GSL: : sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
E/Adreno-GSL: : GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
W/Adreno-GSL: : sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
E/Adreno-GSL: : GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
A/libc: Fatal signal 11 (SIGSEGV) at 0x61860398 (code=2), thread 25200 (Thread-2710)
Application terminated.

If one had been paying any attention to the Android console log, it would have been evident that the GC is staying WAY too busy! Creating new instances at every render will definitely leak away the memory! Several hours to find the issue, only a minute to fix it! 

Pretty Good Game Engine is 1 Year Old!

One year ago I started a new github repo, a new programming project using libGDX.

The purpose of the pgge project is to demonstrate the libGDX 3D API and Bullet physics integration in a 3D game engine.

The project is developed using Android Studio for Java development, and Blender to create 3D models. Thanks to libGDX multiplatform capability, the program can be run on an Android device or on PC desktop.

Hope someone has a chance to check it out!

Compatible OpenGL / OpenGL ES games on i.MX6

If you happen to have an ARM development board sitting around, you may be thinking about plugging it into your nearest HDTV to play some games. While the ultimate gaming computer is probably not going to be built around a single-board computer such as ODROID or Raspberry PI, it might be interesting to see what such a device is capable of. I was looking for games that would utilize the OpenGL|ES capability provided by the i.MX6Q processor, but there aren't that many compatible Linux games out there, with most still using the standard "desktop" OpenGL. Many of the similar ARM SOCs provide only GL|ES and do not support OpenGL at all, but the i.MX6Q at least supports some part of the OpenGL 2.1 specification. To help me keep track of the results, I started creating my own "ultimate guide" for GL/GL|ES compatible games on i.MX6Q and maybe others might find this information useful as well.

In order to make my list, I require that the game will run full-screen with "reasonable" FPS, and utilize the hardware GL or GL|ES capability of the i.MX6Q (refer to my previous posts how the system is setup). However, on the Sabre Lite and SabreSD boards that I'm using, I found that many of these games don't set the video mode properly, but it can be done manually using xrandr prior to running the game. I am also trying to keep track of some different monitors that I am using (a 4:3 A/R Dell, a 1920x1080 RCA HDTV, and our new 55" Samsung HDTV), as the aspect ratio may affect what modes are available to the game.

As I mentioned in the introduction above, I found only a couple of games so far that are using GL|ES graphics on Linux, these are:

• Trigger Rally, ported to OpenGL|ES by ptitSeb (libGLES_CM)
• Hurrican, ported by pickle (libGLESv2)

The i.MX6Q supports at least a part of OpenGL 2.1 and I have found a half dozen or so titles that are compatible, including an early version of Neverball. I have found quite a few more games that will run if linked to a special implementation of libGL called glshim. The glshim library was devised by lunixbochs for the purpose of "providing OpenGL 1.x functionality to OpenGL ES accelerated cards" (and thus to to expand the available games for the Pandora ... and possibly other platforms). As stated glshim provides "parts of OpenGL 1.x by internally translating to OpenGL ES". By now, glshim has found its way from the Pandora world to other ARM platforms such as Odroid, and i.MX6. I am using the ptitseb branch as I found it would allow a few games to run that the lunixbochs version wouldn't, but at this time I have not bothered to see what the functional differences are between the two versions.

Running the game executable with glshim may be as simple as invoking it with LD_CONFIG_PATH. However, I seem to find that I have to re-link the executable, else it tends to defer to the libGL.so which is already installed on my system. This is easily done be replacing '-lGL' with e.g. '/usr/local/lib/glshim/libGL.so' in the link command.

One final comment is that out of the dozen or so games that I have built and found working with glshim, all are using libSDL-1.2, with the exception of CaveExpress (libSDL2-2.0). 

Enjoy!

Trigger Rally GL|ES on i.MX6Q

Trigger Rally, "a fast-paced free software rally racing game", was ported some time ago to OpenGL|ES on Open Pandora by ptitSeb. Here's a link to the SourceForge browser at Revision: 96 where the Pandora branch was made. With a bit of additional footwork, I was able to build it on an i.MX6 quad-core and it seems to run pretty well. Trigger Rally has undergone considerable development since that branch was made, so it might be a good exercise to forward-port those GL|ES patches to the current version! 

Build Environment
The build environment is hosted on an i.MX6 quad-core platform running Debian “jessie” release. The system relies on closed-source VIVANTE GPU libraries for Freescale i.MX6 being installed. Please see previous posts for details on setting up the root file system to support accelerated GL/GLES functionality in Debian.

Prerequisite  Binary Packages

apt-get install cmake jam libsdl-image1.2-dev libopenal-dev libalut-dev libphysfs-dev

Build GLU ES 

TR depends on GLU ES implementation (gluScaleImage) - latest source ported by lunixbochs (GLU ES version 1.5 based on original GLU 1.3) is on GitHub. 

git clone https://github.com/lunixbochs/glues.git
cd glues ; rm -f CMakeCache.txt ; cmake . ; make

If the build is successful, the library file libGLU.so.1 will have been created. There is no install target - maybe there is better way, but I simply copy the two needed header files so they will be found by the build in a system include path:

cp lunixbochs/glues/source/glues.h  /usr/local/include/GLES/
cp lunixbochs/glues/include/SDL/SDL_opengles.h  /usr/local/include/SDL/

Build TR
Define LINUX in trigger-rally-pandora/Jamrules; otherwise header file /usr/include/EGL/eglvivante.h (part of Freescale imx-gpu-viv bundle) throws an #error "Platform not recognized":

sed -i 's/COMPILER_CFLAGS += -Wall/COMPILER_CFLAGS += -Wall -DLINUX=1/' Jamrules

Please note that this project uses jam (and not make) as build tool:
./configure ; jam

If you did not copy over the header files from GLU ES, you are probably seeing a couple of errors from the build:

src/pengine/pengine.h:39:24: fatal error: GLES/glues.h: No such file or directory

/usr/local/include/GLES/glues.h:37:33: fatal error: SDL/SDL_opengles.h: No such file or directory

Eventually, the linker fails due to library specification -lGLUES_CM:

/usr/bin/ld: cannot find -lGLUES_CM
collect2: error: ld returned 1 exit stat

Rather than take the time to tweak the jam scripts to fix the problem correctly, immediate gratification is had by manually linking the trigger executable in the shell: remove -lGLUES_CM from the linker invocation, as well as the library path specification -L/usr/lib/arm-linux-gnueabihf, and link directly to the GLU  ES library libGLU.so.1 as follows:

g++ -Wall -DLINUX=1 -O3   -DDATADIR='"${prefix}/share"' -DHAVE_GLES -DPANDORA  -o trigger ./out/armv7l-unknown-linux-gnu/opt/src/trigger/eglport.o ./out/armv7l-unknown-linux-gnu/opt/src/trigger/game.o ./out/armv7l-unknown-linux-gnu/opt/src/trigger/main.o ./out/armv7l-unknown-linux-gnu/opt/src/trigger/render.o ./out/armv7l-unknown-linux-gnu/opt/src/trigger/menu.o  ./out/armv7l-unknown-linux-gnu/opt/src/pengine/libpengine.a ./out/armv7l-unknown-linux-gnu/opt/src/psim/libpsim.a   -lSDL -lSDL_image -lEGL -lGLES_CM  -lopenal -lalut -lphysfs ../glues/lunixbochs/glues/libGLU.so.1 

(use jam -n to get the g++ command)

Success!

No need to run the make install, the trigger executable will run fine if invoked from within the project "./data" directory:

cd data ; ln -s ../trigger

xrandr -s 800x600   # TODO: it can't seem to change resolution on it's own!
LIBGL_DEBUG=verbose ./trigger



Enjoy!

Hurrican 2D Platformer on i.MX6 Sabrelite

Hurrican is a retro/16-bit styled 2D platformer that I was able to build from source on an i.MX6 Sabrelite board with essentially zero effort, as it has already been ported to SDL 1.2 and GLES2.

Some background info may be of interest on the forum posting at Phoronix. Apparently Hurrican was entirely a Windoze game ported to Linux-SDL-GL by pickle who is pretty active on the Open Pandora Pyra community, which I have been looking at quite a bit lately to research games and GL stuff to try out on the i.MX6 board.

This one builds and runs "out of the box" as they say on my system, with great sound music, keyboard control and no obvious glitches.

Repository Root: svn://svn.code.sf.net/p/hurrican/code

sdl1.2 is installed from the distribution and apparently with GLES2 target enabled ...

apt-get install libsdl-mixer1.2-dev libsdl-image1.2-dev libsdl1.2-dev libmodplug-dev
cd hurrican-code/Hurrican/src/
make TARGET=linux_GL2  # this will link with -lGLESv2

I should get a screenshot of the thing running but even better is gratuitous nerdy console output showing all the startup logging gotta love it ...



More info on Hurrican over at Odroid forum.

mesa demos revisited on i.MX6

In my quest to better understand GL/GLES I previously setup an Debian environment on i.MX6 and installed Freescale support libraries to enable hardware accelerated GL functionality.

Download source for mesa-demos-8.3.0.

Build is done in native armhf environment on the i.MX6 Sabre-lite. With usr libraries and headers installed, the following error is seen in the build:

 /usr/include/EGL/egl.h:39,
                 from eglut.c:32:
/usr/include/EGL/eglvivante.h:242:2: error: #error "Platform not recognized"
 #error "Platform not recognized"

Use the following configure to define platform LINUX:

CFLAGS=-DLINUX ./configure --enable-vg=no

(configure detects "vg" available on my system but throws many compile errors which I don't care to deal with for now so use --enable-vg=no   to avoid additional errors)

The following modules are automatically enabled from the above configure line ... one outcome I didn't check for was situation with GL support (what any header files are supplied with support libraries):
checking for GLEW... yes
checking for GLU... yes
checking for EGL... yes
checking for GLESV1... yes
checking for GLESV2... yes
checking for OSMESA... no
checking for DRM... yes
checking for X11... yes
checking for GBM... yes
checking for FREETYPE2... yes

The following error is seen in the build  ... assume at least in this case it is a benign side affect of co-mingling locally built packages with chip vendor support libraries:

/usr/bin/ld: warning: libGL.so.1, needed by /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../arm-linux-gnueabihf/libGLEW.so, may conflict with libGL.so.1.2

Demos in src/egl/opengles1, src/egl/opengles2 working.

Some in src/demos working, some not, some real slow.

Most in src/tests apparently not ... glutfx full screen but otherwise not interesting.
I noticed from eglinfo that there is no 'gl' context so don't expect anything from src/egl/opengl to work.

debian@arm:~/src/mesa/mesa-demos-8.3.0/src/egl/opengl$ DISPLAY=:0 LIBGL_DEEBUG=verbose ./eglinfo -info

EGL API version: 1.4

EGL vendor string: Vivante Corporation

EGL version string: 1.4

EGL client APIs: OpenGL_ES OpenVG

EGL extensions string:

    EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_image

    EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image

    EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image

    EGL_KHR_lock_surface EGL_KHR_create_context

    EGL_EXT_create_context_robustness EGL_EXT_buffer_age

EGL client extensions string:

Configurations:

     bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported

  id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 

---------------------------------------------------------------------

0x01 12  0  4  4  4  0  0  0  0 0 0x21--      a     y  y     win,pb

0x02 12  0  4  4  4  0  0  8  0 0 0x21--      a     y  y     win,pb

src/xdemos/glxgears is good to go: 

debian@arm:~/src/mesa/mesa-demos-8.3.0/src/xdemos$ DISPLAY=:0 LIBGL_DEBUG=verbose ./glxgears
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 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports platform:Vivante GCCore:00
748 frames in 5.0 seconds = 149.467 FPS
752 frames in 5.0 seconds = 150.196 FPS
^CProcess termination by interupt!
debian@arm:~/src/mesa/mesa-demos-8.3.0/src/xdemos$   

This patch against mesa-demos-8.3.0 incorporates these various hacks and fixes including one known issue regarding undefined reference to `glWindowPos2iARB'.



Good luck!

HP Omen i7 Quadcore + Ubuntu 15.10 AMD 64

Finally a new computer, first one in a few years.

HP - OMEN 15.6" Touch-Screen Laptop - Intel Core i7 - 8GB Memory - 256GB Solid State Drive on sale at Best Buy.

How annoying is it, machine is unusable until you activate Windows 8 with a Microsoft registration. No matter, here comes Ubuntu 15.10 AMD 64 ...

Using usb-creator, configured a USB flash drive for installing Ubuntu 15.10 AMD 64 ISO.

On power up hold keys FN-F10-ESC, then F9 accesses "Boot Device Options" ().

• Select "USB Hard Drive (UEFI) - SanDisk Cruzer"
• On the flash disk Ubuntu boot menu, select "Try Ubuntu without installing" (from "Install Ubuntu" it would not consistently boot from the USB)

All 4 USB ports are on the back of the machine which is occasionally annoying. Several tries to get machine booted from USB, and the boot makes a lot of noise about "Nouveau PIBUS 0xbadf1100" on startup console which seem to hang the machine. When the machine finally booted it locked up several times for no apparent reason and had to be forcibly rebooted. Doesn't seem to be any consistency to this so I suspect (and hope) merely a quirk related to the USB bootable system.

Hang in there and eventually the thing gets booted - waited to plug in HP supplied USB-Ethernet adapter until the machine successfully made all the way to the desktop. Finally, select "Auto Ethernet" from the connections menu (interface is reported by ifconfig as enx0050b67d3ecc).


As far as for configuring the AC 7260 WiFi ... this doesn't seem to work until only after making the modification to modules configuration as shown below (so after OS install this can certainly be fixed,  but use of WiFi during install from Ubuntu 15.10 environment booted from USB stick may be possible by rmmod'ing acer_wmi and related modules and re-configuring the wlo1 interface).


Selected "Download updates while installing".
Did not select "Install the third party software".



Not my screen shot here but as I recall the default partitioning of the 256 Gb SSD drive left about 120 Gb available for a Ubuntu partition - and presumably I won't have problem erasing Windows and re-partitioning and reclaiming 100 or so Gb of SSD. As unpacked out of the box, there is a Windows 8.1 un-activated install - selecting option to Install alongside; subsequent (re)installation attempts do not encounter this dialog but rather the following one (Installation type)  ...

"Installation type" ... "Erase Ubuntu 15.10 and reinstall"

With the following added to /etc/modprobe.d/blacklist.conf, AC 7260 WiFi is working on wlo1 :

blacklist acer_wmi

(Edit: In the live CD environment, rmmod acer_wmi to unload the kernel modules, then restart networking with the command service network-manager restart).

After a bumpy start installing Ubuntu 15.10, once the install process is done it only takes a few seconds to boot the machine. On sporadic occasions the machine fails to boot and returns to the BIOS boot manager a few seconds after attempting Linux boot from the GRUB menu.

One final observation is that on power up the machine always stops at Boot Manager requiring the manual selection of "OS boot Manager (UEFI) - ubuntu (SanDisk SD6PP4M-256G-1006)".

Update: after significant frustration with erratic system hangs, and also reverting to Xubuntu 14.04 in the process, I did some webbing for laptop-suspend problems and got the impression those problems were often related to display drivers. Searching the device "NVIDIA Corporation Device 139b" as reported by lspci yielded some helpful info and having upgraded the video driver from the xorg-edgers ppa the (resume from) suspend seems to work.