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...
It matters because I need to understand what you're trying to achieve before I can give any advice.
CompileShader() is the function where shaders are passed to Warp3D Nova. However, remember that they are in SPIR-V format, and NOT the raw GLSL.
It matters because I need to understand what you're trying to achieve before I can give any advice.
I need shaders in all their trasformation till the very latest sended directly to nova.
So far we can get those ones which we send to Ogles2 , and so we need those ones which ogles2 output to warp3dnova after glslnag-internal conversion happens with all the tweaks and workarounds putted in.
So yeah, as it will be SPIR-V format, then it's CompileShader(), thanks !
Nova patches must be installed differently, that's why there is a separate macro for them.
I originally used strstr() for string matching (for convenience, but it turned out to be a bad idea). I changed the code to require an exact string match by using strcmp().
@Capehill I also asked Mason for some artwork, and he made glsnoop icon as well as drawer icon, so we can include them to the repo (if you doesn't mind of course).
@Capehill Tested latest commit48 of glsnoop, and found 2 issue (1 bug and one cosmetic issue):
bug:
Just run it as "glsnoop GUI" , and then run any gl4es app, it then crashes in warp3nova_dmodule at line 372, in W3DN_CreateFrameBuffer().
Ignore DSI help through, so it something easy should be (i hope).
cosmetic issue:
Also another error in GUI mode, is that counts of errors not realtime, i.e. you run something, exit, and error count show 0. Then you resize a little gui window, and only then error count refresh (to 9 in my case with prototype).
But gui window start to looks better anyway :) more informative.
ps. i am sure you consider it already, but don't forget about os4depot release :) glsnoop is matured enough for sure.
@Capehill Maybe you on release kernel, and not on debug one ? But will post full crashlog a bit later.
As for error code refreshing: sure it should refreshes when window active, but i was active and didnt refreshes, refreshes only when i resize window a little
Got it. OGLES2 seems to pass nullptr for "errcode" parameter. Can be worked around. This also means that OGLES2 is not interested in error code for some reason?
@Capehill commit49 fix crash on startup , thanks !:
Btw, as i see it not "OGLES2 seems to pass nullptr for "errcode" parameter. Can be worked around. This also means that OGLES2 is not interested in error code for some reason?" , but NOVA instead, so probabaly that question/bug report to Hans instead.
It's OGLES2 who passes the nullptr to Nova, so this must be checked in Nova module before trying to dereference the pointer. It's anyway legal to pass a nullptr to Nova in these cases.
@Capehill Tested latest versions, all works, and what is good profiling also works !
Through, what i note,is that if in gui mode it was paused/unpaused, then, on exit there is _NO_ profiling info (like pressing pause/trace break whole process of counting things).
For example for now i trying to understand why SuperTuxKart the same slow over gl4es as on minigl (i.e. no differences in most cases), and so, i run glsnoop in GUI mode, press "pause". Then, load game, start track, and then press "Trace", tracing a little for 5 seconds, and press "pause". Then exit from glsnoop, and in log didn't have profiling info, just usuall loggin.
But if i just run it in gui mode, and didn't press pause , and then just trace a little and exit, then profiling info is here.
@Capehill It can be and when app destroyed, and when glsnoop quit (if that make sense?)
But problem that after you hit pause, then profiling didnt saves. But if you didnt hit pause, then profiling saves even when you just quit from glsnoop without destroing application
@Capehill Another idea which maybe you find worth of adding : adding something like profiler-only flag to command line , so, while all the functions will be patches and counted as usuall, log will not be writen anything, but only final profiling information.
By this way, we will be able to avoid slow-downs in heavy games when we want only to know, where all the loading happens, and how much of and of which ones calls are used.
Because when i only need profiling, and even if i redirect loggin via sashimy to RAM:, it still slowdown the games pretty much (not _THAT_ much as if it was writen to serial of course, but still, it reduce fps pretty much, and for some big-slow games, its hard to profile it as you want it).
@Capehill Btw, in NOVA output i didn't see any call to nova's CompileShader(), while it for sure should be called, as OGLES2 one call glCompileShader() for sure.
For example that will be helpfull to see speed of executiong of the shaders when they passed to/from ogles2 , and how much time takes NOVA's CompileShader().
Probabaly simply adding CompileShader() to warp3dnova's filters list will not make it "just works" ?