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 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.