LPGPU2 Font Renderer App

Transcription

1 LPGPU2 Font Renderer App Performance Analysis 2 Introduction As part of LPGPU2 Work Package 3, a font rendering app was developed to research the profiling characteristics of different font rendering algorithms. Screenshots of the app in Figure 1 show a quantitative difference in the three rendering modes. This is because the Font Renderer app was developed to investigate the disparity in CPU versus GPU utilisation for different algorithms, and not as a tool for the inter-comparison of those algorithms per se. More details can be found in D3.1. Since its initial development, the LPGPU2 Profiling tool has many new features and capabilities; the Font Renderer app was updated to leverage this, and the process of updating the app is described elsewhere. The LPGPU2 Font Renderer app offers three modes of operation: SKIA (the default CPU based android implementation), Loop-Blinn (an efficient GPU font rendering method developed by Charles Loop and Jim Blinn), and Stencil and Cover (the Loop-Blinn method drawn to the Stencil buffer and post coloured with large triangles spanning the display area). The present study focuses on SKIA the android default method, and Loop-Blinn, a geometrical technique target at the GPU. a) SKIA b) Loop-Blinn c) Stencil and Cover Figure 1 Font Rendering Modes

2 Analysis: SKIA The LPGPU2 Profiling Tool was used to collect data for SKIA mode in two separate experiments. Experience in profiling many apps throughout LPGPU2 has shown the need for repeat experiments, as more often than not, results vary wildly between runs. This is because the device system is complex with many demands on its resources, multiple daemons running, and timed events firing off all the time. At first glance, the resulting profiles from the two SKIA experiments, shown in Figure 2, seem to be very similar indeed; an initial burst of power settles to an asymptotic level, while load and frequency remain flat. However, on closer inspection, the power scales are quite different. The first experiment levels off at around 100mA while the second experiment settles at around 200mA. a) First SKIA counters profile b) Second SKIA counters profile Figure 2 Profiling experiments in SKIA mode

3 Looking deeper at the two profiles reveals more: during the first experiment, only three CPU cores are being utilised, whereas in the second experiment all four are busy. This is not a characteristic of the app, but something to do with the Android system. The situation is made clear from the instantaneous view to the right hand side of the profiling tool screen shown in figure 3. a) Four cores utilised c) Full view of the LPGPU2 Profiling Tool b) Only three CPU cores utilised Figure 3 CPU core load graphs and selection boxes in context with the main tool Analysis: Loop-Blinn The Loop-Blinn algorithm by Charles Loop and Jim Blinn is a combination of splitting the font into a set of triangles covering each font glyph. The vertices of those triangles coincide with the edges of the glyph and a fragment shader algorithm renders the actual curves. Because of this, the font can be rendered directly on the GPU without recourse to blitting textures prepared on the CPU. Figure 4 shows a baseline profile of an implementation of Loop-Blinn in the LPGPU2 Font Renderer app. Figure 4 Font rendering with Loop-Blinn.

4 The profile shows similar characteristics to the SKIA app an initial burst of activity evidenced by high CPU core frequency and load, power consumption and cluster temperatures followed by a drop in the frequencies and related counters. The green coloured vertical bars near the top of the profile are individual clickable frames. These are available because capturing API call traces was selected for this experiment. When traces are available, the Feedback Engine has much more to work with. To keep the LPGPU2 Profiling Tool as intuitive as possible, only feedback options which make sense are offered to the user. Two different feedback dialogs are shown in Figure 5. Their configuration depends on the available data. a) Feedback Engine dialog when API traces are not available b) Feedback Engine dialog when API traces are available Figure 5 Different Feedback Engine Dialogs (with sensible defaults)

5 As with SKIA, a number of experiments were performed in Loop-Blinn mode and Figure 6 shows two of these. a) Loop-Blinn experiment 1 b) Loop-Blinn experiment 2 Figure 6 Loop-Blinn font rendering profiling experiments Because feedback is available, the Feedback Engine was run. This resulted in a number of regions being identified. Figure 7 shows the Profiling Tool after the Feedback Engine has been run. The individual frames are still visible and clickable but now a number of bright green sections are present in the display, and these correspond to the regions identified by the Feedback Engine. The timeline at the top of the GUI can be zoomed to an area that has too much detail to visualise otherwise. Figure 7 Regions generated by the Feedback Engine

6 Frames and Regions are clickable to display a finer level of relevant detail. Clicking on a region creates a new tab for that region of interest. Clicking on a frame also creates a new tab for that frame. Figure 8 shows a regions sub-tab. Figure 8 A region sub-tab for Region Of Interest (ROI) number 8 The timeline now displays the timeline for that region. A list box shows the longest running calls, and a pie chart shows the type of calls in the frame. The region shown involves mainly draw calls, as we would expect for this kind of application. Another list box shows annotations high level analysis statements to highlight issues with the app, globally, per region, or even for individual frames. In this view, the timeline is fixed to the region bounds, and the frames along the timeline are all the frames in this region. It is possible to drill down in to those by clicking on them. As with regions, each time a frame is clicked, a new sub-tab is opened under the Frame Details tab. Figure 9 shows a frame data from a Loop-Blinn run. At this level of detail, the timeline displays individual calls. All API calls from this frame are shown on the left of the screen and approximate counter values are listed on the right. The reason they are approximate is that the counter sampling frequency will not, in general, line up with the frame rate which may itself be sporadic. Because of this, counter values must be interpolated between samples. The start and end times of each API call are available and also, for convenience, is the duration of each call. Finally, a button at the bottom of the screen helps the user to navigate back to the Region of Interest this frame comes from.

7 Figure 9 A typical frame from Loop-Blinn mode in the LPGPU2 Font Renderer app Analysis: Stencil and Cover The Stencil and Cover mode is a contrived method using Loop-Blinn to render into the stencil buffer and then using two large triangles to draw through the stencil to frame buffer, revealing the text. In practice, it has a very low framerate and cannot be used to inform the other methods, and will not at this stage be investigated further. Figure 10 shows a profile from Stencil and Cover mode. Figure 10 Profile collected from Stencil and Cover mode experiment

8 Further Analysis: Performance Rendering is a compute intensive task, but when an application also has to marshal every single API call, return value and parameters, and transmit that data over the network, a significant processing burden is added to each frame. If an application is particularly intensive, it might not even be possible to run with all profiling options turned on or even at all. To expose the performance characteristics of each rendering mode, we need to have them working as hard as possible, and that means we need as little overhead as possible in the API shim. To achieve this, we make use of the fact that the LPGPU2 Profiling Tool can capture some data with no app running at all. This is possible because counter data are aspects of the device and not of the app. The data we seek for this analysis are: Power Consumption, CPU Load and Frequency, Processor Temperatures, etc. By using this profiling method, it was possible to drive the apps very hard indeed, as the shim was effectively passing calls straight through to the underlying API with no overhead. Figure 11 shows data collected in SKIA and Loop-Blinn modes via this method for two runs. The number of iterations (i.e. the number of strings rendered) was raised to the maximum: 8000 strings per frame without ill effects. a) SKIA run 1 b) SKIA run 2 c) Loop-Blinn run 1 d) Loop-Blinn run 2 Figure 11 SKIA and Loop-Blinn nodes collecting device counters only where the app is not connected to the LPGPU2 Profiling Tool

9 In all runs, 8000 iterations were used for both font rendering methods. The flat temperature section in each profile is the period during which the app was running in work mode. In all four runs, the two CPU clusters ran at slightly different temperatures, and for each of the two methods the GPU temperature tracked one of the clusters. The surprising thing is that we might have expected the Loop-Blinn method GPU temperature to track the higher value of the two clusters and the SKIA GPU temperature to track the lower cluster temperature, because Loop-Blinn is font rendering on the GPU whereas SKIA is font rendering on the CPU. Although it should also be noted that the temperature difference was small ~ 1 o C. The power consumed was very similar between methods. The Feedback Engine reported that NON GL work was the main cause for the length of the frame in both modes, so for more information we may need to revisit the code to analyse the cause. Conclusion The LPGPU2 Profiling Tool provided detailed counter data in both operation modes of interest: SKIA and Loop-Blinn. SKIA mode renders text on the CPU and Loop-Blinn renders text using the GPU. From the numerous experiments conducted, there was no significant difference between the two, as results from different runs of the same mode varied at least as much as the difference between the modes themselves. However, the LPGPU2 Feedback Engine identified that the main cause of the length of frames was NON GL work. This means that time was being consumed outside of the API calls an area not analysable by the engine. This tells us that a more detailed review of the code may reveal the cause of the extra processing time that currently unaccounted for in the API.