Continuing the discussion about porting a tool like apitrace to AmigaOS to make debugging of OpenGL and Warp3D Nova easier from here.
@Capehill
Quote:
Regarding API tracing, I would contribute to such a project. I have no idea how portable these open source tools are, but I guess it would be possible to "patch" each OGLES2/Warp3D(Nova) call to capture data. Or how would you approach the issue?
The basics are pretty easy. For the ogles2.library you can use IExec->SetMethod() to patch the library calls. I'm not sure if it's patchable on a per-application basis; that probably depends on whether the ogles2.library provides each app with its own interface clone or not.
With Warp3D Nova it's a little different. The driver context has its own set of function pointers, so you can just replace them with your own.
@Hans So it should be 2 modules, one for ogles2.library and another one for warp3dnova (?)
As far as i can see, apitrace can be running with providing as arguments what api will be traced, so it can be and only ogles2, an only warp3dnova, and both at the same time.
And probabaly making "tracing" will be easy, harder will be replaying and viewing.
But even pure "tracing" for both libraries will be also nice to have, it will then dump the lists of ogles2/ w3d calls with their arguments / offsets , and even that info will help to see when and how many and what was called
So it should be 2 modules, one for ogles2.library and another one for warp3dnova (?)
Yes. 3 modules if you want to log the raw OpenGL calls for GL4ES, but lets not get ahead of ourselves. We need to get something working first.
Quote:
And probabaly making "tracing" will be easy, harder will be replaying and viewing.
Yes, the tracing will be easier than playback.
The documentation says that you can log calls on one machine/OS, and play it back on another. So as far as OpenGL is concerned, it would already be useful with just the call logging working.
Of course, having to copy logs to another machine for playback and analysis would suck, so we want the playback and GUI working too.
Quote:
But even pure "tracing" for both libraries will be also nice to have, it will then dump the lists of ogles2/ w3d calls with their arguments / offsets , and even that info will help to see when and how many and what was called
Yes, even just having the call logs would be useful.
I tried to patch some ogles2.library functions but even though SetMethod doesn't fail, I am not able to capture serial logs so I guess something went wrong. For comparison, patching IDOS->Delay worked (but crashed on exit).
But just in case, and maybe it will be of any help when there is working aos4 example: in dopus5 we do use SetMethod() when patching some librarie's functions (workbench, dos, icon, intuition, exec):
There we use PATCH macro (in wb.h, and its corssplatform, so check for amigaos4 ifdef) , which then used in that wb.c file (check whole wb.c , we there made patched functions, which also return control to originals in case of fail, etc) and on the line 2306 of wb.c we start to install patches. On line 2390 of wb.c, you can see general fucntion which actually do call SetMethod() for amigaos4, and SetFunction for mos,aros and aos3.
@Capehill Played a bit, and with uncommented DOS_Delay() indeed can see how DOS's Delay patching works, and on exit it didn't crash for me through (i use beta one, 54.65) , while OGLES2 ones didn't :(
I tried for sake of tests patch Warp3DNova, but then it as Hans says it seems can't be patched via SetMethod
I tried to patch some ogles2.library functions but even though SetMethod doesn't fail, I am not able to capture serial logs so I guess something went wrong. For comparison, patching IDOS->Delay worked (but crashed on exit).
Sounds like the ogles2.library provides each app with its own copy of the interface. The bsdsocket.library does that too. You can double-check with Daytona if that is indeed the case.
If that's true, then patching may need to be done from within the app/game you want to log. Either that, or you need to patch whatever function is used to create the new interface, so that you can then call SetMethod() on the new interface. Maybe you can patch the library's interface clone function.
Quote:
I tried for sake of tests patch Warp3DNova, but then it as Hans says it seems can't be patched via SetMethod
The Warp3D Nova context you get is NOT an AmigaOS 4 library interface, so SetMethod can't be used there. You need to directly replace the context's function pointers.
What you could do is patch W3D_CreateContext*() so that you can catch the context that's created, and then proceed to patch the function pointers.
If that's true, then patching may need to be done from within the app/game you want to log.
That imho no go.
Quote:
Either that, or you need to patch whatever function is used to create the new interface, so that you can then call SetMethod() on the new interface. Maybe you can patch the library's interface clone function.
Tried to patch ogles'2 Clone, and that also didn't work. I.e. it patches/restores fine, but no printfs coming from patch-fucntion to serail or to console when i run any ogles2 based programm.
Quote:
The Warp3D Nova context you get is NOT an AmigaOS 4 library interface, so SetMethod can't be used there. You need to directly replace the context's function pointers.
What you could do is patch W3D_CreateContext*() so that you can catch the context that's created, and then proceed to patch the function pointers.
That one patches fine with with the same Capehil's-kind code, at least i can patch W3DN_CreateContext, and when run any Warp3DNova example, i have printfs to serial from my patch function.
@Capehill It mean that your code are fine (as Dos_Delay works, and the same works for Warp3DNova's W3DN_CreateContext), but still it didn't with ogles2 even for pure Clone().
Tried also not only Clone(), but Obtain() and aglCreateContext2() : also didn't patches. I.e. patches, but when i run any gl4es app, it didn't print anything from patched functions.
Why is patching it from within the game a no-go? Surely you could just link the logger into the game?
With patching Clone()/Obtain(), you're probably patching a cloned copy of the interface, in which case it only affects that one. Somehow we need to patch the original version before it gets cloned.
Why is patching it from within the game a no-go? Surely you could just link the logger into the game?
That mean additional work always by modify source code which you may not have. Apitrace mean more easy usage, and im sure everyone agree that adding loger to the games code, can be replaced by printfs then or whatever. Kind of different in compare with apitrace.
Advantage of not touching games code clear : you can debug any app, not only one you have sources of.
Maybe Daniel can add some gate to ogles.library which will give ability to patch things without needs to touch source code of games. If of course there is no other way we didnt know
@Capehil Yeah, and no pure ogles2 tracing too (sure not that offten happens at moment, but still there is few games in pipeline which is pure ogles2).
All in all ogles2.library is a library, there should be something which we can patch and from which continue..
As Hans says, if we have no output from our patch-fucntion, it mean that interface cloned, but still original one is created anyway in the ogles2.library somehow, so all we need it to get this one, and from that patch the function like in the way with Warp3DNova for example ?
@Capehill,Hans I asked Daniel about, so hope he doest mind if i put info there about.
--- Daniel says he do nothing special for. The only thing is that ogles2's interface is private. Simply because it contains contextual data, naturally, which means that every process gets its own interface, which is probably the reason why we fail.
However, patching inside the respective prog should work.
Unless if we sure, that our ogles2 calls aren't done through function pointers we obtained via aglGetProcAddress (probabaly just like we do in SDL and GL4ES), if that the case, then we can patch the interface (almost) as much as we want and probably won't see any effect. ---
So, then i go easy route: i just take some pure SDL2/OGLES2 example, and put at begining of main() that patching code which patch just single glCompileShader() , and it works. When i run my test case (which do some rotate cube) i have on serial:
So from the programm itself patching via SetMethod surely works, and SDL2 didn't break anything there in terms of pointers, etc.
Now need to understand how to patch it in general way, so without needs to touch program's code.
Maybe patch the app in realtime ? I mean as apitrace runs as "apitrace trace --api [gl|egl|w3dn] /path/to/application [args...]" , it mean that we know what application to debug. Then, we can take the "main" section of the elf , and add at begining assembler code which will just execute our patched code, and at end of main, remove them. Sure a bit of hardcore, but just as first idea.
Edited by kas1e on 2019/4/5 21:33:59 Edited by kas1e on 2019/4/5 21:36:10
Patching might be doable by using special constructor functions than run before main(). But I'm not 100% sure, I remember having some issues earlier where constructors were not actually ran (who is supposed to execute those, anyway?) and this caused some uninitialized things.
More likely, the constructor functions didn't run in the order you expected. AFAIK, there are no guarantees given on the order that the constructor functions are run. If one constructor relies on another constructor function to have run first, then it may work some of the time, and then mysteriously fail when the compiler changes the execution order.
Another option might be to create a trace_opengles2.library that passes on the obtain interface call to the actual opengles2.library, and captures the interface pointer before returning it to the application.
Could you explain in more details your idea about trace_opengles2.library?
I did an experiment that patched GetInterface() call. Now if the tracer notices that OGLES2Base is passed, it will then patch its interface. Tracing seems to work.
1. Just running gl4es/sdl2 based game : all works. I have seens all the output from the patched functions on serial
2. Just running sdl2/ogles2 based game (no gl4es involved) : all works too
3. Just running "quad_mystery" (so pure amigaos/ogles2 code) : all works too.
Damn cool ! Probabaly that way to go.
And i have no errors/exceptions/etc (but probabaly you already deal with them after editing the post ?)
ps. what is interesting, is that output from the my_compiershader, always start from 256 and go up, what did it mean ?:)
ps2. thiking a bit more about apitrace (which is take application name as argument) : we probabaly don't need it then, as we just do more general patch ? Or there will need some adaptation, like if we provide a path to the name of the app we want to trace, then somehow to patch only that instance (but how to detect it then, and is it need it at all , maybe just leave it as general patching, because its not like we run many opengl apps at the same time when need debugging/tracing).
Yeah, before edit, there was a copy-paste bug where I tried to patch the wrong interface and that crashed. Those patch_ functions should be probably generated by a macro to avoid such silly issues.
I guess shaders are given numbers (glCreateShader) from 256 upwards, so that's why those numbers appear in glCompileShader input, too. Daniel knows.
Executable might be detected by FindTask() somehow ("who is calling this function") but I don't think it's super important at this phase.
So at least we can do now some basic debugging when needed.
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
