Porting apitrace

@Capehill
Quote:

Yeah, probabaly i can try now to think how to catch bug in FrickingShark without needs of debug version of ogles2.library.

Btw, i also notice, that with current (interface patching) way, the patches installed when you run programm, but removes only when you send ctrl+c to the glsnoop itself, not when app is exit. Maybe that need to be catched too (so, to have clear installing/removing of patches when need it).

@kas1e

If also DropInterface was patched, then it would be possible to remove GL patches when patched interface is dropped by application. Kind of symmetrical behaviour.

But there might be still some strange logs if multiple GL programs were running at the same time. The logger part could print Task name of course.

@Capehill
We at least can debug already when one programm running.

Now to have it practical use, maybe you can help a little with issue we have in fricking shark ?:) That can be good test case for real work.

I.e. issue is : in fricking shark, when we press "f4" to showup something on screen, and then die or pass the level, we have some crash (skippable one) with pointing out on some 0xffffffff address (end of memory).

Now, from gl4es side, we prinfs what we send to ogles2.library from glVertexAttribPointer() and glBindBuffer() and all looks correct.

So we need to prinfs the same values now from ogles2.library side.

But, if i will patch now those function in ogles2 and prinfs all the values, then i probabaly will have the same what send gl4es, i.e. "in" values. But is it possible to catch values which ogles2.library send to warp3dnova ? Or for that , we need to find way how to patch warp3dnova's functions too and only then we can find "out" values which ogles2.library send to warp3dnova ?

@kas1e

I think also glBuffer(Sub)Data is needed so that VBO content can be seen. And glDraw*

If you already debug GL4ES "out" values then OGLES2 "in" values probably don't help much, other than cross-checking the logging.

So it probably needs also W3DN logging to provide a complete picture. Need to locate relevant W3DN buffer and draw functions.

@Capehill
ptitSeb says it should be enough to printf glVertexAttribPointer + glBindBuffer() (probabaly it just the same as to glBuffer(Sub)Data, just once it bind).

I just tried to patch first one, and it crashes by some reassons on that prinfs:



Did you see anything wrong there ?

EDIT: ah, its glenum type %s probabaly :) I just copied line about print from gl4es relevant part, where it seems in structure so was %s


For W3DN dunno if your patching way will works : i can patch CreateContext, but then how to patch relevant functions ?

@Hans
Can you give us a hint, to whhich functions of warp3dnova need to patch / printf values, to see relevant to glVertexAttribPointer() / glBindBuffer() values so to see when that 0xffffffff is starting to come up.

@kas1e

Hmm. But we need also BufferData to see the data passed and also the draw call to see how many elements will be drawn? Or?

Type should be %d instead of %s.

I could start a github project, even if this is a proof of concept project so far, it's easier to collaborate via version control.

EDIT: https://github.com/capehill/glsnoop

@Capehill
Yeah, github project 100% must. Bit by bit and there will be some debugging tool. Even if not apitrace at begining, having good trace one will be really helpfull.

@kas1e

Quote:
Here's a list of all vertex related functions:
CreateVertexBuffer()
DestroyVertexBuffer()
VBOSetArray()
VBOGetArray()
VBOGetAttr()
VBOLock()/BufferUnlock()
BindVertexAttribArray()

@Capehill
Your patching of GetInterface() function is an easier method than what I was suggesting.

I meant creating a fake library, so that when GetInterface() is called, it calls the actual ogles2.library and then reads the returned interface pointer. Since the OS allows you to patch GetInterface() then you might as well go with that.

Hans

@Capehill
Tested commit #13, it works :)

Have notice some moments currently :

1). If you run something from shell, then in return for "task_name" you always have "shell process", through in my case it was "gamedata" binary.

2). What you think, maybe there needs to split somehow w3d and ogles patches in the log when we use them both at one time ? I mean, for now it like this:


Shell Process: my_glDrawArrays: mode 6, first 0, count 4
Shell Process: my_BufferUnlock: bufferLock 0x5f73c7c8, writeOffset 0, writeSize 64
Shell Process: my_CreateVertexBufferObject: errCode 0x62558d00, size 192, usage 6, maxArrays 16, tags 0x62558cf8
Shell Process: my_VBOSetArray: buffer 0x6078c118, arrayIdx 0, elementType 6, normalized 0, numElements 4, stride 48, offset 0, count 4
Shell Process: my_BindVertexAttribArray: renderState 0x6f90a358, attribNum 0, buffer 0x6078c118, arrayIdx 0
Shell Process: my_VBOSetArray: buffer 0x6078c118, arrayIdx 1, elementType 6, normalized 0, numElements 4, stride 0, offset 16, count 4
Shell Process: my_BindVertexAttribArray: renderState 0x6f90a358, attribNum 1, buffer 0x6078c118, arrayIdx 1
Shell Process: my_VBOSetArray: buffer 0x6078c118, arrayIdx 2, elementType 6, normalized 0, numElements 4, stride 48, offset 32, count 4

So there is unknown what is "in" for ogles2 , and what is "in" for w3d. Maybe some note at begining, like "ogl:" and "w3dn:" so we will know what and from where.

Or its better to keep it as it ?

3). Its really cool shit.

4). Also we maybe need some way to say what function we want to patch ? I mean, something like "templates" , where we write list of function of module we need, which ones will be printed (so to short the logs to minimum and to print only necesary info, depend on what kind of trace we need).

They can be just some directory called "templates", in which we have something like 2 directories "ogles2" and "w3dn" , and in which something like "all.txt" , "drawing.txt" , "shaders_only.txt" and so on. Not like that exactly of course, but something of that sort to have more control on debug output without needs to touch source code itself, but just to use templates.

5). Another idea is to have some key-kombo, which will pause actual printing. For example, you have some bug in some game, which to show up need to start game, play in it, etc ,etc. And will be cool to let's say run it all, "pause" output, the go to the menu, start game, play in it, meet and before meeting with bug "unpause" printing.

But just as some idea which of course not really necessary.

EDIT: let's discuss fricking shark issue in gl4es thread if you doens't mind ? (to keep ApiTrace porting more on topic)

@kas1e

1) Yes, that's all Task node has when started from Shell.

2) I have removed silly "my" prefix and use "W3DN" and "OGLES2" now.

3) Yeah

4) Yes, filters are needed to keep logs smaller and debugging faster. By the way, added already support for command-line options. You can choose NOVA or OGLES2 (by default both).

5) Needs a GUI, or a window at least.

So please create tickets for 1, 4 and 5. I have no idea when they could be implemented but PRs are welcome.

Just a quick reminder on your debug output:

Because RawDoFormat() defaults to int16, you should always use %ld rather than %d when dumping values via DebugPrintF() otherwise the expected results could be wrong (rounded down to 16 bit).

Simon

@Capehill
Quote:

Done, thanks!

@kas1e

The latest version supports logging to a file. However, the 10-megabyte memory buffer fills up very quickly.

@Capehill
Yeah loggin to a file are good. Before to speed things up i just use Sashimi with redirect to the >ram:debug.txt , and it create 25-30 megabytes of log pretty quick too. Of course perfomance of the GL app in testing reduced quite well, but at least it usable for sure for real-tests in compare with serial output, which even on 115200 slow things down that much that you can't do anything :)

Are you restricted loggin to a file by 10mb limit ? Imho it should have no limits, just fill it as much as it can till programm which is being debug not exit.

@kas1e

Yes, there is this limitation in source code (easy to modify of course). To write a logfile dynamically from multiple process contexts, there has to be a better solution.

The problem is that glsnoop opens the log file. Now, if I understand correctly, random process cannot just write this file using the same handle, but it should either have its own file handle or delegate writes to glsnoop. So, logs are just collected in a mutex-guarded memory buffer and flushed at the end. Not very cool, but until a better solution :)

@Capehill
From another side, we already write to the serial from multiple process context with no probs :) Sashimi also redirect it all to a file by simple "Run sashimi >ram:debug.txt" dinamicaly.

@Capehill
I modified makefile a bit, so it will be able to build glsnoop and on amigaos native and on crosscompilers too. Also replaced -ggdb with -gstabs, as only -gstabs should be used, only that one works all the time with all the things, -g, -ggdb and anything which id not -gstabs, sometime just fail. Its not just me, its Thomas Frieden (author of all that stuff) says sometime ago that only -gstabs should be used. And i find out that yes, sometime (like with addr2line), things like -ggdb or -g not works, while -gstabs works.

There is new makefile:



Also found little issue : can't run it like

ram: "glsnoop OGLES2" &

(handy to run in the same window, and then later send ctrl+c via another app).

It then fail with words "glsnoop OGLES2: unknown command". Pure "glsnoop" runs fine.

That probabaly because of ReadArg usage ? At least as i remember if use pure main()'s argvs, that kind of error didn't happens.

@kas1e

1) Please create a pull request of your changes, it's more convenient for me to merge it. By the way: I wonder what the problem with -g or -ggdb might be? I have never used -gstabs personally. Is there a public reference? I guess not, since the Friedens don't write on forums these days.

2) Try without quotes. By the way, how do you signal the process if you run in on background?

EDIT: regarding serial port redirection to file - I didn't know Sashimi has file redirection. If that is as fast as the current glSnoop implementation, and if it doesn't have other limitations, I guess glSnoop file writer can be removed to avoid redundancy.

@Capehill
Quote:

Ok

Quote:

I do not remember when and where Thomas said it, maybe in beta-list, but what is for sure, that for some C++ progs, when you use anything but not -gstabs, then you will fail to have relevant string numbers in stack trace. I can't remember at moment exact situation, but i just remember the rule like "use -gstabs all the time". I can try to search when and where Thomas say it..

Quote:

Without quotes something like "NO NAME:d/glsnoop OGLES2" will not works :)

Quote:

I run Ranger in background in the DOS/Process tab, and when i need, i choice glsnoop , choice "dos signals" tab, and there i can choice what one to send and press "signal" to send it. Tnere is also other ways i remember, like sending "break" from shell to process , and co.

Quote:

Its not that it has any special code, is just ">" thing do all the job, sashimi only redirect serial output to console, so ">" thing do it as usuall to a file

@kas1e

Quote:

Try:

"NO NAME:/d/glsnoop" OGLES2 &

Quote:

Cool. I find it easier to run glsnoop in a shell tab and just CONTROL-C it :)

Quote:

Of course. I feel now dumb adding the file logger earlier. Good intentions and all that.