Porting apitrace

	Bottom Previous Topic Next Topic
Register To Post

« 1 ... 6 7 8 (9) 10 »

kas1e

Re: Porting apitrace

Posted on: 2019/10/7 20:14 #161

Home away from home

@Capehill
You are right, don't waste your time on it for sure. Logging already fine enough :)

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: Porting apitrace

Posted on: 2019/10/9 9:39 #162

Home away from home

@Capehill
Tested latest version : independent starttime & duration works fine, as well as output in info log are good too :) Thanks a bunch for such a fast fixes/changes.

I notice through few little nitpicking issues which we can skip, but maybe worth to note (or maybe add them to BZ for 0.4 or for some future):

1). As we can use "Starttime" or "Duration" only with "PROFILE", then maybe worth at begining when we run glsnoop check also on that: if no PROFILE arg was used, but or Starttime, or Duration, or both was used, then or exit with words "sorry, startstime & duration can be used only in PROFILE mode", or, continue with the same words, but like "sorry, starttime & duration can be used in PROFILE mode only, skiping and continue without".

So that will be good user's feadback about.

2). it didn't works in GUI , but that probabaly expected ? Maybe to make it works in GUI, the same checking on args need it (so if PROFILE used, and if anything like STARTTIME or DURATION or both used and that all toghet with GUI), then make it works, just run gui with all buttons disabled. Or even instead of buttons, wrote in the middle of gui window "you can't control tracing/profiling when starttime/duration is used"

3). if you run glsnoop like "glsnoop PROFILE STARTTIME 10" (for example), and then imeediately press "ctrl+c" , then after words "*** Control-C detected ***" , we have "*** Delay timer triggered ***", while it wasn't triggered (as we for first didn't start anything yet, and for seconds 10 seconds didn't pass for trigger the delay timer). I think it can be some missing "if/else" ?

All of this for sure not really important, just trying to find any pieces which can be improved even a little bit :)

ps. And i have no single crash or issues for now when use glsnoop in all conditions. Pretty stable and helpfull

ps2. And i checked "tequila" of course too, pretty good :)

Join us to improve dopus5!
AmigaOS4 on youtube

Capehill

Re: Porting apitrace

Posted on: 2019/10/9 16:43 #163

Just can't stay away

1) I will add some prints.

2) Yes, GUI mode is not supported. I don't want to duplicate all that timer logic on GUI side and GUI is pretty pointless if you are using start/duration params, in my opinion. If it can be implemented without code duplication, I might enable it in the future.

3) It's probably because timer is not cancelled upon CTRL-C. EDIT: "delay timer" (or "patch cooldown timer") is triggered in all cases. IExec has been patched and those patches must be removed "safely".

Edited by Capehill on 2019/10/10 19:15:48

Capehill

Re: Porting apitrace

Posted on: 2019/10/10 19:12 #164

Just can't stay away

v0.3 RC 2 is available: https://github.com/capehill/glsnoop/releases/tag/v0.3-rc2

kas1e

Re: Porting apitrace

Posted on: 2019/10/13 20:07 #165

Home away from home

@Capehill
Tested, yeah, all fine, thanks !

Btw, sorry for saying that, i am sure that you know it all well, but i just see you always change the build date manually, which of course take your time for nothing. Instead, you can use "date" for both crosscompiler and native. There adapted glsnoop's makefile:


ifneq ($(shell uname), AmigaOS)

    CC            = ppc-amigaos-gcc

    DELETE        = rm -f

    STRIP        = ppc-amigaos-strip

    NEWDATE        = $(shell date +"%-d.%-m.%Y")

else

    CC            = gcc

    DELETE        = delete

    STRIP        = strip

    NEWDATE        = $(shell date LFORMAT=%-d.%-m.%Y)

endif



NAME = glSnoop

OBJS = main.o ogles2_module.o warp3dnova_module.o logger.o gui.o common.o filter.o timer.o profiling.o

DEPS = $(OBJS:.o=.d)



CFLAGS = -Wall -Wextra -O3 -gstabs -D__COMPDATE__="$(NEWDATE)" 



# Dependencies

%.d : %.c

    $(CC) -MM -MP -MT $(@:.d=.o) -o $@ $< $(CFLAGS)



%.o : %.c

    $(CC) -o $@ -c $< $(CFLAGS)



$(NAME): $(OBJS) makefile

    $(CC) -o $@ $(OBJS) -lauto



clean:

    $(DELETE) $(OBJS)



strip:

    $(STRIP) $(NAME)



ifneq ($(MAKECMDGOALS),clean)

-include $(DEPS)

endif

See there i add for both native and crosscompiler different date call to have the same output, and in the CFLAGS add new __COMPDATE__ which will take the date.

So in code for both glsnoop and tequila you can use that __COMPDATE__ later without needs to worry anymore about manual date set.

That will have needs to do once, and you can forget about for all the time, and date will be always 100% accurate

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: Porting apitrace

Posted on: 2019/10/24 19:52 #166

Home away from home

@Capehill
Found some formatting bug probably in ogles2 shader's patch function.

In the original code i have that:


static stringc vertToonShader =

"varying vec2 vTexCoord;"

"void main(void)"

"{"

"   vec2 Position;"

"   Position.xy = sign(gl_Vertex.xy);"

"   gl_Position = vec4(Position.xy, 0.0, 1.0);"

"   vTexCoord =Position.xy *.5 + .5;"

"}";



static stringc fragToonShader =

"uniform sampler2D texture[2];"

"varying vec2 vTexCoord;"

"uniform float sampleDist;"

"uniform float grayScaleFactor;"

"void main()"

"{"

"   vec2 samples[12];"

"   samples[0]  = vTexCoord + sampleDist * vec2(-0.326212, -0.405805);"

"   samples[1]  = vTexCoord + sampleDist * vec2(-0.840144, -0.073580);"

"   samples[2]  = vTexCoord + sampleDist * vec2(-0.695914,  0.457137);"

"   samples[3]  = vTexCoord + sampleDist * vec2(-0.203345,  0.620716);"

"   samples[4]  = vTexCoord + sampleDist * vec2(0.962340, -0.194983);"

"   samples[5]  = vTexCoord + sampleDist * vec2(0.473434, -0.480026);"

"   samples[6]  = vTexCoord + sampleDist * vec2(0.519456,  0.767022);"

"   samples[7]  = vTexCoord + sampleDist * vec2(0.185461, -0.893124);"

"   samples[8]  = vTexCoord + sampleDist * vec2(0.507431,  0.064425);"

"   samples[9]  = vTexCoord + sampleDist * vec2(0.896420,  0.412458);"

"   samples[10]  = vTexCoord + sampleDist * vec2(-0.321940, -0.932615);"

"   samples[11]  = vTexCoord + sampleDist * vec2(-0.791559, -0.597705);"

"   vec4 sample = texture2D(texture[0], vTexCoord);"

"   for(int i = 0; i < 12; i++)"

"   {"

"      sample += texture2D(texture[0],samples[i] );"

"   }"

"   sample /= 13.0;"

"   float greyscale=sample.r*0.3+sample.g*0.59+sample.b*0.11;"

"   vec4 gray;"

"   gray.r=greyscale;"

"   gray.g=greyscale;"

"   gray.b=greyscale;"

"   gl_FragColor = (sample*(1-grayScaleFactor)) + (gray*grayScaleFactor);"

"}";

Now, when i do choice to patch only shader's based functions in ogles i have 2 issues.

1st one : output have no cariage return after a ";" most of time.

2st one : second shaders dump not fully, and stop on the words
for(int.

That how glsnoop output looks like for me for those 2 shaders:

Quote:

Shell Process 'NIGHT OF THE ZOMBIES.exe': OGLES2_glShaderSource: shader 259, count 1, string 0x5721f9a8 length 0x0
Line 0: '#version 100
precision highp float;
precision highp int;
attribute highp vec4 _gl4es_Vertex;
varying vec2 vTexCoord;void main(void){ vec2 Position; Position.xy = sign(_gl4es_Vertex.xy); gl_Position = vec4(Position.xy, 0.000000, 1.000000); vTexCoord =Position.xy *.5 + .5;}'
Shell Process 'NIGHT OF THE ZOMBIES.exe': OGLES2_glCompileShader: shader 259
Shell Process 'NIGHT OF THE ZOMBIES.exe': OGLES2_glShaderSource: shader 260, count 1, string 0x5721f900 length 0x0
Line 0: '#version 100
precision highp float;
precision highp int;
uniform sampler2D texture[2];varying vec2 vTexCoord;uniform float sampleDist;uniform float grayScaleFactor;void main(){ vec2 samples[12]; samples[0] = vTexCoord + sampleDist * vec2(-0.326212, -0.405805); samples[1] = vTexCoord + sampleDist * vec2(-0.840144, -0.073580); samples[2] = vTexCoord + sampleDist * vec2(-0.695914, 0.457137); samples[3] = vTexCoord + sampleDist * vec2(-0.203345, 0.620716); samples[4] = vTexCoord + sampleDist * vec2(0.962340, -0.194983); samples[5] = vTexCoord + sampleDist * vec2(0.473434, -0.480026); samples[6] = vTexCoord + sampleDist * vec2(0.519456, 0.767022); samples[7] = vTexCoord + sampleDist * vec2(0.185461, -0.893124); samples[8] = vTexCoord + sampleDist * vec2(0.507431, 0.064425); samples[9] = vTexCoord + sampleDist * vec2(0.896420, 0.412458); samples[10] = vTexCoord + sampleDist * vec2(-0.321940, -0.932615); samples[11] = vTexCoord + sampleDist * vec2(-0.791559, -0.597705); vec4 sample = texture2D(texture[0], vTexCoord); for(int

See first shader start dumping fine, with cariage return after ";", then it disappear, and after that all going in line. And second shader dumped not in full size.

Join us to improve dopus5!
AmigaOS4 on youtube

Capehill

Re: Porting apitrace

Posted on: 2019/10/26 11:07 #167

Just can't stay away

@kas1e

1) That's because shader string doesn't contain '\n' characters. Apparently only the prefix part does.

2) It seems to be chopped after about 1 kilobyte while glSnoop log buffer is 16 kilobytes. Does it happen with or without Sashimi? At least DebugPrintF() function is able to print longer buffers (> 1024 chars).

I think there is a bug in glSnoop in case strings weren't NUL-terminated and "length" array was passed because lengths are ignored as far as I can see, but this a separate issue.

kas1e

Re: Porting apitrace

Posted on: 2019/10/26 17:33 #168

Home away from home

@Capehill
Quote:

1) That's because shader string doesn't contain '\n' characters. Apparently only the prefix part does.

That probabaly because prefix part added by gl4es at top of original shader , and then other part taken without modification as it. So probabaly not something we need to worry about then (?).

Quote:

2) It seems to be chopped after about 1 kilobyte while glSnoop log buffer is 16 kilobytes. Does it happen with or without Sashimi? At least DebugPrintF() function is able to print longer buffers (> 1024 chars).

It was pure "dumpdebugbuffer" in console (and i even tried to redirect it to a file, same result). When i just trace shaders function there no big needs in sashimi, as not that much to dump, so no slowing downs.

And when i check, that string wasn't line 1024, but something like 1068 or so. Yeah, "almost" 1024 limit, but a bit more.

Join us to improve dopus5!
AmigaOS4 on youtube

Capehill

Re: Porting apitrace

Posted on: 2019/10/27 9:37 #169

Just can't stay away

@kas1e

I haven't been able to reproduce issue. Maybe you can add a normal printf() somewhere around https://github.com/capehill/glsnoop/bl ... ter/ogles2_module.c#L2259 for comparison.

kas1e

Re: Porting apitrace

Posted on: 2019/10/27 11:52 #170

Home away from home

@Capehill
There is little fault in makefile which make it fail to bulid on crosscompiler, it should be not:

Quote:

CFLAGS = -Wall -Wextra -O3 -gstabs -D__AMIGA_DATE__="$(AMIGADATE)"

But with added \ char before both " things. That should be fine and for crosscompiler's shells , and for "sh" on amigaos4, and for pure amigaos4 shell

Edited by kas1e on 2019/10/27 12:09:57

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: Porting apitrace

Posted on: 2019/10/27 12:18 #171

Home away from home

@Capehill
Quote:

I haven't been able to reproduce issue. Maybe you can add a normal printf() somewhere around https://github.com/capehill/glsnoop/bl ... ter/ogles2_module.c#L2259 for comparison.

Yeah, there is printf output:

Quote:

'Line 0: '#version 100
precision highp float;
precision highp int;
uniform sampler2D texture[2];varying vec2 vTexCoord;uniform float sampleDist;uniform float grayScaleFactor;void main(){ vec2 samples[12]; samples[0] = vTexCoord + sampleDist * vec2(-0.326212, -0.405805); samples[1] = vTexCoord + sampleDist * vec2(-0.840144, -0.073580); samples[2] = vTexCoord + sampleDist * vec2(-0.695914, 0.457137); samples[3] = vTexCoord + sampleDist * vec2(-0.203345, 0.620716); samples[4] = vTexCoord + sampleDist * vec2(0.962340, -0.194983); samples[5] = vTexCoord + sampleDist * vec2(0.473434, -0.480026); samples[6] = vTexCoord + sampleDist * vec2(0.519456, 0.767022); samples[7] = vTexCoord + sampleDist * vec2(0.185461, -0.893124); samples[8] = vTexCoord + sampleDist * vec2(0.507431, 0.064425); samples[9] = vTexCoord + sampleDist * vec2(0.896420, 0.412458); samples[10] = vTexCoord + sampleDist * vec2(-0.321940, -0.932615); samples[11] = vTexCoord + sampleDist * vec2(-0.791559, -0.597705); vec4 sample = texture2D(texture[0], vTexCoord); for(int i = 0; i < 12; i++) { sample += texture2D(texture[0],samples[i] ); } sample /= 13.000000; float greyscale=sample.r*0.300000+sample.g*0.590000+sample.b*0.110000; vec4 gray; gray.r=greyscale; gray.g=greyscale; gray.b=greyscale; gl_FragColor = (sample*(1-grayScaleFactor)) + (gray*grayScaleFactor);}'

And there is output which i have from glsnoop when do dumpdebugbuffer:

Quote:

'#version 100
precision highp float;
precision highp int;
uniform sampler2D texture[2];varying vec2 vTexCoord;uniform float sampleDist;uniform float grayScaleFactor;void main(){ vec2 samples[12]; samples[0] = vTexCoord + sampleDist * vec2(-0.326212, -0.405805); samples[1] = vTexCoord + sampleDist * vec2(-0.840144, -0.073580); samples[2] = vTexCoord + sampleDist * vec2(-0.695914, 0.457137); samples[3] = vTexCoord + sampleDist * vec2(-0.203345, 0.620716); samples[4] = vTexCoord + sampleDist * vec2(0.962340, -0.194983); samples[5] = vTexCoord + sampleDist * vec2(0.473434, -0.480026); samples[6] = vTexCoord + sampleDist * vec2(0.519456, 0.767022); samples[7] = vTexCoord + sampleDist * vec2(0.185461, -0.893124); samples[8] = vTexCoord + sampleDist * vec2(0.507431, 0.064425); samples[9] = vTexCoord + sampleDist * vec2(0.896420, 0.412458); samples[10] = vTexCoord + sampleDist * vec2(-0.321940, -0.932615); samples[11] = vTexCoord + sampleDist * vec2(-0.791559, -0.597705); vec4 sample = texture2D(texture[0], vTexCoord); for(int

2/0.Work:debug/glsnoop>

I.e. its that when i just have those 2 lines one after another:


logLine("Line %u: '%s'", i, string[i]);

printf("Line %u: '%s'", i, string[i]);

Then tried sashimy : there is all fine !

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

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: Porting apitrace

Posted on: 2019/11/10 7:25 #172

Home away from home

@Capehill
Is there any way with current glSnoop, to dump content of W3DN_DBOSetBuffer ? I mean content of buffers exactly in hex format.

Join us to improve dopus5!
AmigaOS4 on youtube

Capehill

Re: Porting apitrace

Posted on: 2019/11/10 11:18 #173

Just can't stay away

@kas1e

Try something like


diff --git a/warp3dnova_module.c b/warp3dnova_module.c

index 207869a..5b91f1f 100644

--- a/warp3dnova_module.c

+++ b/warp3dnova_module.c

@@ -863,6 +863,11 @@ static W3DN_ErrorCode W3DN_BufferUnlock(struct W3DN_Context_s *self,

 {

     W3DN_ErrorCode result = W3DNEC_SUCCESS;

 

+    const size_t items = bufferLock->size / 4;

+    for (size_t i = 0; i < items; i++) {

+        logLine("[%u] = 0x%lX", i, bufferLock->buffer[i]);

+    }

+

     NOVA_CALL_RESULT(result, BufferUnlock, bufferLock, writeOffset, writeSize)

 

     logLine("%s: %s: bufferLock %p, writeOffset %llu, writeSize %llu. Result %d (%s)", context->name, __func__,

It will dump all buffers, not only DBOs and in case buffer sizes are not aligned to 32-bits, it may fail to print some bytes.

kas1e

Re: Porting apitrace

Posted on: 2019/12/10 8:05 #174

Home away from home

@Capehill

What you think , is it worth to create BZ about "put human values in ogles2 tracing to glTexParameteri() instead of numbers values" ?

For example, i for now need to trace some bug, to check why i have some distored picture. So i need to know what i set via glTexParameteri. Currently , output looks like this for example:

Quote:

OGLES2_glTexiParameteri: target 3353, pname 10241, param 9985
OGLES2_glTexiParameteri: target 3353, pname 10242, param 33071
OGLES2_glTexiParameteri: target 3353, pname 10243, param 33071
OGLES2_glTexiParameteri: target 3353, pname 10241, param 9729

So currently i had to refer to something like https://developer.android.com/reference/android/opengl/GLES20 , to see actual meaning of "pname" and of "param". But for sure will be better if instead of numbers there will be actual values. That will mean no additional work of copy+compare+rewrite-log :)

Join us to improve dopus5!
AmigaOS4 on youtube

Capehill

Re: Porting apitrace

Posted on: 2019/12/10 9:26 #175

Just can't stay away

@kas1e

There is already ticket https://github.com/capehill/glsnoop/issues/20 that should cover this. I can start with texture params so feel free to write some comments.

kas1e

Re: Porting apitrace

Posted on: 2019/12/10 10:31 #176

Home away from home

@Capehill
Thanks, done !

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: Porting apitrace

Posted on: 2019/12/10 20:48 #177

Home away from home

@Capehill
Checked latest commit , it works ! Thanks a bunch !

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: Porting apitrace

Posted on: 2019/12/13 17:58 #178

Home away from home

@Capehill
Tried to profile some game, loading of which take about 40 seconds on x5000, and only 5 seconds on some modern win32 box. On loading all what happens, its bunch of textures puts to GPU video memory (about 500-600mb).

Now, i made a profile log:
http://kas1e.mikendezign.com/aos4/tmp/profile_slow_loading.txt

And when i run game, via cpu_monitor or via tequilla it show that binary itself take 96% of cpu loading. So something heavy happens there. But then, seeing that profiling log, it looks like that warp3dnova and olges2 , there take only ~10% of cpu loading , right ? (at least that what i see checking last column).

Or the column i need to watch on are one before last one ? With that "% of 6041.878015 ms" ?

Join us to improve dopus5!
AmigaOS4 on youtube

Capehill

Re: Porting apitrace

Posted on: 2019/12/13 18:21 #179

Just can't stay away

@kas1e

Doesn't seem very GL heavy really, as you say about 10% was spent in OGLES2/Nova context. glTexImage2D took about 1 second in total.

Maybe there is some slowness when loading and unpacking data?

Have you tried Snoopy to check file access?

Which filesystem did you try?

kas1e

Re: Porting apitrace

Posted on: 2019/12/13 18:31 #180

Home away from home

@Capehill
Its x5000 with NGFS, and in general i notice that slow loading everywhere where game need to put lots of stuff to memory.

Besides, i surprised with slow compiling times. Remembr i say before that on x5000 compiling of irrlicht engine take about 20 minutes (or so), while just few on win32. That kind of strange ..

Join us to improve dopus5!
AmigaOS4 on youtube

Register To Post	« 1 ... 6 7 8 (9) 10 »
	Top Previous Topic Next Topic

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