Author Archives: Martyn Bliss

7 New Video Uploads from the Samsung LPGPU2 Team!

Today Samsung has uploaded videos for 7 of their Vulkan test apps. Find out more about each one, including why it was written the way it was, and what we hope the LPGPU2 tool will identify when analysing them:

The LPGPU2 Vulkan Raymarching test app is designed to test the LPGPU2 profiling tool’s ability to analyse GPU compute-bound scenarios. All of the work for this app is confined to the fragment shader, which involves a computationally expensive loop detecting the distance a ray travels into the scene before colliding with geometry.

The LPGPU2 Vulkan Overdraw App displays a stack of translucent sheets that span almost the entire display area. The stack can be drawn either front to back or back to front. Can the LPGPU2 profiling tool detect a difference between these scenarios, and what are the implications of having many pixels repeatedly overdrawn?

The LPGPU2 Vulkan OverdrawTex App is geometrically identical to the Overdraw App – it displays a stack of translucent sheets that span the display area. The difference is that instead of colouring the triangle with a simple interpolation between values, a texture lookup is invoked. What happens when many more texture lookups are issued than there are pixels? Can the LPGPU2 profiling tool recognise this scenario?

The LPGPU2 Vulkan Menger Sponge app has a variable amount of geometry and a variable amount of detail on that geometry. The detail is implemented through a multi-level fragment shader algorithm. The result is an app that has a tuneable volume of geometry and independently tuneable compute burden.

The LPGPU2 Vulkan Hypercube app displays a representation of a 4D hypercube as it tumbles about the three most interesting planes of a 4D space. The scene contains a small amount of geometry and uses almost trivial shaders. The app is designed to have a low graphics overhead to find out what the LPGPU2 profiling tool reports in that situation.

The LPGPU2 Vulkan Globe app simulates a cloud-covered earth spinning in a starry sky. The number of cloud layers is variable, resulting in an app that specifically stresses the texture capabilities of the GPU.

The LPGPU2 Vulkan Uber app is the ‘kitchen sink’ of tests with its high levels of geometry, many textures, and heavy fragment- and vertex-processing, resulting in a low frame rate and very slow start-up time. Can the LPGPU2 profiling tool pick it apart?


Verifying behaviour with the LPGPU2 Toolsuite

Yesterday I was looked at the behaviour of one of our test apps (you can see an example of the sort of thing here  ) after observing it behaving strangely on one of our test devices.

The application I was using runs through a set of ‘apps’ for a fixed number of frames and then loops. The first app being run was running slowly and not as fluidly as the others.

The first thing I did was to take a capture with the LPGPU2 tool and get a high level overview of what was occurring:

Screen grab from tool – click to zoom

All of the counter data you can see if live and valid and reflects the system state at the time the graphics API calls from the application were being captured (GLES and EGL in this case).

Take a closer at the Regions of Interest (ROI) (shown in a blue gradient) and frames (shown in green)ribbons:

ROI and frames ribbons – click to zoom

In the above you can see that there are ROI that correspond to the heavy content being equally spaced along the timeline. You can also see how these ROI align with frames.

The more astute of you may notice that the ROI and frames are not completely consistent yet, but this is all part of the toolset validation and will be addressed as the project progresses.


LPGPU2 D5.3 Demonstration Video

In this the third video, we show off some more of the new features of LPGPU2 CodeXL including some of the new visualisations that are now available. In the video, we demonstrate the typical work flow for carrying out a power data profile capture session. Included in this workflow we also show you how to run the data analysis Feedback Engine to receive advice on issues found in the capture data.


The DC API, developed by Samsung and implemented by Think Silicon, TUB and Samsung is used by the application on the remote device which in this case is a standard Nexus Six Android phone to generate profile data sent over to CodeXL.

The visualisations seen in LPGPU2 CodeXL to display the API calls, frames and performance data along with the Help and feedback visualisations were created by Codeplay. The Feedback Engine’s advice, written in Lua by Samsung, is first seen in the power profile view as a Help ribbon under the frame data as Regions of Interest (ROI). From there a user can drill down to specific areas of interest or examine the advice given for that region in time.

Last but not least is a powerful new feature which allows the user to be able to compare the current profile session or any previous profile session with others so you are able to visualise graphically any differences for a counter over time.

Website refresh coming soon!

It’s been a wonderful year for LPGPU2 and next year is set to be even better!

To kick things off in style we’re going to have a refresh on the website, so watch this space!

Best wishes from all the LPGPU2 team!


Improving the look and feel of a pie chart

When developing the user interface for an application, no matter the platform, a great amount of time is spent refining the look and feel of the widgets that users interact with.

Sometimes, the GUI framework being used helps in this job, but sometimes there is the need to write your own versions of a known widget.

The LPGPU2 consortium is working on extending CodeXL with new functionality for profiling low-power GPUs. CodeXL’s user interface is developed using Qt 5.5, which is quite old by modern standards. This means that we have to write custom widgets once in a while in order to achieve our goals.

One of the visualisations we aim to provide is a pie chart. Pie charts are good for showing proportions of one group of elements relative to a set. However, Qt 5.5 does not provide some of the off-the-shelf chart components we require, so we had to develop our own pie chart.

Drawing a pie chart requires some calculations, but once that is sorted out we need to find the right look and feel for it.

The first version we came up with was far from ok, but it served to prove the point and allows us to keep working on the prototype (Before image). Unfortunately, there were a lot of things that didn’t feel right about the first version. The pie edges were drawn using black and they were quite jagged. The text for the labels was too big and very hard to read when confined in a small space. Finally, it was very difficult to associate the percentage amount of the corresponding label.

In order to improve this, the pie edge colours are now a light grey, this removes the attention from the edges and directs the eyes towards what is important in a pie chart: proportion. A small reduction in the font size combined with a better placement of the labels allows the association of a pie and label to be made more easily.

To remove the jagged edges, since we are using Qt, one can specify antialiasing flags to the object used for the actual drawing:

QPainter painter{ this };

painter.setRenderHints(QPainter::Antialiasing | QPainter::TextAntialiasing | QPainter::HighQualityAntialiasing);

The last flag is only used when this component is used with an OpenGL renderer is available.

The following screenshots give an overview of how the look and feel of the pie chart widget was improved by this change. (Click to zoom)

Original View

Modified View

OpenCL application captured and analysed by LPGPU’s Feedback Engine!

The screenshot below shows an OpenCL android application running on a Samsung device captured by the LPGPU2 tool suite and the captured API calls and performance counters (note synthetic counters were used in this test) used to provide feedback on possible ways to improve your application:

(click to zoom)

Adding a Scripting Language to CodeXL

One of the goals of the LPGPU2 project is to provide an application to enable developers to target non AMD low power devices running open standard APIs like Vulkan or OpenCL to analyse GPU performance versus efficiency with their applications in order to allow them to write code is efficient manner extending battery life.

CodeXL was chosen as the base tool for the LPGPU2 project for many reasons, but we can highlight a few important ones:

  • It is open source
  • It has a wide range of functionality already implemented
  • It is cross-platform
  • It is already familiar to developers as a profiling tool

CodeXL has a quite large code base. It can be considered a mature and established tool with many features but one key feature is missing in its architecture is a component to perform scripting. Adding a scripting component would allow an easy extension to existing functionality while also opening up the possibility to query CodeXL profiling sessions and the data with.

In this post, we are going to explore the process of adding Lua as a scripting language for LPGPU2 CodeXL in order to facilitate the advanced analysis of power profiling sessions is in quick customisable manner.

The choice of Lua as a scripting language

From the Lua website we read:

Lua is a powerful, efficient, lightweight, embeddable scripting language. It supports procedural programming, object-oriented programming, functional programming, data-driven programming, and data description.

Compared to other scripting languages, Lua is very compact with no external dependencies. It was designed to be embedded in applications and it has a simple but powerful C interface. With this in mind, we can easily expose CodeXL API to Lua scripts. In the summary table below you can see a breakdown by lines of code of the Lua component:

Language Files Blank lines Comment lines Code lines
C 35 2787 2481 14585
C/C++ Headers 26 1111 1132 2010
Make 1 39 10 148
Sum 62 3937 3623 16743

This data was obtained using CLOC 1.72 (, and the Lua version is 5.3.4.

As you can see not much to add a new language and open up the possibility for automation or other capabilities.

What will Lua developers have access to inside CodeXL

Currently, the Lua component has been embedded in the CodeXL project to expose the LPGPU2 extended CodeXL database layer to Lua so that it can have access to the power profiling session data. The database layer of CodeXL provides the abstraction of an SQLite database used to store data for profiling sessions. Lua scripts will have access to the database allowing it to read and write the data collected during a profiling session. Figure 1 has a diagram showing how the Feedback Engine was positioned inside CodeXL.

Figure1: Diagram showing where the Feedback Engine was inserted into CodeXL.

What the LPGPU2 project is doing with Lua

Samsung, a LPGPU2 consortium partner, is developing a Lua Feedback Engine. The goal of the Feedback Engine is to provide an in-depth analysis of an application’s power profile session that came from running on a remote device’s profile such as a standard Samsung Galaxy S7 phone. The user performs a power profile analysis session after which the user can ask the Feedback Engine to analyse the data and suggest optimisations. In real time, the profile data displayed and stored in an LPGPU2 modified CodeXL database (it remains standard CodeXL compatible) which the Feedback Engine has access too. This is one of the many achievements of the work carried out by the LPGPU2 project shown in the following video. In order to provide a more detailed analysis of an application, we extended CodeXL’s Power Profiling mode to allow the capture of different GPU API calls with the objective to associate power consumption data with their respective function calls. With this data in their hands assisted by the Feedback Engine, developers can easily find hotspots regarding power consumption and quickly iterate to lower power consumption, therefore delivering a polished application to their users that will last longer on battery powered devices.

Compiling Lua

The compilation process of Lua is straightforward. On Visual Studio, just create a new project inside your solution, add all the files from the source folder and you are done. In order to modularize the code, we decided to build Lua as a DLL on Windows. For this one just need to define the preprocessor macro LUA_BUILD_AS_DLL on both the project that generates the DLL and the projects that are going to use the DLL.

On Linux, there is the possibility to use the provided Makefile to build Lua with a simple make command, but CodeXL uses the SCons build system. Like Visual Studio, it was just a matter of creating a custom SConscript file to generate the Lua library to be used across CodeXL modules.


Scripting is powerful tool anyone can add to an application in order to provide easy extension and development. Scripts don’t require compilation and linking, therefore they allow for a very fast iteration cycle with a rapid prototype of new functionality. In the case of LPGPU2 CodeXL, the ability to have scripted behaviour has allowed the LPGPU2 project to provide rapid development of advanced features within the tool, in particular, we are enabling advanced analysis of an application power profiling data in order to allow developers to extract maximum performance whilst keeping the battery of mobile devices alive.



Windows support coming online for LPGPU2!

Samsung and Codeplay have been working together very closely on the LPGPU2 fork of AMD’s CodeXL. In the last day or so we performed the first captures from an Android device (Samsung S6) from a Windows host!

Timeline view (click image to zoom)

Regions of Interest (ROI) view (click image to zoom)

These visualizations are still in flux and are intended to give a ‘feel’ of the final version rather than being definitive.


Samsung’s Game Developer page now active!

Samsung have launched a page to track resources for game developers on Samsung devices. I’m sure the LPGPU2 tool suite will be added once it’s publically available!

Find out more here:


Codeplay add OpenCL kernel code coverage!


By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.