Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
63 user(s) are online (43 user(s) are browsing Forums)

Members: 1
Guests: 62

K-L, more...

Support us!

Headlines




« 1 ... 7 8 9 (10)


Re: Porting apitrace
Not too shy to talk
Joined:
2011/6/3 13:49
Posts: 264
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: 6375
@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: 1098
@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: 6375
@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: 6375
@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: 1098
@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: 1098
@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


« 1 ... 7 8 9 (10)



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project