With real serial all still will be slow even for little portions, so Sashimi save a lot with it. When you redirect it to ram then all really fast.
I.e. i run glsnoop with GUI key, press "pause" rigth away, then run sashimi >ram:debug.txt, then run game, go till problematic moment, press "trace" in glsnoop's gui, do something, press "pause", and in log have all stuff happens only on need it place.
I think paused-logging is not buffered right ? I mean, when i press "pause" no output collected somewhere in the memory's buffer so when i press "Trace" , it didn't throw at me what was done before, but only start all new , right ? Just to clarify, as when it throw walls of logs at you, you can't be sure :) But seems that all fine and when you press "pause" all skipped till you press "trace".
The only thing which probably need it for that little gui wndow, its resizable gadget, so anyone can set size of that gui as big as he want, with buttons resized as well. And by default that window imho can be a little bit bigger , so word "glsnoop" in the window's title will be fit in all the themes, not only default aos4 one. For me by default with SilverGreen theme it looks like this now:
Also found some bug probabaly: sometihng wrong with adding of OGLES2_glShaderSource(), at least i think it is. As i tried to run one game (fricking shark), and it just crashes now on that function (but crash skippable):
Logging is not buffered, so when you pause, logs are simply ignored.
Rigth, as it should be then :)
Quote:
Thanks for the crash report. It's hopefully fixed now. It seems to be OK to pass a NULL pointer for "length" param.
Crash fixed, and gui window looks fine too, banana !
And i can see in the log now how shaders dumps too, that quite cool ! We need filters now probabaly, so we can for example only choice from the list to patch only "glShaderSource", and have in log only shaders in use which ogles2 transfer to warp3d.
What is also good with shashimi and ">" thing, is that you can open it in realtime and see last writing. I.e. you start sashimi, glsnoop, doing things via trace/pause , and can in some dopus window check the log in realtime.
Another little moment which of course make no big harm, but you may want to change : when we run glsnoop we have: "system patched. Press control-C to quit..." in console, but then when we exit from (via ctrl-c, or via close gadget if gui mode used), then we don't have words like "System dispatched, glsnoop exit", it just silencly exit and only wrote to serial about glsnoop being terminated.
Probabaly adding that on exit to usuall console same as when we run it will be good.
PS. what you think, do we need to create ticket for adding minigl and old warp3d support too, so, ppls can trace and minigl/warp3d apps as well ? If i understand things right, patching of minigl/warp3d will be the same as warp3dnova's one ?
We anyway still use minigl things there and there, can be helpfull (for example to detect why we have crash in Jedy game, which we have with all newer minigl versions since 2.20).
When we run glsnoop in gui mode, then press "pause", and then close it, then in the log we have only "tracing paused", and nothing else, which mean that probably it didn't removed/dispatched when we exit from pause mode.
I don't object adding MiniGL and Warp3D classic, but logging them is already possible, without system patching, by just building a debug version of MiniGL. glSnoop would add pause/resume feature of course.
Writing those log wrappers is super-boring so probably would need to create a Python script that creates all those functions based on the interface data.
Quote:
When we run glsnoop in gui mode, then press "pause", and then close it, then in the log we have only "tracing paused", and nothing else, which mean that probably it didn't removed/dispatched when we exit from pause mode.
Hmm. I think only prints were omitted but can check.
Patching business is somewhat undefined currently. Depending on which is quit first, the traced application or glSnoop, something strange might happen.
Quote:
we don't have words like "System dispatched, glsnoop exit", it just silencly exit and only wrote to serial about glsnoop being terminated.
Totally reasonable request, I will see what can be done.
Totally reasonable request, I will see what can be done.
I see you already do so, thanks !
Quote:
Hmm. I think only prints were omitted but can check.
Seems also fine now, through when in GUI mode i exit when "pause" pressed, in log i have also words that tracing resumed before restoring of patches and exit happens, but that probably not big deal.
Quote:
Patching business is somewhat undefined currently. Depending on which is quit first, the traced application or glSnoop, something strange might happen.
Oh, that can explain some strange crashes when i have few times when close glsnoop while game still in runing. I was in hope that those crash happens because of that missing dispatching when close glsnoop from gui mode when pause pressed, but as you say its other problem.
I retested now, and it seems that if i run glsnoop, then run some game, and while game runnig i quit from glsnoop, it seems patches interface still there, and game continue to works like it works over glsnoop (i can see new logs coming to serial). But when i quit glsnoop it of course says that patches removed and glsnoop terminated. Then in end , after a while, it just freeze OS or crashes.
Maybe there is no way to remove patches while app already runing with patched interface ? And there should be something like "sorry you can't interrupt glsnoop while tracing app" ?
Edited by kas1e on 2019/4/15 22:07:57 Edited by kas1e on 2019/4/15 22:10:31
1) multiple glSnoop instances are blocked by a named message port 2) when glSnoop is quit first, it attempts to remove known patches, then it waits for a moment before freeing context memory and quitting. This *hopefully* makes sure that applications don't get surprises. 3) support for multiple applications (5 now)
1) multiple glSnoop instances are blocked by a named message port
That one works for sure
Quote:
2) when glSnoop is quit first, it attempts to remove known patches, then it waits for a moment before freeing context memory and quitting. This *hopefully* makes sure that applications don't get surprises.
Tested about 10 times it , in all different conditions, with gui, without, with just ogles2, with just w3dnova, with both, tried to pause/resume it : and after that exit while game is running, and all seems fine.
I.e. logging stops when need it, FPS in game back to normal (mean that patches removes fine), and exit from game also happens after that fine.
So this one for sure Banana !
Quote:
3) support for multiple applications (5 now)
Yes, i can run for sure few different ogles2 apps at one time, and loggin of them works, but at it writes to the the same log, and with the same "Shell Process:" you can't know from what and what come.
In general support of more than one GL app being running at the same time sounds interesting, but usually when you want to debug something, you debug one app / one problem, not that you debug 2 apps running at the same time which send debug information to the same log.
But i can miss the point there :) Like some GL plugins for GL app used at one time or something of that sort ..
Probably what is need it to deal with now, its that "shell process" in the log , so to get name of binary which is running for debug, and filters. And nothing else probabaly need it.
Btw, one little moment i notice: when we patch ogles2's ShaderSource, the output looks like this:
So there is "Line 0: ' .... '" thing. But can be there be any other "lines", as shader is just one single piece ? I mean is there needs for that "Line 0" then ?
I agree that it is difficult to debug multiple OpenGL apps at the same time. However, maybe there are some screen savers or some accidentally started GL apps: this way glSnoop is a little bit safer.
Regarding glShaderSource: it is possible to pass multiple lines. There is count parameter.
The latest glSnoop should be able to show application name properly.
The latest glSnoop should be able to show application name properly.
Yeah, it is ! I run even 2 gl games, and have in log for both of them their names, like:
Shell Process 'Friking_Shark': blablalb Shell PRocess 'LettersFall': blablab
Through, when i run those 2 games, then exit one of them, then another one, and then CTRL+C for glsnoop, then glsnoop is crashed with such stack trace:
Crash log for task "glsnoop"
Generated by GrimReaper 53.19
Crash occured in module glsnoop at address 0x7FADCE14
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
Tested latest version and now all warnings gone and filters added , banana of course !
Did i understand right, that filters for NOVA is not working at moment ? At least when i tried to comment out everything, for ogles2 , but keep only one function: all works for ogles2 filtering. But when i tried to comment out everything for NOVA, but only keep W3DN_Destroy, it still output for me patched W3DN_DestroyVertexBufferObject().
Also, it seems that glShaderSource() patching not works as should : big enough shaders do not fits to the logs, and just ends on some random place. See what i have in log now:
See, it just ends randomly, like, buffer is too small and static (like 1024 or something) and not dinamic-calculated ?
It is also show length 0x0 all the time for all shaders, dunno if it correct as well ?
@Hans
What function of Warp3dNova is analogue of glShaderSource() ? Is it GetShaderDataBuffer() ?
Why i ask, because we often not only need to get shaders which "in" to ogles2, but we also need code of shaders which "in" to warp3dnova (be it after ogles2 conversion, or when we use pure warp3dnova progs).
What function of Warp3dNova is analogue of glShaderSource() ? Is it GetShaderDataBuffer() ?
Why i ask, because we often not only need to get shaders which "in" to ogles2, but we also need code of shaders which "in" to warp3dnova (be it after ogles2 conversion, or when we use pure warp3dnova progs).
Sounds like you're confused as to what glShaderSource() does. It's used to pass shader code TO OpenGL, NOT to get it.
Or do you mean glGetShaderSource()? If you mean glGetShaderSource(), then there is no equivalent. Warp3D Nova does NOT store a copy of the SPIR-V shader code because that would be a pointless waste of memory.
If you want to capture a copy of the SPIR-V source, then do so in your patched CompileShader() function.
Sounds like you're confused as to what glShaderSource() does. It's used to pass shader code TO OpenGL, NOT to get it.
It probabaluy have no difference with shader itself ? I mean, be it TO , and NOT to get, or to get, and not to : it make no differences as shader didn't changes.
The point there is that we have now shader with which ogles2 operates (so gl4es send it, ogles2 take it). Now we need what is ogles2 output to the nova, and what nova get from ogles2 , i.e. how shader start to looks like after, and in his last tranformation.
With that info, i may start to think more about why fricking shark shaders didn't work at all visually while compiles well.
Changed matcher function to use strcmp instead of strstr.
Increased line buffer to 16 K. It's allocated on stack for speed and simplicity. Not sure what is the best to way to handle it. Now it sets an implicit requirement for application to have enough stack.
Quote:
It is also show length 0x0 all the time for all shaders, dunno if it correct as well ?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
