Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
103 user(s) are online (52 user(s) are browsing Forums)

Members: 0
Guests: 103

more...

Headlines

 
  Register To Post  

« 1 (2) 3 4 5 ... 10 »
Re: Porting apitrace
Home away from home
Home away from home


See User information
@Capehill
Quote:

So at least we can do now some basic debugging when needed.


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).

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@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 ?



Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@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:

static void my_glVertexAttribPointer(struct OGLES2IFace *Self,GLuint indexGLint sizeGLenum typeGLboolean normalizedGLsizei stride, const GLvoid pointer)
{
    
IExec->DebugPrintF("VA %d size=%d, type=%s, norm=%d, stride=%d, pointer=%p\\n"indexsizetypenormalizedstridepointer);
    if (
old_glVertexAttribPointer) {
        
old_glVertexAttribPointer(Selfindexsizetypenormalizedstridepointer);
    }
}


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.


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@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


Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@kas1e

Quote:
@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.

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


http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@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)


Edited by kas1e on 2019/4/6 21:55:36
Edited by kas1e on 2019/4/6 22:05:18
Edited by kas1e on 2019/4/6 22:12:16
Edited by kas1e on 2019/4/6 22:13:47
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: Porting apitrace
Supreme Council
Supreme Council


See User information
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

Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such.
----
http://codebench.co.uk
Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@Capehill
Quote:

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


Done, thanks!

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@kas1e

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

Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@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 :)

Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@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:

ifneq ($(shell uname), AmigaOS)
    
CC             ppc-amigaos-gcc
    DELETE        
rm -f
else
    
CC             gcc
    DELETE        
delete
endif

OBJS main.o ogles2_module.o warp3dnova_module.o logger.o
CFLAGS 
= -Wall -O3 -gstabs

%.: %.c makefile
    
$(CC) -$@ -$< $(CFLAGS)

glsnoop: $(OBJSmakefile
    
$(CC) -$@ $(OBJS)

clean:
    $(
DELETE) $(OBJS)


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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: Porting apitrace
Home away from home
Home away from home


See User information
@Capehill
Quote:

1) Please create a pull request of your changes, it's more convenient for me to merge it.


Ok

Quote:

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.


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:

2) Try without quotes.


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

Quote:

By the way, how do you signal the process if you run in on background?


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:

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.


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

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Porting apitrace
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:

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


Try:

"NO NAME:/d/glsnoop" OGLES2 &

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.


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

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


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

Go to top

  Register To Post
« 1 (2) 3 4 5 ... 10 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project