Some test-case lockup

[kas1e]

There is test case i do check for now on amigaos4: http://kas1e.mikendezign.com/aos4/gl4es/tests/drawbuffer_gl4es.c

Once i run it, after few loops of DrawBox() , it crashes.

It works through when pure opengl used (some old 1.1 version which we have), but can be that bug in the code as well. There is only defined 6 normals for 8 vertices, but probably that should't cause crash ?

@ptitSeb Can you check plz that GL code on your own (with SDL or something) , to see if that code works at all for on gl4es, so we can then know if it amigaos4 only issue or not.

Thanks!

[ptitSeb]

@kas1e I have tested on the Pandora, and I have no lockup. I see an oversized cube, witch each face with its own color, rotating.

Did you locate where the crash occurs?

Also: the Normal is not an issue. You have not defined a NormalArray here, but you are just defining the Normal 1 time per face., with a simple glNormal3fv. The code is correct.

[kas1e]

I have tested on the Pandora, and I have no lockup. I see an oversized cube, witch each face with its own color, rotating.

Yes, that how it should be (oversized just because i comment out 2 GLU functions to be able to build without).

Did you locate where the crash occurs?

Its hard, as it lockup whole machine and i can't normally debug it , but all i can see, is that when i put prinfs after and before each function, i can see how drawbox() called for about 10 times (and code from executes), and then, crashes on glNormal3fv().

Can it be issues with the same uniforms and stuff which we workoround yesterday ?

[ptitSeb]

Mmm, you are not in a drawing loop when you call glNormal3fv(..) so not much is done with the info. fpe_glNormal3f should be called, which does nothing... (in fact, only things hapening is storing current normal in glstate for later use, in the drawing shader because light is enabled and normal is needed).

It can be something odd with Uniform/Attrib yes.

You should activate some debug info in gl4es, and do only 2 loop and exit, to avoid freeze and get access to logs.

[kas1e]

It can be something odd with Uniform/Attrib yes.

Author of our driver already checking it, probably if all going well will have fixed version today (and so we for first can remove workoround, and for second can be sure if it because of that crashes in that example, or not).

You should activate some debug info in gl4es, and do only 2 loop and exit, to avoid freeze and get access to logs.

Indeed ! Thansk for idea :)

[kas1e]

@ptitSeb I recieve fixed version of ogles2.library , so we can remove workoround for amigaos4 in the gl/program.c

Through, it didn't fish crash about which that ticket, so i will follow now your suggestion and will try to enable as much debug as possible

[ptitSeb]

Done, workaround removed.

You should put some traces in fpe.c, shaderconv.c and program.c at least, that should give a good idea on what is going on.

[kas1e]

To be on safe side from begining, i enable debug everywhere:

gl/buffers.c gl/fpe.c gl/framebuffer.c gl/matrix.c gl/program.c gl/shader.c gl/shaderconv.c gl/texture.c gl/uniform.c gl/vertexattrib.c

And just do it like:

for (i = 0; i < 6; i++) { // exit after 3 ! if (i>3) { exit(0);};

glEnableClientState(GL_VERTEX_ARRAY); glNormal3fv(&n[i][0]); glVertexPointer(3, GL_FLOAT, 0, v); glColor3fv(&colors[i][0]);

glDrawElements(GL_QUADS, 4, GL_UNSIGNED_INT, faces[i]); } }

full source here: http://kas1e.mikendezign.com/aos4/gl4es/tests/gl4es_crash_try_to_debug.c

And the debug log is: http://kas1e.mikendezign.com/aos4/gl4es/tests/gl4es_crash_try_to_debug.txt

After program exit , after 2 or 3 seconds whole lockup.

Its like some heavy trashing of some memory somewhere ..

[ptitSeb]

For reference, the shader used is: Vertex:

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat3 _gl4es_NormalMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
attribute highp vec3 _gl4es_Normal;
struct _gl4es_LightModelParameters {
  vec4 ambient;
};
uniform _gl4es_LightModelParameters _gl4es_LightModel;
struct _gl4es_MaterialParameters
{
   vec4 emission;
   vec4 ambient;
   vec4 diffuse;
   vec4 specular;
   float shininess;
};
uniform _gl4es_MaterialParameters _gl4es_FrontMaterial;
uniform _gl4es_MaterialParameters _gl4es_BackMaterial;
// FPE_Shader generated
// ** Vertex Shader **
// ligthting=1 (twosided=0, separate=0, color_material=1)
// secondary=0, planes=000000
// texture=00000000, point=0
varying vec4 Color;
struct _gl4es_FPELightSourceParameters1
{
   highp vec4 ambient;
   highp vec4 diffuse;
   highp vec4 specular;
   highp vec4 position;
   highp vec3 spotDirection;
   highp float spotExponent;
   highp float spotCosCutoff;
   highp float constantAttenuation;
   highp float linearAttenuation;
   highp float quadraticAttenuation;
};
struct _gl4es_FPELightSourceParameters0
{
   highp vec4 ambient;
   highp vec4 diffuse;
   highp vec4 specular;
   highp vec4 position;
   highp vec3 spotDirection;
   highp float spotExponent;
   highp float spotCosCutoff;
};
struct _gl4es_LightProducts
{
   highp vec4 ambient;
   highp vec4 diffuse;
   highp vec4 specular;
};
uniform _gl4es_FPELightSourceParameters0 _gl4es_LightSource_0;
uniform _gl4es_LightProducts _gl4es_FrontLightProduct_0;

void main() {
vec3 normal = _gl4es_NormalMatrix * _gl4es_Normal;
gl_Position = _gl4es_ModelViewProjectionMatrix * _gl4es_Vertex;
// ColorMaterial On/Off=1 Front = 0 Back = 0
Color = _gl4es_FrontMaterial.emission;
Color += _gl4es_Color*_gl4es_LightModel.ambient;
highp float att;
highp float spot;
highp vec3 VP;
highp float lVP;
highp float nVP;
highp vec3 aa,dd,ss;
highp vec3 hi;
// light 0 on, light_direction=0, light_cutoff180=0
att = 1.0;
VP = normalize(_gl4es_LightSource_0.position.xyz);
aa = _gl4es_Color.xyz * _gl4es_LightSource_0.ambient.xyz;
nVP = dot(normal, VP);
dd = (nVP>0.)?(nVP * _gl4es_Color.xyz * _gl4es_LightSource_0.diffuse.xyz):vec3(0.);
hi = normalize(VP + vec3(0., 0., 1.));
lVP = dot(normal, hi);
ss = (nVP>0. && lVP>0.)?(_gl4es_FrontLightProduct_0.specular.xyz):vec3(0.);
Color.rgb += att*(aa+dd+ss);
// end of light 0
Color.a = _gl4es_Color.a;
Color.rgb = clamp(Color.rgb, 0., 1.);
// texturing
}

Fragment:

#version 100
precision mediump float;
precision mediump int;
// FPE_Shader generated
// ** Fragment Shader **
// lighting=1, alpha=0, secondary=0, planes=000000, texture=00000000, texformat=00000000 point=0
varying vec4 Color;
void main() {
vec4 fColor = Color;
gl_FragColor = fColor;
}

[ptitSeb]

There are still some issue with Uniform :(

The Mat3 and Mat4 are fixed! But there is an issue with struct uniform now. For example, the _gl4es_FrontMaterial uniform is of type struct _gl4es_MaterialParameters So, the glGetUniform should return all individual struct element, not the struct itself. AmigaOS4 OGLES2 return:

uniform #2 : "_gl4es_FrontMaterial" (builtin)  type=GL_POINTS size=1

(note: type=GL_POINTS means type=0x0000) it should return:

 uniform #3 : "_gl4es_FrontMaterial.emission" (builtin)  type=GL_FLOAT_VEC4 size=1
 uniform #4 : "_gl4es_FrontMaterial.ambient" (builtin)  type=GL_FLOAT_VEC4 size=1
 uniform #5 : "_gl4es_FrontMaterial.diffuse" (builtin)  type=GL_FLOAT_VEC4 size=1
 uniform #6 : "_gl4es_FrontMaterial.specular" (builtin)  type=GL_FLOAT_VEC4 size=1
 uniform #7 : "_gl4es_FrontMaterial.shininess" (builtin)  type=GL_FLOAT size=1

I don't see any easy workaround here. Can you open a new bug? Hopefully it's easlily fixable?

[ptitSeb]

In fact, using a struct, you really create as many different uniform as there is struct elements...

[kas1e]

Tested shaders : they both ok.

As for issue you find, will notice author of driver now

Thanks for help !

[ptitSeb]

In gl4es side, that means the light and material parameters are never updated, so there are at 0. the shaders then try to compute stuff with that, it may not be good...

[kas1e]

Btw, while experimenting with it, what you think is it worth adding something like -DDEBUG_ALL=1 so, once someone will need to debug everything , it will be enough to recompile gl4es with that ? Just as idea of course, maybe uncommenting per file its easy for debug purporses..

[ptitSeb]

I prefer to not have a test at the beggining of each function (like if(globals4es.debug) printf(...);, because it's a waste of cpu cycle for most case (you rarely want to debug in fact), were the #define is more efficiant. Of course, that means recompiling, but I prefer speed...

[ptitSeb]

Aaah, I missed your point

If you want to activate all debug, simply add -DDEBUG=1 and you'll have a super chatty gl4es version!

[kas1e]

Yeah, that what i mean, thanks for point out !

Author of ogles2 driver works on "struct" stuff, will wait then once he done.

Probably, until structs is fixed, we can't go futher anyway, as in any shader you generate strcuts will be used probably ?

[ptitSeb]

Yeah, I don't use array, but I do use struct a lot. We need to wait for a fix, as removing struct is a lot of work.

[kas1e]

Yeah, sure we need to fix it on our side , as it will make gles2 driver be better, and will avoid unnecessary hassle in gl4es. Hope today/tomorrow author will be done with, so we can continue tests :)

[ptitSeb]

Ok. (in the mean time, take a look at my github account, there are a few games that can be worth porting on AmigaOS4 ;) )

[kas1e]

Yeah, will try them all :)

Btw, is it possible add to cmake in the amigaos4 area, to set compile to be "ppc-amigaos-gcc" ? I mean something like:

AmigaOS4

if(AMIGAOS4) set_compier_gcc("ppc-amigaos-gcc") set_compiler_g++("ppc-amigao-g++") set_compiler_ar("ppc-amigaos-ar") set_compiler_ranlib("ppc-amigaos-ranlib") add_definitions(-DAMIGAOS4) set(NOX11 ON) set(NOEGL ON) endif()

[ptitSeb]

Sure I can.

I also see for an option to build as static lib or dynamic

[ptitSeb]

Done. Commit 271e72898558598338aa7c63073092ed72928e45 force the compiler for AMIGAOS, and there is a new option if the cmake "STATICLIB" to build gl4es as a static lib. I haven't forced AMIGAOS4 to use STATICLIB, but I can if it make no sense to build as a dynamic lib.

[kas1e]

Checked, seems something wrong ..

cmake . -DAMIGAOS4=1; make GL

give me :

-- The C compiler identification is unknown -- The CXX compiler identification is unknown

And in log i can see it still tries to use /usr/bin/cc

But as i cross-compile (on cygwin), maybe that make difference ? ppc-amigaos-gcc and co, the same and on crosscompiler, and on native , so by adding that to cmake i was in hope cmake will just use those ones. But probably it check for "uname" or something firstly ?

[ptitSeb]

strange, I tested on my side befor pushing (using ccmake, the curse client of cmake, as I find it more conveniant) and it was looking for ppc-amigaos-gcc. What version of cmake do you have?

[kas1e]

3.3.2

Not that its very important (as i anyway use pure bash script with necessary to build objects), but as you add amigaos4 to cmake, maybe it worth to make it working :)

I also have 2 cmake out logs, in one about Compiler: /usr/bin/c , and in another "The system is: CYGWIN - 2.3.1(0.291/5/3) - i686". Maybe, it still somehow think that it linux (cmake somewhere deep maybe do cygwin = linux), and then cmake fail.

[kas1e]

I also recieve new fixed driver. Through, we not sure if it works as it should , as test case still crasehes :( but on some simple tests looks like ok. Through in your example you say that it should be:

uniform #3 : "_gl4es_FrontMaterial.emission" (builtin) type=GL_FLOAT_VEC4 size=1 uniform #4 : "_gl4es_FrontMaterial.ambient" (builtin) type=GL_FLOAT_VEC4 size=1

While in my new debug output its a bit shifted, i.e.:

uniform #0 : "_gl4es_NormalMatrix" (builtin) type=GL_FLOAT_MAT3 size=1 uniform #1 : "_gl4es_ModelViewProjectionMatrix" (builtin) type=GL_FLOAT_MAT4 size=1 uniform #2 : "_gl4es_FrontMaterial.emission" (builtin) type=GL_FLOAT_VEC4 size=1 uniform #3 : "_gl4es_FrontMaterial.ambient" (builtin) type=GL_FLOAT_VEC4 size=1 uniform #4 : "_gl4es_FrontMaterial.diffuse" (builtin) type=GL_FLOAT_VEC4 size=1 uniform #5 : "_gl4es_FrontMaterial.specular" (builtin) type=GL_FLOAT_VEC4

I.e. #3 ambient, #4 diffuse , like shifted on 1 position , but maybe that ok and it was just typo in your example ?

Anyway, test-case still crashes :( There is new debug output: http://kas1e.mikendezign.com/aos4/gl4es/tests/fixed_structs_debug.txt

[kas1e]

Also with enabled -DDEBUG=1, latest texture.c didn't compiles, as well as glx.c on linking stage bring undef to "create_rpi_window". All other objects compiles fine

[ptitSeb]

The new driver seems to work fine. I don't think the shifted position is a problem.

The log seems fine now to me, I don't see anything wrong. How is the rendering before the crash? is it correct

(I'll try to fix the build error with texture.c and glx.c)

[ptitSeb]

I don't have error on texture.c with DEBUG=1 on my side. What error do you have ?

[kas1e]

Its even didn't render anything, just open window and then baam :) If i put a lot of Delays() around every function, then i can see that it tries to render something .. something not related to the cube at all. Just some strange triangle, like everything wrong..

I start to fear it may be issue with our shaders, like it compiles, run , but just works wron.

What you think if we will try to change ss = (nVP>0. && lVP>0.)?(_gl4es_FrontLightProduct_0.specular.xyz):vec3(0.); on some dummy value ?

Or, maybe we can try to shorted vertex shader, just to see, if it shader's bug at all or not..

As for texture error with DDEBUG: src/gl/texture.c:2518: error: 'glstate_t' has no member named 'bound_stream'

[ptitSeb]

If you want, just cut the lightning: comment the glEnable(GL_LIGHTNING); that will greatly simplify the shader...

[kas1e]

Yeah, disabled in crash code glEnable(GL_LIGHTING); and still lockup ! debug: http://kas1e.narod.ru/no_light.txt

And shaders indeed very simple ones (imho).

[ptitSeb]

So I guess this is not the shader, as it's the same as last time.

How is the rendering this time? Still grabage?

[ptitSeb]

Also, can you comment those lines:

            glDrawBuffer(GL_BACK);
            display();
            glDrawBuffer(GL_FRONT);

that are after the SwapBuffers, just to simplify the code and try to pinpoint the piece that cause the freeze.

[kas1e]

Ops sorry i was wrong : No crash ! Cube rotate without gl_Enable(GL_LIGHTING);

Wtf..

[ptitSeb]

Ah, so it can be the a shader issue.

[kas1e]

Yeah, those ones commented already, i just didn't update test case, there is new src: http://kas1e.narod.ru/gl4es_crash.c

[kas1e]

Ok.. now probably need to find what in shader cause that, so i can then report it to shader's code author (damn!)

[ptitSeb]

Can the guy that develop the ogles2 driver help debugging here?

Now, if you want to simplify the shader yourself, you will need to hack-in in src/gl/fpe_shader.c It's mainlys mainy sprintf, so you will have to comment inside the string, to comment in the shader (it will be better then commenting the code generation itself I think).

You are interested in lines 354, 372 & 391 mainly.

[kas1e]

Can the guy that develop the ogles2 driver help debugging here?

Yeah he already, just its 2 different persons. One develop ogles2.libary (which based on warp3d), and another develop warp3d (in where shaders compiler placed). First one fast on responce and stuff, second one not so :(

[kas1e]

Maybe for begining trying to put some dummy value to "ss =" , like "ss = 1" .. as it look like string which may cause issue ..

[ptitSeb]

Just comment, like sprintf(buff, "//ss = (nVP>0. && lVP>0.)?(%s%d.specular.xyz):vec3(0.);\n", fm_specular, i); that would be the simpler...

[ptitSeb]

That makes a lots of emulation/translations layer when you look at it!

Program ---OpenGL---> GL4ES ---GLES2--->OGLES2 driver---whatever it is--->Warp3D-->Hardware

[kas1e]

Yeah :) But works fast enough already :)

Checked commenting out stuff, and , if i just comment out line 354 , then no crash, but no crash because shader fail, and nothing renders:

[quote] glGetShaderInfoLog(256, 1000, 0x0, 0x6c3ab568) LIBGL: FPE Vertex shader compile failed: ERROR: Code generation failed. Error log: INTERNAL ERROR: Variable is missing its CGVars: 117: OpLoad: FloatVector3: tmp117 << aa INTERNAL ERROR: I/FAdd instruction's source parameters are missing INTERNAL ERROR: I/FAdd instruction's source parameters are missing INTERNAL ERROR: (Vector/Matrix)TimesScalar instruction's source parameters are missing INTERNAL ERROR: I/FAdd instruction's source parameters are missing INTERNAL ERROR: Dot instruction's source parameters are missing INTERNAL ERROR: Store instruction's source parameter is incomplete: OpStore: : tmp127 >> Color [/quote]

[ptitSeb]

Mmmm, then maybe you have to affect a bummy value indeed: try: sprintf(buff, "aa = 1.0;//%s.xyz * _gl4es_LightSource_%d.ambient.xyz;\n", fm_ambient, i);

[kas1e]

With that one fail as well:

ERROR: 76:1: 'assign' : cannot convert from ' const float' to ' temp highp 3-component vector of float'

[ptitSeb]

Ah oops, yes, aa, dd and ss are all vec3 (it's the 3 componant of the light/material interaction: ambient, diffuse and specular, and all are a color) so use sprintf(buff, "aa = vec3(1.0);//%s.xyz * _gl4es_LightSource_%d.ambient.xyz;\n", fm_ambient, i);

[kas1e]

Ok, results:

making dummy line 354 (aa) - didn't help, same lockup making dummy line 354(aa) and line 372(dd) - didn't help, same lockup

so, then i make dummy line 391 (ss) , together with previous 2 : and lockup gone !

Now will try to play with any of them to be original one, and others 2 dummy

[kas1e]

So, only original "aa =" is ok , "dd =" and "ss =" , both cause lockup if they not dummy but originals (together , or per one, does not matter).

[kas1e]

Probably our shaders dind't like those "?" constructs seems so .. Is there any fast way we can check if it the cause ? I mean somehow rephrase those strings, without having "?" in them ?