Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
109 user(s) are online (46 user(s) are browsing Forums)

Members: 0
Guests: 109

more...

Headlines

 
  Register To Post  

« 1 ... 30 31 32 (33) 34 35 36 ... 42 »
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
About that lighting bug, maybe it can be seen from another side: there is another differences related to lighting visually, maybe it all have the same roots.

So, if i fully remove lighting code in both shaders, then that how it looks like for

amigaos4:

(open in new tab for fullsize):

Resized Image

win32/opengl , pandora/gl4es:

Resized Image

So, the same at this point without lighting code. That mean that other parts of shader not related to issue i will show now.

Now, there is how looks like shaders "as it", without anything changed, with full lighting code in shaders enabled:

amigaos4:

Resized Image


win32/opengl , pandora/gl4es:

Resized Image

See, on amigaos4 its not only start to be "darker" in whole (and also have that "black" effect as i show on video), but also if you check how looks like "Tanks", you can see they also have issues like "overlighting". Some lines of tanks even not visibly.

To see that issue more better, i set that g_ambdiffspec to vec4(1.0) again (i.e. that how we get rid of black areas before), so its no more "dark" , and you can see how tanks looks like now : they looks like lighting code fully disabled:

Resized Image

Probabaly it's all the same roots , but maybe from this point of view it will bring more ideas about.

As you can see, with fully enabled lighting code, we have bunch of issues :

1). everything black when hit enemy as we discuss before
2). too dark in whole
3). tanks (and other enimies of course, and probabaly some textures too) do have overlighting or something, so some parts (black ones ?) just didn't visibly: probably boscage also a little bit overlighted.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

There are two possibilities:
1. A shader compiler bug
2. Corrupt lighting input data

Could you check what happens to the value of g_ActiveLights? This is on a hunch that something blowing up adds an extra light, and that light's data is corrupt. For example, if the explosion's light value happened to be huge and negative, then that would cause the effect we see.

Hans


P.S., Yes, I'm pretty sure that the waves disappearing is caused by the cos() instruction not handling large values. Simple test cases are welcome, though.

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
Quote:

There are two possibilities:
1. A shader compiler bug
2. Corrupt lighting input data


If it was corrypt lighting input data, it should then fail (probabaly) and on gl4es/pandora and on win32/opengl.

Quote:

Could you check what happens to the value of g_ActiveLights?


Yeah.

With original shaders (i.e. when it show us those 3 issues on amigaos4 only) when i just start a game or level (so when everything have too-dark bug), then gl_ActiveLights are "1". The same as if i made shader be with g_ambdiffspec to vec4(1.0), then everything is not too-dark, but gl_ActiveLights value still 1 in both cases, so at least that bug 100% not because of corrupted gl_activelights

Then, when i see enimies, then values start vary, from 1 to 5. When i hit the enemty and have all black screen, values didn't changes much, same 1,2,3,4,5. Not bigger, and not negative. And that the same and with original shader, and when we do g_ambdiffspec be vec4(1.0).

Quote:

This is on a hunch that something blowing up adds an extra light, and that light's data is corrupt. For example, if the explosion's light value happened to be huge and negative, then that would cause the effect we see.


If it was it, it can only explain that one bug, but it didn't explain why everything is too dark (always, just from starting the game), and that textures of enemies overlighted or over-something, as i show on screenshots (that always too, not when i hit them).

Anyway, as gl_ActiveLights as values are small ones, and not negative, its in end probabaly compiler shader bug. Question is how to find out where and why so you can fix it..

Have any more ideas ?:)

Quote:

Yes, I'm pretty sure that the waves disappearing is caused by the cos() instruction not handling large values. Simple test cases are welcome, though.


Done:
http://www.amiga.org/developer/bugreports/view.php?id=427


Through as i suck in shader's programming, i can't create simple test case. But i put relevant fragment shader part to the ticket, so you with your knowledge for sure will be able to made simple test case fast, it if there will be needs. But probabaly internally you can check somehow what happens with cos() anyway faster than creating test case.


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
If it was corrypt lighting input data, it should then fail (probabaly) and on gl4es/pandora and on win32/opengl.

Not if the reason for the corrupt data is Amiga-specific (e.g., GLES2 lib bug). The shaders in question use an old variant of GLSL with predefined light uniforms (the gl_LightSource struct array), which modern GLSL doesn't use any more. Fricking shark is probably one of the few programs to use those so far on AmigaOS, and it's entirely possible that there's an issue with them.

Quote:
Then, when i see enimies, then values start vary, from 1 to 5. When i hit the enemty and have all black screen, values didn't changes much, same 1,2,3,4,5. Not bigger, and not negative. And that the same and with original shader, and when we do g_ambdiffspec be vec4(1.0).

What do you mean by "didn't change much?" Does it change at that instant or not? Being in the range of 1-5 doesn't clarify anything.

Quote:
Have any more ideas ?:)

Yes, find out what changes occur with the lights when something is hit. Which light(s) change? Which values change? Knowing what the game is doing with the lights should help track down where it's failing.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
Quote:

What do you mean by "didn't change much?" Does it change at that instant or not? Being in the range of 1-5 doesn't clarify anything.


Retested again : when you just fly in the level gl_ActiveLights are 1. Once you hit the tank, gl_ActiveLights are 2. Once you hit the paraplane, gl_ActiveLights are 2 sometime 3.

Do you think its better to concetrate on that lighting bug when enemies hits, and not on others 2: "why whole game is too dark with lighting shader" and "why look of textures overlighted" ? At least bug with hit happens only when hit, while other two there always (can be a little bit easer to debug maybe?)



Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
Retested again : when you just fly in the level gl_ActiveLights are 1. Once you hit the tank, gl_ActiveLights are 2. Once you hit the paraplane, gl_ActiveLights are 2 sometime 3.

Interesting. What happens if you lock gl_ActiveLights to 1? Is there a way for you to print out the values that the lights are set to?

Quote:
Do you think its better to concetrate on that lighting bug when enemies hits, and not on others 2: "why whole game is too dark with lighting shader" and "why look of textures overlighted" ? At least bug with hit happens only when hit, while other two there always (can be a little bit easer to debug maybe?)

Yes, that one's likely to be easier to track down, because it happens under specific circumstances. Hopefully the other two are related, but we can deal with that later.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
Quote:

Interesting. What happens if you lock gl_ActiveLights to 1?


If i catch all cases when gl_ActiveLights is more than 1, and then set it to 1 before calling adduniform(), then bug with "all black when hit" disappeared !


Quote:

Is there a way for you to print out the values that the lights are set to?


As far as i can see there is only one uniform in shader about lighting (that gl_ActiveLights), so that one i can printf easy from source code of game, but other ones you mean probabaly shaders values, and they probabaly very hard to print. I remember reading in google that its all hard, and ppls only somehow print it like "drawing on screen", etc.


EDIT: oh, and that i notice now, its probabaly another issue with lighting. Originally, when shaders works as expected, when you hit enemy, everything around have some lighting effect, which we didnt' have.

On win32/opengl and on pandora/gl4es, does not matter if you set gl_ActiveLighting to 1 or not for all the time : that effect still here, and visually not much changes. If it 1 for all time, or varies.

Its like, whole lighting dind't work.


Edited by kas1e on 2019/8/13 8:47:08
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Quote:
If i catch all cases when gl_ActiveLights is more than 1, and then set it to 1 before calling adduniform(), then bug with "all black when hit" disappeared !

Okay, so there's definitely a problem with the additional lights. It could still be either corrupt uniform data passed to the GPU, or a shader compiler issue.

Quote:
As far as i can see there is only one uniform in shader about lighting (that gl_ActiveLights), so that one i can printf easy from source code of game, but other ones you mean probabaly shaders values, and they probabaly very hard to print. I remember reading in google that its all hard, and ppls only somehow print it like "drawing on screen", etc.


The lighting parameters that end up in the gl_LightSource array are set via glLightfv(). This is a legacy OpenGL function which GL4ES must somehow process to work with GLES2. For that matter, the raw shaders must be modified before being passed to the GLES2 library to add the legacy gl_LightSource uniform.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
Ok, will go then that way: will remove from original shaders everything which is not light: fog, shadows, water-ripple, etc. Then will strip light functions till small, but which still give on os4 black-when-hit, but on win32/oopengl and pandora/gl4es still not. Then we can continue , but since then will post shaders after gl4es conversion: that indeed will be better than checking original shaders which later convering by gl4es and add/remove/regroup things.

Will take few hours

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

And you say you are "shitty" with shader writing?

I can't even imagine touching this stuff, let alone altering it to a working stripped down test version...

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
So was able to strip the shaders so "black-when-hit" bug still there, and that how looks like shaders which are converted by gl4es and sended to ogles2:

Vertex one:

#version 100
precision highp float;
#define _gl4es_MaxLights 8
precision highp int;
uniform highp mat4 _gl4es_ModelViewMatrix;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
uniform highp mat4 _gl4es_TextureMatrix_0;
uniform highp mat3 _gl4es_NormalMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
attribute highp vec4 _gl4es_MultiTexCoord0;
attribute highp vec3 _gl4es_Normal;
struct _gl4es_LightSourceParameters
{
   
vec4 ambient;
   
vec4 diffuse;
   
vec4 specular;
   
vec4 position;
   
vec4 halfVector;
   
vec3 spotDirection;
   
float spotExponent;
   
float spotCutoff;
   
float spotCosCutoff;
   
float constantAttenuation;
   
float linearAttenuation;
   
float quadraticAttenuation;
};
uniform _gl4es_LightSourceParameters _gl4es_LightSource[_gl4es_MaxLights];
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;
varying lowp vec4 _gl4es_FrontColor;
varying mediump vec4 _gl4es_TexCoord_0;

highp vec4 ftransform() {
 return 
_gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
}


uniform int  g_ActiveLights;
varying vec4 g_EyeVertexPos;

varying vec4 g_ambdiffspec;
varying vec3 g_normal


void PointLight(const in int  i,
                const 
in vec3 ecPosition3,
                const 
in vec3 normal,
                
inout    vec4 ambient,
                
inout    vec4 diffuse,
                
inout    vec4 specular)
{
    
    
float d length(_gl4es_LightSource[i].position.xyz ecPosition3);
    
vec3 L normalize(_gl4es_LightSource[i].position.xyz ecPosition3);
    
float lambertTerm max(dot(normal,L),0.000000);
    
float attenuation 1.000000 / (_gl4es_LightSource[i].constantAttenuation +_gl4es_LightSource[i].linearAttenuation +_gl4es_LightSource[i].quadraticAttenuation d);
    
ambient+= _gl4es_LightSource[i].ambient*lambertTerm attenuation;
    
diffuse +=_gl4es_LightSource[i].diffuse*lambertTermattenuation;
    if(
_gl4es_FrontMaterial.shininess>0.000000)
    {
        
vec3 E normalize(-ecPosition3);
        
vec3 R reflect(-Lnormal);
        
float specularFactor pow(max(dot(RE), 0.000000),_gl4es_FrontMaterial.shininess);
        
specular += _gl4es_LightSource[i].specular *_gl4es_FrontMaterial.specularspecularFactor attenuation;
        
    }
}


void main (void)
{
    
vec4 LocalVertexPos=_gl4es_Vertex;
    
g_EyeVertexPos=_gl4es_ModelViewMatrix LocalVertexPos;


    
g_normal=normalize(_gl4es_NormalMatrix _gl4es_Normal);

    
    
vec4 amb=vec4(0);
    
vec4 diff=vec4(0);
    
vec4 spec=vec4(0);
    
gl_Position ftransform();

    for(
int x=1;x<g_ActiveLights;x++)
    {
        
PointLight(xg_EyeVertexPos.xyzg_normalambdiffspec);
    }
    
g_ambdiffspec=_gl4es_LightModel.ambient+amb+diff+spec*_gl4es_FrontMaterial.specular;

    
    
_gl4es_FrontColor=_gl4es_Color;
    

    
_gl4es_TexCoord_0=_gl4es_TextureMatrix_0*_gl4es_MultiTexCoord0;

}


Fragment one:

#version 100
precision highp float;
precision highp int;
varying lowp vec4 _gl4es_FrontColor;
varying mediump vec4 _gl4es_TexCoord_0;

uniform int  g_ActiveLights;

uniform sampler2D Texture0;

varying vec4 g_ambdiffspec;
varying vec3 g_normal;
    

void main (void
{
         
vec4 texcolor=_gl4es_FrontColor;
         
vec4 finalcolor;
   
  
      
texcolor*= texture2D(Texture0_gl4es_TexCoord_0.xy);

      
vec4 sunamb=vec4(0);
      
vec4 sundiff=vec4(0);
      
vec4 sunspec=vec4(0);
     
      
      
vec3 N=normalize(g_normal);

      
finalcolor.rgb=clamp(g_ambdiffspec.rgb,0.000000,1.500000);
          
finalcolor.rgb*=texcolor.rgb;
          
finalcolor.a=texcolor.a;
  
          
gl_FragColor=finalcolor;
}


As i see, vertex one still have arrays for uniform, and that is exactly that uniform _gl4es_LightSourceParameters _gl4es_LightSource[_gl4es_MaxLights];

So maybe problem still because of uniforms arrays ! It looks just the same as it was before : when all textures was black. And once we get rid of arrays usage there, textures appears to be visibly. Now, there is another uniform arrays, which also give us "black-when-hit", so maybe it's still the same issues ?

I ask ptitSeb, if it for sake of tests possible to get rid of uniform's array usage there , and he say that:

Quote:

Don't forget all those variable are normaly "built-in" in OpenGL, and gl4es already need to track them. Tranforming the array to non-array basically double the work (tracking the array and non-array form). Also, more importantly, on the shader side, you can see the lights array are accessed by variable. It's inside a function called from inside a loop on the number of active lights (look at the PointLight function in the vertex shader). Unrolling that will result in a mess of a shader: that really is difficult, and will not result in the same shader anyway.

Lightning most often needs arrays, because you most of the time have more than 1 light.


What mean, that even if the roots of problem probabaly the same (seems very possible) because of that non-working uniform's arrays, then we can't fast-check-test it, and only can test it when uniform arrays issue will be fixed.

So cross the fingers that Daniel can find the roots , then we can test fistly if all works with arrays, and then we can see how lighting start to works (or not), and how other lighting issues will looks like.

Oh, btw , need to mention, that it's not just an array of uniform, but an array of uniform structure (!) there, so can be probably some other bug with the same "uniform arrays" roots.


Edited by kas1e on 2019/8/13 20:33:53
Edited by kas1e on 2019/8/13 20:47:00
Edited by kas1e on 2019/8/13 20:48:08
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Nice job, we're getting closer to discovering the root cause. It definitely looks like a uniform array of structures problem.

I just checked, and I have a test for uniform arrays of structures. It's a relatively simple one (a single uniform variable with a struct containing 3 floats), though, so there could still be a bug in there.

I agree with ptitSeb that reworking the code to remove the arrays would create a mess. It's not worth the effort.

For now, I can't think of anything else to try to narrow it down further.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans, Capehill

Good news about water-ripple bug effect, while its probabaly the easest bug from all, still ..

So, i was able to create simple test case with _VERY_ simplefied version of ripple-water effect. I grab the Hans tutorial 3 (drawing texture), reduce gl4es shaders very much + adapt them a little as well as adapt main.cpp so it set CurrentTime uniform in a loop, and violla, bug is 100% reproducable on amigaos4 once CurrentValue hit _exactly_ 400. Dunno why 400, but it is.

I firstly create it for win32/opengles(angle) (yeah, that really handy now to test bugs when you have ability to run 1:1 the same code on both win32 and aos4), and there is no such bug of course. Currenttime value increased as much as i wish without problems (i tested till 2000, all fine). While on amigaos4, once 400 is hit: bum, nothing happens, effect stops.

There is archive with test case:

http://kas1e.mikendezign.com/aos4/gl4 ... pple_water_effect_bug.zip


win32(x64 with all .dlls inside) and amigaos4 versions, source code and binaries included. Just unpack, run Effect_bug.exe, and just hold any button when window with texture active: In the shell you will see printouts of currentvlaue (a = xxx , this is that fCurrentTime) , and once it hit 400 effect disappear. On win32 all fine, i test even till 2000.

Shaders in question start to be really small.

Vertex one:

#version 100
precision highp float;
precision highp int;
attribute highp vec4 _gl4es_Vertex;
attribute highp vec4 _gl4es_MultiTexCoord0;
varying mediump vec4 _gl4es_TexCoord_0;
varying lowp vec4 _gl4es_FrontColor;

highp vec4 ftransform() {
 return 
_gl4es_Vertex;
}



void main (void)
{
    
    
_gl4es_TexCoord_0=_gl4es_MultiTexCoord0;
    
gl_Position ftransform();

}


Fragment one:

#version 100
precision highp float;
precision highp int;
varying lowp vec4 _gl4es_FrontColor;
varying mediump vec4 _gl4es_TexCoord_0;

uniform float CurrentRealTime;

uniform sampler2D texSampler;

void ApplyWaterEffect(in sampler2D sampler,in vec2 vCoordsout vec3 color)
{
        
    
vec2 tc vec2(_gl4es_TexCoord_0.x,_gl4es_TexCoord_0.y);    
    
    
float len length(-1.000000 2.000000*tc);
    
float ripplesize=cos((len*3.000000+CurrentRealTime)*4.000000);
    
vec2 uv=tc;
    
uv+=ripplesize*0.030000;

    
    
color.rgb texture2D(sampleruv).xyz;
}

void main (void
{
   
vec4 texcolor=_gl4es_FrontColor;

   
ApplyWaterEffect(texSampler,_gl4es_TexCoord_0.xy,texcolor.xyz);
   
   
gl_FragColortexcolor;

   
}


They can be reduced even more, just effect will a bit more sucky , but for tests its enough for sure.

@Hans
Now its probabaly one of the best bug-reports ! :) Hope you will start to works on nova soon.

ps. will add that testcase to BZ just in case.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
And it's not only cos() , it also sin() behave exactly the same. I.e all fine on win32/opengl(angle) and on pandora/gl4es, but give same issue on aos4. And it also stops on the same currentime value as cos().

I also shorten fragment shader even more, now effect looks wrong of course, but that not matter, what matter that i still can see how cos() or sin() stop working. I remove all * 4, all + and so on, so now function which use cos()/sin() looks just like this:

void ApplyWaterEffect(in sampler2D sampler,in vec2 vCoordsout vec3 color)
{

    
vec2 tc vec2(_gl4es_TexCoord_0.x,_gl4es_TexCoord_0.y);
  
    
vec2 uv=tc+sin(CurrentRealTime);

    
color.rgb texture2D(sampleruv).xyz;
    
}


Now, even with such a small function, once we do 1600 loops, everything stops. For both cos() and sin(). Before it was 400 because in shader's code we multiply it and so on.

Is there anything you can think of , why "1600" exactly are stop factor to broke sin() and cos() ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
I do not know if it worth to report more things about warp3dnova, as nothing from previous got fixed for too long already, even simply ones, taking aside those ones which need to spend more time :( But hope die last, so there is another thing to discuss, maybe not only Hans, but also Daniel or Capehill will bring some ideas about:

So i do port irrlicht engine over gl4es, and while generaly speaking it all works fine, through, its pretty slow in test-cases: its just on the level of some 10 years old notebok with amd 1.6gz and some intel-inbuild-gfx-card. I not sure because of what it all (but knowing that there is no GART support, and that some parts of warp3dnova just have disabled optimisation, and that we have no DMA for x5k in graphics.library, we can skip that till point that all will be fixed/done).

But issue i want to discuss there is more than just "its slow", is that 2 examples which come with Irrlicht behave pretty strange (and only on amigaos4 of course). As main example we can take "12.terrainrendering". That how it looks like (visual and source):

http://irrlicht.sourceforge.net/docu/example012.html

As can be seen nothing hardcore there.

Now, i test it on that old 10 years notebook 1.6ghz , and it give 600fps, with no problems when i move camera, etc.

On amigaos4 it give at best 90 fps only, and when i start move camera, it increasely start to eat memory. At some point it eat up whole 256 mb of video memory and os even freezes or crashes in warp3d_si library

That how it looks like in action:

https://youtu.be/Qhs7iG4BVew

You can see on video , at top, where is small dockies placed, how gfx-ram dockie show filled video ram till maximum.

On pure software rendering it give on 10 years old amd1.6ghz 43 fps, and on amigaos4 34 fps. So kind of on the same level we can say. But in opengl, it just about 40-90fps at maximum, while on that 10 year old amd notebook give ~600fps (!).

Now, i ask ptitSeb to check it on Pandora , he say that all fine, i quote him:

---
Nothing special on the Pandora. Can't really tell the speed, but it's fine. I made a GLES2 capture: the drawing loop is pretty, with only 10 calls per frame! There is just a background "cube map" (well just 6 planes), than the large terrain in 1 drawing command, than the Irrlicht logo, and a last untextured drawing at the end (not sure what it is). The only thing I can see that can have some effect, is that, before that last drawing command, it bind on GL_TEXTURE0 the texture 0 (that is default unattached texture). That a classic way to avoid texture drawing in OpenGL 1.x, you bind Tetxure #0 and disable Texture mapping. So here there is a drawing with a shader that doesn't use texture, with an invalid texture binded. Not sure if this can be the source of the issue you have. But I seriously haven't seen anything wrong in the draw loop.
---

There is pretty pvrlogtracing:

https://user-images.githubusercontent. ... 1e9-90b8-3f3aa5d5d59e.png


So.. I do capture via glSnoop (thanks Capehill we have that important piece of software!) and there results:

profiling only: http://kas1e.mikendezign.com/aos4/irrlicht/eat_memory/profile.txt
full tracing: http://kas1e.mikendezign.com/aos4/irrlicht/eat_memory/tracing.txt

Everything looks fine, but still we have 2 issues on amigaos4

1. All video memory eats when i just move camera with such a simple test-case

2. Its just sloooow. But maybe that because of the issue #1.

Now, any ideas, anyone ?:) I thinking at first that maybe somewhere is "calloc" or "realloc" hides which can cause such kind of issues, but all the other 25 examples (which is more and heave than those ones) didn't have such issues..

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

EDIT: Nope. Got that wrong.
EDIT2: Okay, I don't see a memory leak but there is a gradual enlarging of VBOs, e.g.:

Shell Process '12.TerrainRendering': W3DN_CreateVertexBufferObject: size 320, usage 6, maxArrays 16, tags 0x640326a8. Buffer address 0x66384c18, errCode 0 (W3DNEC_SUCCESS)

then later:

Shell Process '12.TerrainRendering': W3DN_DestroyVertexBufferObject: vertexBuffer 0x66384c18
Shell Process '12.TerrainRendering': W3DN_CreateVertexBufferObject: size 11520, usage 6, maxArrays 16, tags 0x64032858. Buffer address 0x66384c18, errCode 0 (W3DNEC_SUCCESS)

then even later:

Shell Process '12.TerrainRendering': W3DN_DestroyVertexBufferObject: vertexBuffer 0x66384c18
Shell Process '12.TerrainRendering': W3DN_CreateVertexBufferObject: size 2713964, usage 6, maxArrays 16, tags 0x64032688. Buffer address 0x66384c18, errCode 0 (W3DNEC_SUCCESS)

There's a similar pattern with other VBOs. No idea if that's enough to fill VRAM, though.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Hans
There is also what ptitSeb says:

Well, think about it, the terrain in that frame is a large set of almost 29k vertices. That's a big object. What I'm not sure is if the arrays are rebuilt for each frame (to include only triangle that are visible) or if it's the same at each frame. My guess is that's a new very large array at each frame. That means GLES2 will check if that large array is the same as a previous one (not sure how fast this is for large arrays) and then create a VBO with BigEndian->LittleEndian conversion (that will, again, take some time).

Of course that didnt explain eating if memory and THAT slow speed

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Those two examples trigger one of the many performance boosters in ogles2.library without which things would crawl to resize the internal multibuffer's VBOs all to rather huge sizes. I added a simple safety mechanism now to avoid such situations. This quick workaround comes at a rather huge performance penalty (only) for such situations though. I will improve that for the next official ogles2 version.

@Hans
However it's important to note that there is no memory-leak or bug in ogles2.library!
All those allocations are legal, Nova always reports "success". What is causing the crash here is something else, pretty interesting actually:

As being said, all VBO allocations are reported as being successful by Nova. This is true even if the physical gfx memory is already practically fully depleted. The stuff still runs, albeit with a significant slowdown. Something else is causing Nova to freeze the system then, namely a call to DestroyVertexBufferObject. This is what happened in ogles2: when gfx RAM was already in critical areas, yet another VBO was in the process of being resized - which involved its prior destruction before its recreation, bang.
Note that the call to DestroyVertexBufferObject is fully legal and the respective VBO is not in use anywhere or whatever.

So, to sum it up: Nova freezes if you call DestroyVertexBufferObject when gfx RAM is low, at least.

EDIT: filed this as new W3D Nova bug report 0000447.


Edited by Daytona675x on 2019/9/7 10:56:15
Edited by Daytona675x on 2019/9/7 10:58:53
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@All
Ok so, for that example from Irrlicht called TerrainRendering we are done : Daniel add workaround for Nova bug when Nova freezes if you call DestroyVertexBufferObject when gfx RAM is low, as well as he added that safety mechanism to avoid such situations.

But now more news about : PtitSeb add real use of VBO for glBindBuffer() (at this time only for it), so, all the apps/games which use it much, benefit from it. For example, in FrickingShark i got +10fps more (not a lot, but still), but in that TerrainRendering example, it is now 550 fps instead of 50 (!) yeah, in 10 (ten) times faster.

But in case with TerrainRendering example, it was also slow and on Linux with gl4es. So, it was gl4es slow things down this time. But now all Irrlicht examples have on linux with gl4es almost the same speed as on linux with Mesa, so it didn't add as a layer speed issues anymore.

Now, probabaly the last thing i want to understand (and maybe it possible to speed up it somehow) with Irrlicht, is why some Irrlicht examples are 2-3 times slower, than on 10 years old AMD 1.6 ghz with some shity-inbuild gfx card.

To explain it more, we have in Irrlicht few different modes of rendering : OpenGL and Software Rendering.

Now, let's see figures of software rendering , on 3 different machines:


1). notebook icore_i5 2.7ghz + intelHD 620 (win10)
2). notebook AMD e360 1.6ghz with HD 6300m (winxp)
3). X5000 2ghz RadeonHD r7-250 (last aos4)

Software Rendering:
   
   
Example                     icore_i5     AMD e360    X5000
                                                  
02.Quake3Map                     92           28          29
03.CustomSceneNode              283           93          85
04.Movement                     236           72          67
08.SpecialFX                     88           24          30
09.MeshViewer                   121           38          37
10.Shaders                      241           72          74
11.PerPixelLighting              93           29          29
12.TerrainRendering             124           34          34
13.RenderToTexture              193           59          60
15.LoadIrrFile                  176           47          54
16.Quake3MapShader               82           24          23
18.SplitScreen                   56           17          16
20.ManagedLights                231           67          69
26.OcclusionQuery                72           28          26


As we can see, x5000 by hardware specs on the level of 10 years old amd 1.6ghz notebook.

That time, we didn't take in account opengl, or warp3d, or anything of that sort. It is pure software rendering. And only what have impact there , is CPU, graphics.library and radeonHD driver.

Through if think more about it, its probabaly ok. Everyone know that x5000 is 10 years behind of current computer world, so, kind of ok.

Now, taking those results in mind, and knowing that we on the level of amd 1.6ghz , we expect x5000 with opengl rendering be at least on the same level (of course, as we have better gfx card, it is wish to be faster, but its ok to be just on the same level).

And there is table , with OpenGL. The same 3 machines are used:

1). notebook icore_i5 2.7ghz + intelHD 620 (win10)
2). notebook AMD e360 1.6ghz with HD 6300m (winxp)
3). X5000 2ghz RadeonHD r7-250 (last aos4)

But also added there results from icore_i5 (first config) under Linux with MESA, and under linux with GL4ES (so to see that GL4ES is ok, and on the same level as MESA and we can't blame it for some issues i will point out now). Also i added MiniGL results (i was able to made Irrlicht works for MiniGL somehow, which offten crashes with it, have rendering bugs, some example's didn't work either, but it still something to compare with).

So, table:

OpenGL Rendering:

   
Example              icore_i5 (Linux,MESA)    icore_i5 (Linux,GL4ES)   icore_i5 (win10)    AMD e360 (winxp)    X5K (GL4ES)    X5K (MiniGL)

02.Quake3Map                    1182                     1070                   1023               342               152             87
03.CustomSceneNode              3374                     3177                   2671              1316              2462           1576
04.Movement                     2610                     2412                   2071               756              1280            492
08.SpecialFX                    1459                     1359                    911               306               275             55
09.MeshViewer                    834                      841                    887               237               189            165
10.Shaders                      1954                     2005                   1457               658               723        
(no shaders)
11.PerPixelLighting             1328                     1356                   1141               393               452             57
12.TerrainRendering             1625                     1597                   1423               567               570             44
13.RenderToTexture              1932                     1776                   1915               482               709         
(cant start)
15.LoadIrrFile                  2160                     2033                   1835               706               890            522
16.Quake3MapShader               657                      634                    610               170                90             53
18.SplitScreen                   409                      370                    480               110                37             31
20.ManagedLights                1255                     1342                   1290               400               253            265
26.OcclusionQuery               2898                     2618                   2152              1184              1378             61



What we can say there ? For first, MiniGL is suck. Only 2 examples at least on the same speed level (09.MeshViewer and 20.ManagedLights). For others its just too slow indeed.

Next thing we can notice there, that X5000 with GL4ES, with some examples pretty much faster that old AMD notebook (at least that what we expect when we have modern RadeonHD), like 03.CustomSceneNode, 04.Movement and most of them if not on the same level, but a little bit faster there and there.

Issue i see now, is that some examples show pretty degradate results, which i want to discuss and find out why: maybe it will be again possible to speed up somehow/somewhere , or at least we can find WHY.

Examples about which i told are:

02.Quake3Map (slower on 50% than even on 10 years old AMD with shiti intel gfx card)

16. Quake3MapShader (again slower on 50% than 10 years old notebook, but i assume its the same issue as with first example). But with that example, DISABLING of compositing make it be 90 fps, while with ENABLED compositing it is around 60-65 (maybe that will point out on something).

18. SplitScreen (slower in 300% ! Example again load quake3map, and split screen on 4 parts, and rendering happens independent in each).

So those 3 examples probably have the same single issue (i hope), as all of them use quake3map.

And, last one:

20.ManagedLights. That one the same as MiniGL one by speed, nothing changes, so i assume there is that issue with GART this time, or non-dma in graphics.library for x5k.

Now, to have something to discuss, i firstly upload all those 4 examples ready to run, so everyone can try:

http://kas1e.mikendezign.com/aos4/irrlicht/irrlicht_slow_tests.lha

I am in interest if any X1000 user (so with DMA in graphics.library) can run them, and see the maximum fps they have in all of them (FPS is writen in window title). So we can avoid or not avoid that its because of DMA. Quiting from examples can be done via close gadget or via "alt+f4". Run it from directory where they are (bin/amigaos4) as they want root's "media" directory.

Next, i made a tracing/profile for all those 4 examples via today's glsnoop which catch almost everything now (Capehill, thank you very much for that!). Profilings for both warp3dnova and ogles2 are at end of files

02.Quake3Map : trace_profile

16.Quake3MapShader : trace_profile

18.Split screen : trace_profile

20.ManagedLights : trace_profile


So, very wellcome any kind of analysis and we probabaly can understand wtf happen with those examples.

Thanks !

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@All
PtitSeb made a capture of 02.QuakeMap:

(press open in new tab for fullszie):
Resized Image

To be honest, the capture is very clean. Only 27 drawing call in the entire frame! No suspicious state change. Only the bare minimum per drawing call and that's all. And most drawing are using a quite simple shader that do multitexture rendering:
Vertex shader:

#version 100
precision mediump float;
precision mediump int;
uniform highp mat4 _gl4es_ModelViewProjectionMatrix;
attribute highp vec4 _gl4es_Vertex;
attribute lowp vec4 _gl4es_Color;
attribute highp vec4 _gl4es_MultiTexCoord0;
attribute highp vec4 _gl4es_MultiTexCoord1;
// FPE_Shader generated
varying vec4 Color;
varying vec2 _gl4es_TexCoord_0;
varying vec2 _gl4es_TexCoord_1;

void main() {
gl_Position _gl4es_ModelViewProjectionMatrix _gl4es_Vertex;
Color _gl4es_Color;
_gl4es_TexCoord_0 _gl4es_MultiTexCoord0.xy _gl4es_MultiTexCoord0.q;
_gl4es_TexCoord_1 _gl4es_MultiTexCoord1.xy _gl4es_MultiTexCoord1.q;
}


Fragment shader:

#version 100
precision mediump float;
precision mediump int;
// FPE_Shader generated
point=0
varying vec4 Color
;
varying vec2 _gl4es_TexCoord_0;
uniform sampler2D _gl4es_TexSampler_0;
varying vec2 _gl4es_TexCoord_1;
uniform sampler2D _gl4es_TexSampler_1;
uniform float _gl4es_TexEnvRGBScale_1;
void main() {
vec4 fColor Color;
vec4 texColor0 texture2D(_gl4es_TexSampler_0_gl4es_TexCoord_0);
vec4 texColor1 texture2D(_gl4es_TexSampler_1_gl4es_TexCoord_1);
vec4 Arg0Arg1Arg2;
fColor texColor0;
Arg0 texColor1;
Arg1 fColor;
fColor Arg0 Arg1;
fColor.rgb *= _gl4es_TexEnvRGBScale_1;
fColor clamp(fColor0.1.);
gl_FragColor fColor;
}


His first guess was is the time difference is converting from BigEndian to LittleEndian to send the ever changing Vertex Arrays data to the GPU.

But yeah, sure that conversion take place, but it can't take THAT MUCH. I mean, old amd 1.6ghz with some slow intel-gfx card give us ~350fps, and on our setup ~150fps. I can't belive that such a conversion can take that much time. Its probabaly something else ?

Then we checked tracing/profiling logs, and can see that it's the Drawing itself that is the main bottleneck, not the VBO creation/handling it seems (well, it takes some time too, but ok-ish).

And currently run out of ideas. Its a pretty simple things as can be seen from log, through, that a big diffrence bettwen 10 years old amd with shity gfx-card. So something wrong somewhere, and we can't see why and where.


Edited by kas1e on 2019/9/12 22:44:14
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 ... 30 31 32 (33) 34 35 36 ... 42 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project