Porting apitrace

@kas1e

Added "average call duration column (us)" and I'm now looking for final comments for 0.2 release - if you have time to test.

0.3 might have some OGLES2-only time stats, if I can find a reliable way to calculate that (subtract Nova times).

@Capehill
Tested latest, found some stuff in pausing of profiling.

I.e. that what i do:

1). run glsnoop as "glsnoop PROFILE GUI", then immediately press "finish".
2). run foobillard++, go to the place i don't like, press in glsnoop "start", doing things, and press "finish"

Now, i expect in the log just one profiling result as i didn't run any binary to check when press "finish", so it should be skipped imho, but there still was two profiling reports : and both for the foobillard ! Ok there can be 2 , first empty with nothing (as nothing was running), and second for foobillard++, but there was just 2 and both for foobillard++

First one probabaly should't be for anything and be empty (or even should't be recorded, as nothing was running).

Also, in that "2 times profile" report, i see in second one wrong FPS count at top of the ogles2 output, somethinge like frame/s 1500 which is unpossible, as in reality its about 50 (but in first profile output, which happens when foobillard wasn't running, it was right, 50fps or something).

Also i have a freeze when exit glsnoop and/or app when playing with profiling start/finish, but that one i need to recheck, as pretty possible just bad luck.

@kas1e

I was able to reproduce the FPS bug, it was due to sorting the items for display. It was supposed to happen only at the end of context but now, when results can be triggered multiple times, sorting messed up the exit results, if user pressed "Finish" and then quit the program _without_ restarting the profiling.

I'm now thinking about ghosting the "Finish" button instead of "Start". This way it's more logical for user to control the profiling - if he wants, it's still unnecessary to "start" or "finish" anything for basic results.

@Capehill
Tested latest commit (where you change start/finish buttons ghosting). Hope i not too early with tests :)

So, running it as just "glsnoop gui" , gui shows like tracing is working (trace ghosted , pause not) - all fine. Profiling shows like "finish ghosted, start can be pressed" - all fine (by logic it mean, that tracing starts by default, and profiling disabled by default and will be not in logs, until i press "start").

After running some gl test and exit, i found that in log profiling information from ogles2 still there. While visually, gui says it should't put any profiling in. And it only from ogles2 profiling in, nova ones are no, so maybe some forgotten code change ?


Next, i run test as "glsnoop GUI PROFILE" , and didn't press "start" in gui (so, by logic profiling didn't started at this point). Run GL test, exit, exit from gui (so start wasn't pressed), and in output have both profile results and from NOVA and from OGLES2, while should be none, as i even didn't press "start".

Probabaly if we will start profiling by default, just when we run glsnoop, "start" should be ghosted instead (as before). Or, if not, then profiling should't be running by default when run it with GUI keyword.

@kas1e

Calls and ticks are always counted when there is a context. At the moment, "Start" just clears the counters and "Finish" dumps them to serial. Maybe buttons should be renamed to "Clear counters" and "Dump counters".

It would be possible to change the GUI so that both buttons are ghosted until the first context appears into play. Then "Finish" might be enabled.

Quote:

How to reproduce missing Nova trace? Are you 100% sure that they are not somewhere above, before some other serial debug?

@Capehill
Quote:

No no !:) It will be too technical. We anyway want "stop/start" or "pause/resume" feature, so if call it clear counters, it will just make it hard to understand for anyone.

Quote:

Uhm.. I was thinking about that (from user side):

you run "glsnoop GUI PROFILE". Now, there is 2 buttons "start/finish" for profiling. Now, if "start" it ghosted, then it mean that profiling already work : that good, and you press "finish" for make profiling finish. Then in the log will be only one profiling results for nova and ogles from the begining of running gl app.

Then , if one want to profile only current place of the gl app, he then just run again "glsnoop gui profile", hit "finish" right away (so, no any profiling in logs should be), and when time is come to profile necesary place, then "Start" and finish when need it, and then in log will be only that, last profile.

In other words, the previous way was more logical for sure. As it now, it's a bit misleading, like if "start" is not ghosted, then nothing started (while it is).

If ghost all the buttons at begining, and then unghost "finish" when GL app start, then, to profile part one need, he still press "Finish", and then again start/finish to have profile need it place, and again in log will be 2 profile.

Imho in compare with as it now, and ghost the both buttons, better way was as at begining. At least, if it unpossible to skip "starting" profile, to have just one at need it place.

Previous way at least was understandable from begining , you run it, hit finish, then again start when need it and finish, and have 2 profiles, but at least second one is what you need.

Quote:

Will recheck it more.

@Capehill
Quote:

Can't reproduce at moment, so may be some false alarm or overlook..

Thinking more about those profile buttons, i come up with some other crazy thing (dunno how well it fits):

1. We back things as it was before (i.e. start by default, and "start" button ghosted).

2. Instead we put numbers of the counts of profile restarting to the buttons itself, i.e. it will be like this:

We run "glsnoop gui profile" , button "start profile #1" ghosted. Button "finish profile #1" can be pressed. Now, once you press "finish profile #1" button, first start button is unghosted, but called now "start profile #2" , and ghosted finish button called now "finish profile #2". And so on.

So by this way, there will be understanding that there is many profiling results.

But dunno how to deal with that issue that when you run glsnoop, and then hit "finish profile #1" (but at this moment didn't run any GL apps), we still have in log that first small profile when running GL app after that.

Maybe just ghost all the buttons until any gl app runs ? And only then allow pressing "finish" ?

@kas1e

Quote:

Will think about that. Initially there was only one button called "Reset" that a) printed counters, b) reinitialized them. What do you think about 1-button solution? We could sell to Apple.

Quote:

If you mean the final, end-of-context summary, I consider it a feature. It's also useful in a sense that there are error counters, in my opinion.

Quote:

This should be doable.

BTW there is a button help now.

@Capehill
Quote:

You mean bubble-help ? yeah, looks nice.

And now i understand it more as well.. "Tracing" there is real pause/trace. While "profiling" there can't be just "stop/pause" , but instead enabled , and then sended information to serial.

So with bubble-help it start to be better for sure.

Now, if you want to fullfit gui, we can add there simple menu, with just currently "About, Quit, Iconify" as initiall version, and later expand it if there will be needs. By this "GUI" version will feels "full". If of course, you think is worth of loosing your time :)

Also, i see now there is window title change the name depending on what is in use, and while when we use only "PROFILE" it correctly named "glsnoop profiling", but then, when we run it by default, it have and tracing and profiling enabled, while window name "glsnoop tracing".


Quote:

Hmm.. for example i run glsnoop in gui with "PROFILE". Now i press "Finish". So, no profiling happens, as no gl apps was runing, all fine. In debug buffer i have words that profiling counter finished, all fine.

Now i run foobillard++, and press at some point "start", and then "Finish". And quit from foobillard++ , and in log i have 2 new profiling stats. So :

Did i understand right, that first one, are my one which i "start/finish" , and second one (last one, which writen when i quite from foobillard++) are that "feature" ? Is that "last one" are profile of everything since start till end, while first profile, are the my one, which i need for certain place ?

It seems that last profile (that "feature/automatic" one) are not for whole app till start if i press finish/start button, as in case with foobillard then this latest profile which happens on exit, didn't have "errors" writen about foobillard. They only writens if i run glsnoop and didn't touch start/finish buttons.

Can you explain a bit more what final/automatic profile doing ? Maybe its not need it when we press even one time "finish" button. I mean, if we run GUI , and didn't press anything, then on exit profile will happens anyway (as we didn't press finish). But if we press finish button, then maybe disable latest profile as not need it one ?

@kas1e

Quote:

Please create a ticket, I am not going to add it for 0.2.

Quote:

There is only one set of counters. Therefore that final summary was from the last "start" to end-of-context. But I have now removed it.

By errors I meant those errors that might have happened after user finishes profiling. But it's not that important if the point is to profile 5 seconds some FPS drop.

@Capehill
Quote:

Done

Quote:

Thanks ! Now all looks clean !

I do test it and just pure running "glsnoop GUI PROFILE", so all automaticaly saves. And just when i do press "finish" and "start" only one time, or few times, or one time at begining, and then few times in places i need : all fine.

I also tried it together with tracing enabled too: pause tracing, start/finish profiling, restrart tracing, in few different conditions : all seems works as expected.

Fat thumb up for 0.2 !

As final nitpicking , maybe also part in the Readme about "pausing" need to be changed a little ,i.e. now it reads as it was before when we have only one button pause, but now we can pause and tracing, and profiling, just different buttons, and while pause in tracing mean real pause, in profiling by pause (finish) mean that we send profiling information to serial.

But man, you go pretty far with it for sure. Thanks a bunch !

@all
If anyone want to see how glSnoop looks like in action (with all that gui things, and tracing / profiling examples), there is some 5 minutes of HD video showing it all in action:

https://youtu.be/qBmI1u0i2qc

@kas1e

Thank you for video promotion!

There is now a release candidate available: https://github.com/capehill/glsnoop/releases/tag/v0.2-rc1

Nice, thank you

@Capehill

Tested the GUI and works ok, but found a minor issue in iconification
When you iconify it, there is no program icon but just a default one

@Capehill
Btw, thinking about warp3dnova bugs, i still have one not-reported in normal bugreport bug about non-working shaders which come with fricking-shark (i.e not those ones generated by gl4es internally, but those ones which come with the game itself, and which can be enabled in gui.cfg file of fricking shark)

So i thinking about your ticket about levels of debugging, and maybe one of levels can be related to shaders only ? Only shader based functions, etc + some more info which can help with. I just think there something wrong somewhere, as if i strip fricking shark's shaders to minimum, they still didnt works (while, on pandora and linux same build over gl4es work fine, and shaders works)

At moment all what glSnoop can do in that regards is to dump shaders in use, and show information about related functions, but what else can be done to help debugging shaders issues from glSnoop's side ?

@kas1e

In addition to usual status checking, not much I'm afraid :( Of course there is still functionality to add, like glUniform*.

Can you build a minimal example with problematic shader and use it to shade a single triangle?

@samo79

Ok, this should be fixed in RC2: https://github.com/capehill/glsnoop/releases

@Capehill
It seems that deafult "filters" file is missing from release

@kas1e

True, added to RC 3: https://github.com/capehill/glsnoop/releases/tag/v0.2-rc3