Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
82 user(s) are online (66 user(s) are browsing Forums)

Members: 0
Guests: 82

more...

Support us!

Headlines

Recent files - OS4Depot - Your one stop for AmigaOS4 files





« 1 (2) 3 4 5 ... 38 »


Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 11:08   #21
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 435
@kas1e
Quote:
did you recieve reports on mail about glGetActiveUniform(...) and glGetActiveAttrib(...)?

Just saw them now. Yes, most likely you found two (well, most likely it's just one) bug in ogles2.library. I'll see that I fix it now!

p.s.: sorry, forget my normal-problem talk from before. Obviously my quick look was too quick You are calling glNormal and not glNormalPointer, so it's all good with the code in that area.


Edited by Daytona675x on 2018/2/18 11:28:03
_________________
[Facebook] [YouTube Channel] [Atomic Bomberman Discord]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 11:56   #22
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 435
@kas1e & ogles2.lib testers

Just fixed a bug with ogles2.library regarding glGetActiveUniform / glGetActiveAttrib:
A bug in the variable info translator Nova -> GLES2 caused malfunction of those. The returned size was in bytes instead of logical units and for glGetActiveUniform the returned type was most often 0.
Update is on my ftp (and in your mail, kas1e )


However, regarding the freeze for that other example:
no idea so far, not even if it's ogles2 related or not. Have to dig deeper for that one.
_________________
[Facebook] [YouTube Channel] [Atomic Bomberman Discord]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 12:54   #23
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Daytona675x

Thanks a bunch, all works !

As for crash issue: yeah, something heavy happens there ..

I just tried in the DrawBox() function exit after 3 loops (so to be able to save debug log until total lockup happens):

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]);
}
}


As well as enabled most of logging in GL4ES, and that what i have in output (maybe also interesting to see loggin of GL4ES):

http://kas1e.mikendezign.com/aos4/gl4 ... es_crash_try_to_debug.txt

That is for this src:
http://kas1e.mikendezign.com/aos4/gl4 ... l4es_crash_try_to_debug.c


Once program exit after 3 loops, after 2-3 seconds whole machine lockup. And i mean heavy lockup, no soft-reboot possible. Like some heavy trash of memory somewhere or so ..
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 13:05   #24
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 435
@kas1e

The only thing that pops to my mind is that you are using GL_UNSIGNED_INT for indices.
While ogles2.lib was just enhanced to support that, maybe gl4es does not? Looking at the log it ultimately issues a glDrawElements-call with GL_UNSIGNED_SHORT indices.
So maybe it creates wrong indices when doing the conversion it obviously has to do.
Change your test prog to use GLushort / GL_UNSIGNED_SHORT indices please.

Other than that: maybe Nova doesn't like the created shaders. In the past sth. like that could easily result in a freeze.
_________________
[Facebook] [YouTube Channel] [Atomic Bomberman Discord]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 13:07   #25
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Daytona675x

Probably found an issue, i send details on mail.

edit: as for GL_UNSIGNED_INT in GL4ES, they fine in, as we do check that example on Pandora with GL4ES and it works. Also those new shaders generated for that example works too (checked them both with glslangvalidator convet to spvs, and then w3dshaderinfo on them). So probably it's all about those details i send you on mail.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 13:51   #26
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 435
@kas1e
Yes, the issue apparently is that ogles2.lib has trouble with the uniform structs in the shaders (which is not really a surprise because there's no support for those inside yet).
On it, but it's unlikely that this is going to be added in such a short time as fix from above
So I suggest you do sth. more useful with this Sunday until you got mail from me

EDIT: just put an test lib update (1.19)on the ftp which
- should behave as before for stuff that worked as before.
- supports structs (also nested). So sth. like this "works for me" TM

// GLSL:
struct MyStruct {
  vec4 a;
  vec4 b;
};
uniform MyStruct x;

// C/C++
GLint loc=glGetUniformLocation(prog,"x.a");
glUniform4f(loc,1.0f,0.0f,0.0f,0.0f);


With a modified boing-test it works fine, but your test-app still crashs, reason unknown to me.


Edited by Daytona675x on 2018/2/18 20:26:10
Edited by Daytona675x on 2018/2/18 20:27:19
_________________
[Facebook] [YouTube Channel] [Atomic Bomberman Discord]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 23:25   #27
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Great progress! It's awesome to see things moving forward.

Quote:
Once program exit after 3 loops, after 2-3 seconds whole machine lockup. And i mean heavy lockup, no soft-reboot possible. Like some heavy trash of memory somewhere or so ..

Yes, trashing memory it doesn't own is a likely culprit.

It's interesting that it's only happening after exit. Perhaps you need an aglDestroyContext() call before the IIntuition->CloseWindow() to make sure that happens first...

Hans
_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/18 23:51   #28
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Hans
At moment fighting with shaders problems.

While GL4ES didn't use arrays in shaders, they use structs. So glGetUniform will get not whole structs, but elements. Daniel add today that support to olges2.library, and from all tests its all looks correct. At least from his own tests and from GL4ES output all looks correct.

But then what problem we have now: Once in my test-crash code we have disable lighting (glEnable(GL_LIGHTING) ), then all works, shaders simple and clean.

Once we enable it back (lighting i mean), shaders generates more heavy. Have a look at this:

Vertex one

#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 one:

#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;
}



Now, is lockups all the time if we have in shader lines about "ss =" and about "dd =".

I.e. if i put there simple dummy, like ss = vec3(1.0) and dd = vec3(1.0), then code didn't lockup. But draw not correctly.

We think that it can be firstly because of that "?" thing in those strings, so we replace them on:

(don't see on the %s%d things, its from generator which use sprintfs, so there in final shader correct values of course).

if(nVP>0.) dd=(nVP * %s%d.diffuse.xyz); else dd=vec3(0.);

and

if(nVP>0. && lVP>0.) ss=(%s%d.specular.xyz); else ss=vec3(0.);

Still same lockup.

Then we get rid of "else" as well, like this:

dd=vec3(0.0);
if(nVP>0.) dd=(nVP * %s%d.diffuse.xyz);

and

ss=vec3(0.0);
if(nVP>0. && lVP>0.) ss=(%s%d.specular.xyz);


And still the same lockup.


So we now at this point, and do not know what to do next. Its is looks very much like shaders issue..

Of course those shaders works on linux, pandora, android and all the other things where GL4ES works.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/19 2:05   #29
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:
...So we now at this point, and do not know what to do next. Its is looks very much like shaders issue..

Anything in the OS debug log? For example, GPU timeouts or a crash log?

Before I start looking for a shader compiler bug, I'd like to know that it actually gets that far. As in, is the shader being compiled successfully all the way through to Warp3D Nova? Or, is something failing beforehand? For example, it's a larger shader and the lines in question are rather long. Is the buffer that the shader is sprintf()'ing to big enough?

The shader compiler's if/else functionality is fairly well tested, and those if/else sections are pretty basic. Plus, the vertex shader compiles just fine when I do it manually.

Hans
_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/19 7:48   #30
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Hans
The output log from GL4ES looks good enough:

http://kas1e.mikendezign.com/aos4/gl4 ... s/fixed_structs_debug.txt

There i just doing 3 loops of drawing, and then exit (so to be able to save output before total lockup happens). Once i exit from , after few seconds lockup of machine happens. I do exit just to be able to save some output (didn't have seria connected at moment), as if i don't it crashes on 4st loop.

Yes, shader compiles just fine manually, and even it compiles fine from gl4es (you may see in output, that code even pass "3 whole loops" with loaded-shaders). Just then, after, lockup.

Today for one more test we remove completly the "if", and, while rendering of course not correct, it works and didn't crashes. I.e. if we do just:

dd = vec3(0.0);
dd =(nVP * gl4es_Color.xyz *_gl4es_LightSource_0.diffuse.xyz);

and

ss = vec3(0.0);
ss = (_gl4es_FrontLightProduct_0.specular.xyz);

Then no crash.

But if we do as i say previously even just:

dd=vec3(0.0);
if(nVP>0.) dd = (nVP * gl4es_Color.xyz *_gl4es_LightSource_0.diffuse.xyz);

ss=vec3(0.0);
if(nVP>0. && lVP>0.) ss = (_gl4es_FrontLightProduct_0.specular.xyz);

I.e. just adding "ifs" with those (nVP>0.), then after few loops of drawing total lockup of machine. No crashlog, not output, just hardcore heavy lockup.

I will try today to attach serial cable , to see, maybe something dumps on serial.


Edited by kas1e on 2018/2/19 8:23:54
Edited by kas1e on 2018/2/19 8:25:16
Edited by kas1e on 2018/2/19 8:52:51
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/19 8:47   #31
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 435
@kas1e
Glad that struct support works well now
I also asked Entwickler-X to test the new lib (quite some messy changes under the hood) with their very complex game projects: no issues, phew

@Hans
Quote:
Perhaps you need an aglDestroyContext() call before the IIntuition->CloseWindow() to make sure that happens first...

You don't need to close the window / invoke window closure with this example. Any desktop activity like clicking anywhere or moving the window will freeze the system here with that test-prog. It is not bound to window closure or so.

Btw. for ogles2 it doesn't matter if you forget the aglDestoyContext or put it behind the CloseWindow here; it won't touch the invalid window anymore, also not during auto-destruction of any active contexts on lib-close.
Of course using it in the correct order is recommended nevertheless ;)

Quote:
The shader compiler's if/else functionality is fairly well tested, and those if/else sections are pretty basic. Plus, the vertex shader compiles just fine when I do it manually.


I once had similar freezes with if / else in MGLReloaded (which uses Nova directly). However, back then it was an unnecessary if / else which I optimized away anyway. Apparently it also depended on overall code-structure, another if / else at a different place would work.
The defunct shaders always compiled / linked fine for me too, of course. Which is why I told kas1e to try to temporarily get rid of the ? : construct and see if that helps when he sent me those shaders.
_________________
[Facebook] [YouTube Channel] [Atomic Bomberman Discord]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/19 8:59   #32
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Daniel

Yeah , from logs everything about structs looks good :) Thanks !


I know i may ask too much (as i can do it myself after some learning of direct GLES programming), but for me it may take few days , so maybe for you it will be less problematic to cookie up a GLES2 example, which take those 2 shaders which i send you, and then doing with them analogue i do in GL example ? (i.e. rotate+lighting).

So to see if it will lockup or not, to exclude GL4ES. Just exacly those 2 shaders with "ifs/else" etc so we can experiment without GL4ES.

Sure if out of time for, i will do so myself :)

We can probably take last output:
http://kas1e.mikendezign.com/aos4/gl4 ... s/fixed_structs_debug.txt

To cookie up GLES example to do the same , in same order, etc


@Hans

I also recive answer from gl4es developer:

Quote:

buff is a 1024 characters buffer, so no buffer overflow here. This code has been tested a lot, also using valgrind on linux, I'm pretty sure there is no buffer overflow.

Also, the issue is not at compile time it seems, but really at run time, with some corruption happening at run time.


Maybe it's the combination of vec3 and if .. Testing


Edited by kas1e on 2018/2/19 9:32:10
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/19 10:36   #33
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 435
@kas1e
I won't have time until tonight, I guess. Drop me a note please if you came up with a test-bed by yourself in the meantime.
However, considering this

Quote:

dd = vec3(0.0);
dd =(nVP * gl4es_Color.xyz *_gl4es_LightSource_0.diffuse.xyz);

and

ss = vec3(0.0);
ss = (_gl4es_FrontLightProduct_0.specular.xyz);

Then no crash.

I'd say that it's pretty clear that the problem is inside Nova and related to if/else ?: just as we guessed. If that would crash too then a faulty DBO setup by ogles2 would probably have been a candidate too, but since it doesn't crash when removing the if/else construct only...
_________________
[Facebook] [YouTube Channel] [Atomic Bomberman Discord]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/19 12:43   #34
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Daytona675x
Quote:

I'd say that it's pretty clear that the problem is inside Nova and related to if/else ?: just as we guessed. If that would crash too then a faulty DBO setup by ogles2 would probably have been a candidate too, but since it doesn't crash when removing the if/else construct only...


We tried now even with just simple IF without ternary operation, i.e.:

Quote:

spot=0.0;
if(nVP>0.) spot=1.0;
dd=(nVP * _gl4es_Color.xyz * _gl4es_LightSource_0.diffuse.xyz)*spot;


and

Quote:

spot=0.0;
if(nVP>0. && lVP>0.) spot=1.0;
ss=(_gl4es_FrontLightProduct_0.specular.xyz)*spot;


Crashes the same !

Once we remove "if" , i.e.:


Quote:

spot=0.0;
dd=(nVP * _gl4es_Color.xyz * _gl4es_LightSource_0.diffuse.xyz)*spot;


and

Quote:

spot=0.0;
ss=(_gl4es_FrontLightProduct_0.specular.xyz)*spot;


Then all works, cube rotates , all fine.

@Hans

So. If we take that vertex shader as reference:

Once we have IF's in those lines -> crash.
Once we use "?" as ternary operation (which probably, share the same code of shader's compiler as "if" ?) -> crash.
Only "?" or only "if" -> crash (if it share same code, then no surprise).

When no "if" or "?" then no crashes and all works. We can put at this place anything we want to play with, just not IF/?.


Edited by kas1e on 2018/2/19 13:02:56
Edited by kas1e on 2018/2/19 13:10:40
Edited by kas1e on 2018/2/19 13:11:42
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/20 1:06   #35
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:

So. If we take that vertex shader as reference:

Once we have IF's in those lines -> crash.
Once we use "?" as ternary operation (which probably, share the same code of shader's compiler as "if" ?) -> crash.
Only "?" or only "if" -> crash (if it share same code, then no surprise).

When no "if" or "?" then no crashes and all works. We can put at this place anything we want to play with, just not IF/?.


I repeat: anything in the OS debug log? For example, GPU timeouts or a crash log?

The if/else blocks in that shader are pretty simple (the ? operator is translated to if/else), and the disassembled code looks good. I've already got >= 13 tests covering various if/else use-cases, so it's likely to be some obscure issue. Without additional information I'd just be taking wild stabs in the dark.

@Daytona675x
Quote:
I once had similar freezes with if / else in MGLReloaded (which uses Nova directly).

Do you still have the code? And any additional debug info?

Hans
_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/20 7:22   #36
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Hans
Quote:

I repeat: anything in the OS debug log? For example, GPU timeouts or a crash log?


No debug logs, no crashes, pure solid lockup. I will try to attach serial cable and check, if there is anything in.

Quote:

(the ? operator is translated to if/else),


Good, then its explain why it died the same for "if" and for "?".

Quote:

I've already got >= 13 tests covering various if/else use-cases, so it's likely to be some obscure issue.


At least if me and Daniel meet with, then not so obscure :) In meantime will try to cookie up pure GLES2 code which load that shader and lockup on runtime.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/20 10:07   #37
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:

No debug logs, no crashes, pure solid lockup. I will try to attach serial cable and check, if there is anything in.

Thanks. I'll await the serial log and simple test case. Hopefully there's something in there that can tell me what's going on. The last thing I need right now is another (obscure ) needle in a haystack search.

No surprises that you can't capture anything without a serial cable.

Hans
_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/20 12:50   #38
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 435
@Hans

Quote:
I've already got >= 13 tests covering various if/else use-cases, so it's likely to be some obscure issue.

Hehehe, the famous last words of every programmer, including me, of course
Or as I prefer to say: "it works for me TM"

However, here is a simple freezing vertex-shader example.
With "if" it freezes. Without it works.
I think it can't be more minimal and obvious.

attribute vec4 vPosition;
uniform float freezer;
void main()
{
   gl_Position = vPosition;
   // use the following line to experience a Nova freeze
   // if(freezer>0.0)
   gl_Position.x +=freezer;
}


Here's an archive with two exes with the respective variants plus source (sorry, ugly, my std. messy modified mini test).

EDIT:
Digged out my serial cable and this is what I get if I wait a couple of seconds before doing a hard reset:

RadeonHD.chip (0): wait for 8 fifo entries failed (5 available).
Status:
RadeonHD.chip (0): GRBM_STATUS: 0xA01014A5
RadeonHD.chip (0):      FIFO_AVAIL: 5
RadeonHD.chip (0):      SRBM_RQ_PENDING_bit
RadeonHD.chip (0):      CF_RQ_PENDING_bit
RadeonHD.chip (0):      GRBM_EE_BUSY_bit
RadeonHD.chip (0):      DB03_CLEAN_bit
RadeonHD.chip (0):      SX_BUSY_bit
RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit
RadeonHD.chip (0):      GUI_ACTIVE_bit
RadeonHD.chip (0):
RadeonHD.chip (0): GRBM_STATUS2: 0x04000002
RadeonHD.chip (0):      SMX_CLEAN_bit
RadeonHD.chip (0):
RadeonHD.chip (0): SRBM_STATUS: 0x200000C0
RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): TC_STATUS: 0x00000000
RadeonHD.chip (0): TD0_STATUS: 0x00000000
RadeonHD.chip (0): TA0_STATUS: 0x00000000
RadeonHD.chip (0): TA1_STATUS: 0x00000000
RadeonHD.chip (0): TA2_STATUS: 0x00000000
RadeonHD.chip (0): TA3_STATUS: 0x00000000
RadeonHD.chip (0): wait idle failed. Status:
RadeonHD.chip (0): GRBM_STATUS: 0xA01014A5
RadeonHD.chip (0):      FIFO_AVAIL: 5
RadeonHD.chip (0):      SRBM_RQ_PENDING_bit
RadeonHD.chip (0):      CF_RQ_PENDING_bit
RadeonHD.chip (0):      GRBM_EE_BUSY_bit
RadeonHD.chip (0):      DB03_CLEAN_bit
RadeonHD.chip (0):      SX_BUSY_bit
RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit
RadeonHD.chip (0):      GUI_ACTIVE_bit
RadeonHD.chip (0):
RadeonHD.chip (0): GRBM_STATUS2: 0x04000002
RadeonHD.chip (0):      SMX_CLEAN_bit
RadeonHD.chip (0):
RadeonHD.chip (0): SRBM_STATUS: 0x20000AC0
RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): TC_STATUS: 0x00000000
RadeonHD.chip (0): TD0_STATUS: 0x00000000
RadeonHD.chip (0): TA0_STATUS: 0x00000000
RadeonHD.chip (0): TA1_STATUS: 0x00000000
RadeonHD.chip (0): TA2_STATUS: 0x00000000
RadeonHD.chip (0): TA3_STATUS: 0x00000000


When using the no-if-no-freeze shader variant then nothing is put on the serial.

RadeonHD.chip version 1.17
Warp3DNova.library version 1.43
Those are the latest versions I got from Matthew. If you have newer ones, please mail them to me.

Cheers,
Daniel


Edited by Daytona675x on 2018/2/20 14:02:18
Edited by Daytona675x on 2018/2/20 14:03:04
Edited by Daytona675x on 2018/2/20 14:17:21
_________________
[Facebook] [YouTube Channel] [Atomic Bomberman Discord]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/20 15:12   #39
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6819
@Daniel
Checked you test arhive, right, everything as you say.

@Hans
Is info Daniel provide enough to fix issue ?

All i can add to Daniel's info, is that my tests done on:

RadeonHD.chip 3.4 (12/28/2017)
Warp3DNova.library 1.43 (08/03/2017)

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

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Posted on: 2018/2/20 15:42   #40
Just popping in
Joined:
2017/5/18 11:12
From Audruicq, France
Posts: 85
Hello,

Here the debug log from my system (A1X1000 - R9 280X- RadeonHD.chip 2.22 - Warp3DNova.library 1.43), using the test "Freezing" demo from Daniel.

RadeonHD.chip (0): wait for 8 fifo entries failed (5 available).
Status:
RadeonHD.chip (0): GRBM_STATUS: 0xA01014A5
RadeonHD.chip (0):      FIFO_AVAIL: 5
RadeonHD.chip (0):      SRBM_RQ_PENDING_bit
RadeonHD.chip (0):      CF_RQ_PENDING_bit
RadeonHD.chip (0):      GRBM_EE_BUSY_bit
RadeonHD.chip (0):      DB03_CLEAN_bit
RadeonHD.chip (0):      SX_BUSY_bit
RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit
RadeonHD.chip (0):      GUI_ACTIVE_bit
RadeonHD.chip (0):
RadeonHD.chip (0): GRBM_STATUS2: 0x00000002
RadeonHD.chip (0):      SMX_CLEAN_bit
RadeonHD.chip (0):
RadeonHD.chip (0): SRBM_STATUS: 0x200000C0
RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): TC_STATUS: 0x00000000
RadeonHD.chip (0): TD0_STATUS: 0x00000000
RadeonHD.chip (0): TA0_STATUS: 0x00000000
RadeonHD.chip (0): TA1_STATUS: 0x00000000
RadeonHD.chip (0): TA2_STATUS: 0x00000000
RadeonHD.chip (0): TA3_STATUS: 0x00000000
RadeonHD.chip (0): wait idle failed. Status:
RadeonHD.chip (0): GRBM_STATUS: 0xA01014A5
RadeonHD.chip (0):      FIFO_AVAIL: 5
RadeonHD.chip (0):      SRBM_RQ_PENDING_bit
RadeonHD.chip (0):      CF_RQ_PENDING_bit
RadeonHD.chip (0):      GRBM_EE_BUSY_bit
RadeonHD.chip (0):      DB03_CLEAN_bit
RadeonHD.chip (0):      SX_BUSY_bit
RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit
RadeonHD.chip (0):      GUI_ACTIVE_bit
RadeonHD.chip (0):
RadeonHD.chip (0): GRBM_STATUS2: 0x00000002
RadeonHD.chip (0):      SMX_CLEAN_bit
RadeonHD.chip (0):
RadeonHD.chip (0): SRBM_STATUS: 0x200000C0
RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): TC_STATUS: 0x00000000
RadeonHD.chip (0): TD0_STATUS: 0x00000000
RadeonHD.chip (0): TA0_STATUS: 0x00000000
RadeonHD.chip (0): TA1_STATUS: 0x00000000
RadeonHD.chip (0): TA2_STATUS: 0x00000000
RadeonHD.chip (0): TA3_STATUS: 0x00000000
RadeonHD.chip (0): wait for 8 fifo entries failed (7 available).
Status:
RadeonHD.chip (0): GRBM_STATUS: 0xA00030A7
RadeonHD.chip (0):      FIFO_AVAIL: 7
RadeonHD.chip (0):      SRBM_RQ_PENDING_bit
RadeonHD.chip (0):      CF_RQ_PENDING_bit
RadeonHD.chip (0):      DB03_CLEAN_bit
RadeonHD.chip (0):      CB03_CLEAN_bit
RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit
RadeonHD.chip (0):      GUI_ACTIVE_bit
RadeonHD.chip (0):
RadeonHD.chip (0): GRBM_STATUS2: 0x00000006
RadeonHD.chip (0):      GRBM_STATUS2
RadeonHD.chip (0):      SMX_CLEAN_bit
RadeonHD.chip (0):
RadeonHD.chip (0): SRBM_STATUS: 0x200000C0
RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): TC_STATUS: 0x00000000
RadeonHD.chip (0): TD0_STATUS: 0x00000000
RadeonHD.chip (0): TA0_STATUS: 0x00000000
RadeonHD.chip (0): TA1_STATUS: 0x00000000
RadeonHD.chip (0): TA2_STATUS: 0x00000000
RadeonHD.chip (0): TA3_STATUS: 0x00000000
RadeonHD.chip (0): wait idle failed. Status:
RadeonHD.chip (0): GRBM_STATUS: 0xA00030A7
RadeonHD.chip (0):      FIFO_AVAIL: 7
RadeonHD.chip (0):      SRBM_RQ_PENDING_bit
RadeonHD.chip (0):      CF_RQ_PENDING_bit
RadeonHD.chip (0):      DB03_CLEAN_bit
RadeonHD.chip (0):      CB03_CLEAN_bit
RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit
RadeonHD.chip (0):      GUI_ACTIVE_bit
RadeonHD.chip (0):
RadeonHD.chip (0): GRBM_STATUS2: 0x00000006
RadeonHD.chip (0):      GRBM_STATUS2
RadeonHD.chip (0):      SMX_CLEAN_bit
RadeonHD.chip (0):
RadeonHD.chip (0): SRBM_STATUS: 0x200000C0
RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000
RadeonHD.chip (0): TC_STATUS: 0x00000000
RadeonHD.chip (0): TD0_STATUS: 0x00000000
RadeonHD.chip (0): TA0_STATUS: 0x00000000
RadeonHD.chip (0): TA1_STATUS: 0x00000000
RadeonHD.chip (0): TA2_STATUS: 0x00000000
RadeonHD.chip (0): TA3_STATUS: 0x00000000

Regards,
Petrol
   Report Go to top


« 1 (2) 3 4 5 ... 38 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project