Test-driving the Mali OpenGL ES Emulator

Hello all,

My name is Dale Whinham, and I’m an intern within the Media Processing Group at ARM. I have been working with ARM over the summer to produce some additional sample code for the Mali SDK, which is freely downloadable for your platform of choice over at our SDKs section here: http://malideveloper.arm.com/resources/sdks/

In this blog post, I wanted to talk a little bit about my experiences with the Mali OpenGL ES Emulator, which saw some significant updates recently, as detailed by lorenzodalcol in this previous blog post: http://community.arm.com/groups/arm-mali-graphics/blog/2015/04/10/whats-new-in-mali-graphics-debugger-21-and-opengl-es-emulator-21

I am very new to OpenGL (ES) development, so currently I rely fairly heavily on good debugging tools to help me understand where I might be going wrong. As a newcomer to graphics development, I learned fairly quickly that staring at a black screen for several hours is normal and okay when you are just starting out, as there are quite a lot of things you need to do to prepare your OpenGL context for rendering, such as allocating vertex buffer objects, filling them with data, compiling shaders, getting handles to their attributes and uniforms, and so on. This in itself can be quite overwhelming at first, especially when it’s difficult to see what’s going on inside OpenGL, because you’re cross-compiling native code for an Android device, and debugging options are more limited.

One of the challenges I was faced with was that I struggled to get debugging to work properly for native code in Eclipse with Android Development Tools (ADT).

So, a bit of context: at the time of writing, Google have now deprecated support for Eclipse with ADT, in favour of their new Android Studio IDE – which is great news for Android Java developers, as the IntelliJ platform makes for a very rich and stable IDE, but not-so-great news for developers writing C/C++ code, as Android Studio’s native code support is still in its early stages at the time of writing. Until the tools mature, Eclipse with ADT is still relied on by many developers to write and build native code for Android.

As such, I just couldn’t get the Eclipse debugger to co-operate and set breakpoints on my native Android code. I found myself spending more time on StackOverflow trying to find solutions to problems with Eclipse than I did actually writing the code, and so I started looking for another strategy!

I was made aware of the Mali OpenGL ES Emulator, which is a comprehensive wrapper library for OpenGL that allows you to write code for the OpenGL ES API, but have it run on a desktop computer with desktop OpenGL. This would allow me to work on my project on the desktop, get it working the way I wanted, and then move it back into Eclipse and rebuild for Android later. The Mali Linux SDK actually comes with Microsoft Visual Studio project files, and you can build and run the samples for Windows if you have the Mali OpenGL ES Emulator installed. I decided to migrate my project to Visual Studio 2015 so that I could design and debug it on the desktop more easily, though I could have also chosen to use Linux-based tools, as the Mali OpenGL ES Emulator provides a Linux version too.

The installation procedure is quite straightforward. There are two flavours of the Mali OpenGL ES Emulator to download – 32bit or 64bit – and you’ll need to install the version corresponding to your build target, i.e. whether you’re compiling for 32bit or 64bit. You can, of course, install both if you’re building for both architectures, but beware of mixing up the ”bitness” – if your app is compiled for 64bit but tries to load the 32bit emulator DLLs, it may crash.

Once installed, configure your project to search for headers within the “include” directory inside the Mali OpenGL ES Emulator’s installation folder – e.g. for the 64bit version on Windows, for me it was C:\Program Files\ARM\Mali Developer Tools\Mali OpenGL ES Emulator 2.2.1\include (see Figure 1). This folder contains header files for EGL and OpenGL ES 2 and 3 as well as their extensions.

Figure 1: Setting additional include directories in Visual Studio. Note the semicolon is used to add multiple directories.

Additionally, configure your project to add the installation folder to your list of linker search directories, so it can link against the wrapper libraries (see Figure 2):

Figure 2: Setting additional library directories in Visual Studio.

Once you’ve done this, you’re pretty much ready to go. On Windows, the Mali OpenGL ES Emulator installer sets your system’s PATH environment variables so that your compiled application will find the OpenGL ES libraries correctly at runtime. You can now begin writing code as if it were for a mobile GPU by including the OpenGL ES headers in your source code, and calling OpenGL ES functions as normal.

Figure 3 shows a screenshot of the Mali OpenGL ES emulator in action, showing a simple 3D scene from one of my work-in-progress code samples. The code sample has some glue code to give me a Windows GUI window, but the rendering context and draw calls are all EGL and OpenGL ES – wrapped seamlessly to desktop OpenGL by the Mali OpenGL ES Emulator:

Figure 3: A simple 3D scene being rendered in OpenGL ES using the Mali OpenGL ES Emulator

In addition to being able to use the powerful Visual Studio debugger for my C++ code, a major benefit of the OpenGL ES Emulator is that I can stack desktop OpenGL debuggers on top of it.

For instance, what if I wanted to check the geometry of my 3D models with a wireframe view? Well, in desktop OpenGL I could just use glPolygonMode() with GL_LINE as the mode parameter, but in OpenGL ES we don’t have this function and so we would have to write a shader.

Alternatively I could use the force wireframe feature of an OpenGL debugger. Enter GLIntercept (https://github.com/dtrebilco/glintercept), a powerful open-source OpenGL debugger for Windows that comes with a multitude of features, including (but not limited to) run-time shader editing, the ability to freely move the camera, texture/framebuffer dumping, and wireframe rendering. By placing its special OpenGL32.dll into the same directory as our application executable, along with a configuration file that lets us pick the debugging features we’d like to enable, it intercepts all calls to OpenGL, allowing us to tweak the behaviour of OpenGL before it gets forwarded to the GPU driver.

In Figure 4, we can see that same scene again, but with GLIntercept enabled, forcing wireframe on, and allowing me to see the geometry of my 3D objects without having to change the code of my project:

Figure 4: The same 3D scene using the wireframe debugging feature of GLIntercept

This is just the tip of the iceberg of what is possible with the Mali OpenGL ES emulator. It supports many OpenGL extensions such as ASTC texture compression, and extensions from the Android Extension Pack – a collection of extensions found in Android 5.0+ that gives you many advanced rendering capabilities, making it a powerful addition to your development tools. With a reasonably-specced graphics card in your PC, you can save a lot of time developing applications that use these features by eliminating the process of loading your code onto a development device from your workflow – at least in the earlier stages of development, when recompiling and testing may be quite frequent.

For more information about the Mali OpenGL ES Emulator, check out our product page over here: http://malideveloper.arm.com/resources/tools/opengl-es-emulator/

Make sure you grab the PDF User Guide from the download link too, for a comprehensive manual that gives you all the technical details about the emulator, including system requirements for the host PC, supported extensions, texture formats and much more!