Porting apitrace

Have you tried to compile from RAM: ? Perhaps GCC got problems with some file systems ?

@thellier
Its not about gcc only, gcc there was as example. Its in whole i feel that sometime working with data are slower than should be. While when you do pure copy all fine.

And its NGFS here, the fastest filesystem from all amigaos4 ones, that should't be issue (but sure, i tried and with RAM: too, the same). And while it compile things, hdd almost didn't blinks. Like its only pure CPU, and CPU are 100%.

It's like maybe some kernel internal functions of copy from/to memory are slow. But then it didn't when i just copy files.

I meassure again just to be 100% sure, the speed of compilation, of the same project, with the same options for gcc, etc. And that what i have on some 2 years old notebook with icorei5 / 2.5ghz over win10 : 5 min 10 sec (so without any -jX , etc, just pure single threading). And on x5000 compiling the same project from ram: (so we have 2ghz cpu) we have compile it for over : 20 minutes.

I am sure something wrong there. It can't / should't be that different. I can try to build it later over Pegasos2, but gcc will be different (as i have some old one on peg2) so comparing will be no fair..


@Capehill
Tested latest commits of glsnoop: that pretty nice now indeed. Also you have added translation of warp3dnova values, that did help for sure. Logs now looks more readable and better to compare.

@kas1e

Yep, glSnoop is getting better...

By the way, did you try Tequila's PROFILE switch when testing that Zombie game?

@Capehill
Tested latest tequila with PROFILE, see another thread about profiles there, so we not deral apitrace-glsnoop one.

@Capehill
Tried today to profile only ogles2 with glSnoop, and seem to find a error : when i run it like :

glsnoop profile ogles2 starttime 10 duration 20

it then didn't works , same as if i provide "gui" (that is known to not works).

Should i create some BZ so it will be not forgotten about "making profile starttime/duration works with gui and with ogles or warp3dnova only" ?

@kas1e

It happens because start timer is triggered from Nova context creation. As a workaround you can disable most Nova functions using the filters file. Please create a ticket.

@thread

There is a special 0.4 preview version available, with improved tracing: https://github.com/capehill/glsnoop/releases/tag/v0.4-preview

@kas1e

Quote:

Seems that I was able to reproduce this kind of issue with Sashimi when debugging long shader strings. Luckily Sashimi source code is available and it seems to support 4096 chars at max so I have modified the logger accordingly.

Maybe Kdebug patches DebugPrintF but has even smaller buffer?

@Capehill

Just to let you know that in the last 2 days glSnoop help us with Daniel find out some nasty issue in gl4es. There some interesting (i hope:) ) story about:

Firstly I find out that something going wrong with the loading of textures in some of the games. For example, Night Of The Zombies takes about 50 seconds to startup, which is really were strange for me, but I thinking before "ok, no DMA, probably that it".

Now, some time ago I got access to another closed source game, which loads, even more, 1.5 minutes or something. That was unacceptable, I start to ask Hans firstly about what it can be at all. We discuss that it can't be DMA probably, as all should be fine in terms of uploading textures to GPU.

I then create small test cases to find out that it even no the uploading textures to GPU slow, but uploading of textures to VRAM either!

Then I bring all that info on Daniel, he starts digging with ogles2 debugging, and ask "what glSnoop says about?", oh yes! We have glSnoop! Damn, how can I forget that masterpiece!

So running GlSnoop at test case: LINK on output from glsnoop

And as you can see it show us that all time is spent inside of TexUpdateImage(), so glTexImage2D() then! Daniel starts to disable things, adding prints, and find out that it client's glTexImage2D() and not ogles2 or Nova for sure. So we first think it Irrlich, but no, it was gl4es and issues with the endian conversion of GL_UNSIGNED_INT_8_8_8_8_REV formats. So today ptitSeb fix it and thigs works as expected.

But, without glSnoop, how we could know that it glTexImage2D() in end. Maybe after a day of prints debugging :)

@kas1e

Good to hear! I have been occasionally using glSnoop to debug random things.

By the way, in your trace GL context destruction took 6 seconds. User can probably notice that. Is the reason known?

glSnoop 1.0 RC1 is available. These are the main changes since version 0.3:

- Support ogles2.library version 3.1 and Warp3DNova.library 1.83
- Decode enum parameters and taglists
- Open GUI classes before use
- Display W3DN_Clear parameters
- Use 4 kilobyte log chunks in serial logging
- Compile with GCC 10.2.

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

Compatibility note: if you are using older libraries, due to function patching, you probably should filter out the newer functions or use older glSnoop versions.

@Capehill

Tried to build your latest code of glSnoop from gthub to be up2date and have that:



And so on.

is it something on my side or in glsnoop code ?

@kas1e

Have those enums been removed or renamed since last public Nova release?

@Capehill
Sorry , that again was my fault. I updated warp3dnova includes to the very latest ones, and everything fine now. Will use now your latest version of glSnoop

@Capehill
Is it possible to set output to serial things such as:

*** start time triggered ***
Timer signal - start profiling
Waiting for timer...

That can help when we use some big games and want to profile them, without needs to amiga+m to see in console when actually profiling timer start (necessary when you set to start profiling after a long while, like 1-2 minutes).

@kas1e

Currently, you would probably need to change the source code.

I have been wondering if it be possible to redirect standard output to SER: device somehow? IIRC I tried it someday but failed and then forgot about it.

@Capehill
What i mean was "if it possible to change glsnoop code doing this" :) Just asking if it worth to be in the TODO for glsnoop changes, or it better not touch in this regard.

glSnoop 1.1 RC1 is available. Changes:

- Make function tracing more consistent
- Log timestamps
- Improve GL error handling
- Add support for new OGLES2 and Nova features
- Fix some CppCheck findings

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

EDIT, also here: http://capehill.kapsi.fi/glsnoop/

@Capehill
Thanks a bunch! glsnoop helps a lot