Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
90 user(s) are online (73 user(s) are browsing Forums)

Members: 0
Guests: 90

more...

Support us!

Headlines




« 1 ... 7 8 9 (10)


Re: Porting apitrace
Not too shy to talk
Joined:
2011/6/3 13:49
Posts: 269
Have you tried to compile from RAM: ? Perhaps GCC got problems with some file systems ?

   Report Go to top

Re: Porting apitrace
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7018
@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.


Edited by kas1e on 2019/12/15 14:29:26
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Porting apitrace
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1325
@kas1e

Yep, glSnoop is getting better...

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

   Report Go to top

Re: Porting apitrace
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7018
@Capehill
Tested latest tequila with PROFILE, see another thread about profiles there, so we not deral apitrace-glsnoop one.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Porting apitrace
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7018
@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" ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Porting apitrace
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1325
@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

   Report Go to top

Re: Porting apitrace
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1325
@kas1e

Quote:

So.. wtf ?:) Is it just dumpdebugbuffer can't handle big enough strings (that somewhere a bit more than 1024) ?

Full shader in line are 1401 bytes, while when we stop when do dumpdebugbuffer, it print only 1082 bytes


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?

   Report Go to top

Re: Porting apitrace
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7018
@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 :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Porting apitrace
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1325
@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?

   Report Go to top

glSnoop 1.0
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1325
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.

   Report Go to top


« 1 ... 7 8 9 (10)



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project