https://docs.microsoft.com/archive/blogs/kaimio/feed.xml Thoughts on Windows Phone, graphics & performance Wed, 17 Apr 2019 03:40:24 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/kaimio/how-to-use-gpuview-with-windows-phone Wed, 03 Feb 2016 18:02:11 GMT https://blogs.msdn.microsoft.com/kaimio/?p=61 Getting Your Phone Ready If you don't yet have FieldMedic in your phone, install it from Windows Store, or by clicking this link. I have created a simple custom profile for FieldMedic that gathers trace data from the most important ETW providers needed by GPUview. Download it from here. After that, connect your phone to your PC's USB port, open Windows Explorer and copy the downloaded FieldMedic-GPUview.wprp file to phone's Documents\FieldMedic\CustomProfiles directory (you might need to create the directory first)

Recording a trace

Now open the FieldMedic application in your phone. Go to "Advanced" page and tap the first field to select which ETW providers to use. Deselect everything else except the FieldMedic-GPUview profile you just copied to the phone (it should be at the bottom of the list). After that tap "back" to get to FieldMedic front page and tap "Start logging". Initializing the logging session takes a while, and then you are ready to try out the scenario you want to investigate. Note that with the settings in the GPUview profile FieldMedic gathers a huge amount of data (often 10s of megabytes per second) so keep your tracing session as short as possible. Half a minute is OK and usually sufficient; ten minutes of data will fill your phone's storage and make even a high end PC feel slow when analyzing it. When you are finished go back to FieldMedic and tap "stop logging".

Analyzing a trace

You can find recorded traces in phone's Documents\FieldMedic\Reports directory. FieldMedic creates a subfolder for every logging session with recording date in its name. Inside the folder there are several files but we are interested only in the file named Custom-FieldMedic-gpuview.etl. Just copy that to your PC and open in GPUview (if you don't have GPUview installed yet, it is part of Windows Performance Toolkit which comes bundled with Windows 10 SDK) As an example, here is a trace I captured while playing Angry Birds with my Lumia 735: If you are not familiar with GPUview, the top line shows GPU activity (blue area). In this case it is rendering a new frame every 1/60 of second and is active for bit more than 50 % of time. This does not necessarily mean that the game uses half of GPU's capacity; more likely system has lowered GPU clock frequency to save power so that utilization stays at 50-60% level. You can find more information about each GPU work item by clicking the green boxes. Below GPU activity you see flip queue on yellow background, i.e. frames that are ready to be displayed. Note that there is a single frame drop (hole in the right side of the picture). We would need to dive closer to find reason for this (in this case it seems that CPU is kept at little bit too low frequency, which causes work for a frame to take bit over 16.7 ms, finally missing VSYNC) Below that there is a section for each process (green area) that shows both its GPU work queue(s) and CPU activity for each thread. As you can see Angry Birds does most of its processing in a single thread, with some additional threads. The CPU timeline is constructed from events recorded from Windows scheduler as well as sampling profiler data, so if we had symbols for the application we could see exactly what it is doing; even without symbols we can guess quite a lot from the individual events and operating system stack frames that can be decoded with some help from Microsoft's public symbol server.

Conclusions

One of the best things in GPUview and other tools in Windows Performance Toolkit (WPT) is that you do not need application source code or any other development environment to use them. You can record a trace on any device, or even ask your customer to record it and send to you for analysis. Thanks to FieldMedic this is now possible in phones as well. This particular example is not very interesting as the game is so simple from rendering point of view and runs smoothly (well, with the one glitch in right side of picture) Next time we'll have a look at some more complex and problematic cases. Meanwhile, this article is a good starting place for learning GPUview. The recorded ETL file can be opened also with other tools like WPA, which is the general purpose performance analysis tool in WPT. In fact, I have included some providers that cannot be visualized in GPUview but only in WPA, including CPU frequency and power saving information. Bruce Dawson's excellent blog on Windows performance analysis is a good place to start learning about WPA.]]> https://docs.microsoft.com/archive/blogs/kaimio/hot-games-cool-phones Thu, 17 Dec 2015 23:32:59 GMT https://blogs.msdn.microsoft.com/kaimio/?p=41 Setting the Scene Modern mobile phone chipsets (like Qualcomm’s Snapdragon 808 and 810 used in Lumia 950) are indeed very powerful and capable. However, great performance also means that they can consume a lot of electricity and eventually this power turns into heat. Unlike a PC, phones do not have fans or other active cooling systems so the only way to get this extra energy out is to let it conduct to environment via phone’s surface. The small size and fact that phones are usually held in hand (so that must not become too hot) sets very strict limits for amount of heat that can be transferred. In practice, we are talking about roughly 3-5 watts, depending on phone dimensions, surface material and environmental factors. The S810 has 8 CPU cores and a very powerful GPU. If all of these are used at full speed simultaneously the chipset alone produces more heat that a phone can dissipate, and you need to count in also heat produced by display, radios, camera, battery discharge (or charging) and other factors. All this available performance is great if your application needs processing in short bursts: the operations can be completed quickly, application feels responsive and the phone can cool afterwards. But games are played for minutes or even hours at once so the device power consumption must be somehow adapted to a sustainable level. When Windows operating system detects that the phone is getting too hot it takes several actions to force power consumption down. These include dimming display, switching some CPU cores off, forcing rest of CPU cores and GPU to lower clock frequency and lowering the battery charging current, among others. Unfortunately, many of these can be visible to user in a negative way and disturb gameplay. After all, the operating system does not know what is important for your game so it cannot do much else to save power than slow the whole system down. You as game developer can do much better job in both saving energy and especially using it for the things that matter by adapting game resource usage to a sustainable level. There are many best practices and techniques that can be applied to achieve this. The list below just introduces some of the most common ones; everyone of the items is worth a separate blog post and I hope to cover many of them in future.

Doing things efficiently

Optimization should not be considered only as a way to speed up an application that is too slow. It also reduces power consumption in an app that runs fast enough as operations complete in shorter time or can be run at lower clock frequency (which can mean lower voltage and less leakage current). All the normal optimization guidance applies here. Look for hot spots that consume lots of CPU cycles.  Consider writing performance critical parts of your game in native C++. Try to reduce the number of draw calls as GPU driver overhead can contribute a significant part of CPU load in a game. And so on. Systematic and frequent profiling is your friend here. Multithreading can decrease power consumption significantly. Usually it is more efficient to run two or more CPU cores at low frequency than one core at maximum speed. Also, modern mobile chipsets like the Snapdragon 810 have a mixture of CPU cores optimized for energy efficiency and speed; splitting heavy computation to many threads makes it possible to run it quickly using the efficient little cores. For tasks that can be heavily parallelized GPU might be even better solution for minimizing energy consumption. For example, we use it extensively in Lumia camera and imaging applications (many of these algorithms are available to others via Lumia Imaging SDK). Earlier mobile chipsets were limited to DirectX feature level 9.3 (i.e. vertex and pixel shaders) but the newest ones support same features as desktop GPUs including compute shaders.

Using resources sparingly for things that matter

Forget the PC way of thinking that HW performance stays constant. In mobile world you can do either very fast sprints or run for long time at constant but lower speed. But if you try to run at maximum speed for long time you will be in trouble. Games have had to cope always with computers with very different performance. The same strategies can be used to adjust resource usage in mobile to a sustainable level. Especially reducing frame rate or rendering resolution can be very effective; for example, Lumia 950 has screen resolution of 2560x1440 pixels and rendering at this resolution to a small phone screen is usually overkill for a game. In our experience 720p seems to be often a sweet spot for fast paced 60 fps games. The special challenge in mobile is to figure out what performance level is sustainable as this depends not only on the device model but also on environmental factors like temperature, network quality and whether the phone is being charged. My advice here is to do testing in many circumstances. And giving user easy options for changing rendering settings.

Conclusion

The latest generation of mobile phones is quite far from the idealized computer with simple and predictable performance characteristics that I studied while attending  university. We in both Microsoft phones and operating system teams have tried our best to simplify things for you, the app developer , and we will continue that work in future releases. Nevertheless, being a good citizen in this brave new mobile world requires your app to respect the realities of these small devices. I hope you gained some insight of the system level problematics and some ideas how to adapt application to work well in different devices and environments. In future posts I will dive deeper into these as well as into tools that help you understand how your app interacts with the system.]]>