Hi,
I'm trying to profile a game with MGD 2.0.1 without success. So far my status is that I successfully managed to connect to target in the MGD GUI but no trace data is displayed.
Logcat is not displaying any information on the intercepted lib. I don't know what I am missing.
ligGLES_mgd.so and mgddaemon are inside /system/lib/egl and there's a symbolic link libGLES_mgd.so pointing to libGLES.so
I tried both with processlist.cfg and without it. egl.cfg contains "0 0 mali" (as per instructions on android 4.4 telling no need to do "0 0 mgd"
Host: Windows 7
Target: Note 4 910H Android 4.4.4 running an APK generated by Unity 4.6
Kind Regards,
Phil Lira.
Sorry I didn't get back to you yesterday. So I finally managed to get it working. It was indeed a problem with my firmware. The MGD is being able to intercep now although It's giving more overhead to my game than I expected.
I'll be playing with the tool and getting to know it better.
I really wanted to say a big thank you for all the effort you put into helping me with this.
Cheers,
Phil
The MGD is being able to intercep now although It's giving more overhead to my game than I expected.
Yeah, this is expected. The interceptor has to package and pipe a huge amount of data off the target (every API call, paramaters, data buffers, etc), so it's relatively invasive. In general I find most apps stay usable, even for touch screen events, so although the framerate does suffer quite badly it is still running at "interactive" levels of performance. The only modes which drop off from that are the one which are capturing framebuffer output for every drawcall - that requires us to flush the rendering pipeline, and take a screen shot - which is always going to be expensive.
In general if you can stick to "best practise" - using VBOs already in memory rather than client-side attribute arrays, etc - then you can minimize the amount of data the interceptor has to pipe off target every frame. This will also help your app performance in the general case (if MGD has to move data around, then that is data the driver would also have had to move around).
Hope you find the tool useful, and let us know if you have any feedback on the user experience or feature set.
Cheers,Pete
Sorry for taking this long to provide a feedback. I was out of the studio and came back this week.
Although I had a short time to play with it, it felt intuitive and I managed to spot right on some batching problems. The only thing I kind of missed (debugger wise) is the ability to set a breakpoint in a specific OGL call and the ability to see mipmaps (setting a color for each level). Something similiar to the shader map.
Somehow I was expecting MGD to provide me an option to also profile my app. (something in the line of Adreno Profiler that has light, mid and deep profiling options).
I'd be interested in a fast profiler tool that allows me to spot bottleneck issues really easy by allowing me to: replace all textures for ones of 4x4 pixels, disable specific OGL calls and force states (like disabling alpha blend), rendering to a smaller viewport, etc.
Do you have a profiler tool that supports that? If not, do you have a recommendation for me?
Hi Philira,
thank you for feedback. For profiling we have a different tool: DS-5 Streamline. It allows profiling CPU and GPU hardware counters, as well as software events from the Linux kernel and kernel drivers. You cannot do replacements with it yet, but it is something we are thinking about. At the moment setting up Streamline to work with Mali GPUs requires recompiling the Mali driver with the right options (see Using DS-5 Streamline with Mali on Google Nexus 10).
As a general note, rather than pushing for an experimental approach, like trying 4x4 textures, change states, render to smaller viewport, we usually prefer a more analytical approach. With MGD and Streamline we aim to let the tool show you what is going on in the system, and find the reason of the bottleneck, understanding why something is slowing it down. This allows focusing on the whole system, also taking into account energy efficiency rather than just FPS.
Still, I acknowledge that what you listed can be very useful features, and some of which are on our 2015 roadmap for Mali tools.
Thanks,
Lorenzo
Hi Lorenzo,
Thanks for taking the time to get back to this.
I agree with you about the analytical approach. However, most of the profilers I used didn't provide me enough GPU data to identify the bottleneck analytically, and I understand that due to the inherent difficulty to timestamp GPU work. What I usually end up doing is resorting to these overrides to get precise timing. For instance, If I had the ability to override a specific shader program to a (write gl_Position = mvp * v and gl_Fragment = white) I could know for sure how much time this was taking by taking the difference of times (if this was my bottleneck, of course). Of couse this could be implemented on the application side and we did some of these in the past but it would be even nicer to have a tool providing us that.
I'm really interested now in testing DS-5 and even more looking forward to attend your GDC talk on mobile optimization.