Irrlicht Engine 1.9 for OpenGLES2 : in progress

@All
Since some years Irrliht engine do have OGLES2 branch, which once things finalized will be released as Irrlicht 1.9.

So far for us it mean that we can try to make it to work directly over ogles2.library, and get rid of GL4ES layer in between.

The problem is that OGLES2 in Irrlich use EGL for context creation, activation, swapbuffers, etc. For us of course it will be better to not have any additional layers, and did the same as it happens to be with pure OpenGL : through SDL.

Why Irrlicht devs going EGL route with context creation , while they still use SDL to create a window, handle events, etc: is unkonwn, maybe for compatibility reassons for win32/x11/android/emscripten/etc. But what we can do for sure it's get rid of it for us and ourself create ogles2 context and use SDL window to render to it.


So to go futher there is relevant files:

EGL Manager (so you can see it just for context creation/destroying/swapbuffers/etc, i.e. minimal stuff with no events and co):

https://sourceforge.net/p/irrlicht/cod ... /Irrlicht/CEGLManager.cpp
https://sourceforge.net/p/irrlicht/cod ... ce/Irrlicht/CEGLManager.h

And there are relevant CIrrDeviceSDL files (i.e. where we init SDL, create a window, etc).:

https://sourceforge.net/p/irrlicht/cod ... rrlicht/CIrrDeviceSDL.cpp
https://sourceforge.net/p/irrlicht/cod ... /Irrlicht/CIrrDeviceSDL.h


As can be seen, since line 483 we have that:



So, createOGLES2Driver is called with passing CreationParams, FileSystem and, our ContextManager, which is EGL one there and we need to replace it on SDL one.

For that, i go the same route as it was with pure OpenGL: comment there all out, and put just one line:



Now, we have COGLES2Driver itself:

https://sourceforge.net/p/irrlicht/cod ... rrlicht/COGLES2Driver.cpp
https://sourceforge.net/p/irrlicht/cod ... /Irrlicht/COGLES2Driver.h

There we also change context manager as it done in case with pure OpenGL. Like it was:



Which one we change that instead of IContextManager* contextManager we do have CIrrDeviceSDL* device, and at the end instead of ContextManager(contextManager) do ContextManager(0) (as in case with pure OpenGL).

And same for createOGLES2Driver:




Now, with SDL we can go 2 ways:

1). Use the same hack as in GL4ES (so instead of MiniGL, we do use OGLES2, but SDL think about it as OpenGL). That also mean that we should call SetVideoModes() with SDL_OPENGL flag being enabled.


2). Second way is that we didn't touch SDL itself, but instead create sdl window via SetVideoModes _without_ SDL_OPENGL flag, so SDL will not involve MiniGL, but instead we in Irrlicht's SDL openwindow() open OGLES2 library, create context, take the intuition window pointer, and call aglMakeCurrent() on it, like this:




So i tried both ways, and have at the moment result of "nothing renders on screen" by the very simple test case.

Through, when i run exampe after those changes, i do have in the shell lots of:

Quote:

So firstly what i do is delete fully media/shaders/ directory, and start to run it to see what shaders it want to use as necessary basis, and there just 3 shaders for:

1 fragment one - COGLES2Renderer2D.fsh :



2 fragment one: COGLES2Renderer2D_noTex.fsh:



And , 3st one, vertex one, called COGLES2Renderer2D.vsh and there this are:



So with only just those 3 shaders in the media/shaders directory, i run the example, and while have lots of "could not open" for other shaders, i didn't have error that i must to have some shader to make fixed pipeline working, and , have now just one single

"GLSL shader program failed to link.".


So, i give it ago all 3 through glslangvalidator (to made SPIRV from them) and then W3DShaderInfo, to see if they compiles by Nova : and they all compiles fine..


I also checked via glSnoop what happens now , and that what i have in output:




So seems we compile there 4 shaders, 2 fragment ones and 2 time strying to compile this vertex one.


And this part make me curious wtf:



It says GL error 1282 (GL_INVALID_OPERATION) firstly, but then says that shader compiles fine ?

I do check also in whole irrlicht sources on "GLSL shader programm failed to link" and found that it come from

https://sourceforge.net/p/irrlicht/cod ... GLES2MaterialRenderer.cpp

in the LinkProgram().

So that there i stuck for now. Any ideas and help are welcome ! Thanks !

@kas1e

Where is glCreateShader?

https://registry.khronos.org/OpenGL-Re ... html/glShaderSource.xhtml -> "GL_INVALID_OPERATION is generated if shader is not a shader object."

@Capehill
In the same COGLES2MaterialRenderer.cpp line 218:

https://sourceforge.net/p/irrlicht/cod ... GLES2MaterialRenderer.cpp

Intersting that i do not have error about "GLSL shader failed to compile", but only about failing to link.

I even put printf("%s\n", shader); , right before glAttachShader(Program, shaderHandle);, at the end of createShader(), and it prinfs 4 shaders fine.

@kas1e

Was glSnoop log filtered in some way? I am just wondering why there were only 2 GL calls shown.

glCreateShader can return 0 on error (line 222) so this should be checked: https://sourceforge.net/p/irrlicht/cod ... MaterialRenderer.cpp#l222

@Capehill

Yeah, it was filters on shaders call only, there is full non-filtered log (2.5mb of size):

https://kas1e.mikendezign.com/aos4/irr ... whole_irrlicht_ogles2.txt

And there is the simple test case which you may try yourself too:

https://kas1e.mikendezign.com/aos4/irr ... _ogles2_irrlicht_test.lha

You can see that for first after 3 failed attempt to link it crash in nova, then ignore DSI helps, and another 3 failed link. All the shaders used by ogles2 renderer in media/shaders/.

Okay, full log shows that shader pipeline creation failed:

Quote:

So, we need to investigate related shaders.

@Capehill
Not that i understand error well .. Did it mean that some shaders cant be compiled ? Or they are, just fail to link ?

Or, they still can't compiles, just in this part Irrliht didn't have proper checking on return code ?

For now i will try to glslanvalidator/w3dshaderinfo on all of them, to see which ones can't compiles.

@Capehill

Checked all the shaders coming with Irrliht, and that the results we have:



So, we can't compile 8 shaders , all of which share the same issue different values used via ShaderGetObjectInfoTags() and via ShaderGetOffset().

Have a clue wtf ?:) I checked shaders itself, and seems that all errors about coming from uniforms, be it ones whih mat4 , or which have arrays like [MAX_LIGHTS], or ones which even pure "uniform int uLightCount". But maybe some of them is just sideeffect of previous uniform errors..



Also interseting, if they can't compiles, why we do not have those errors from Irrlicht, but only on Linking ? Maybe because OGLES2 do compile them fine to spirv, but it's then spirv which fails, maybe that the reasson why irrlicht didn't throw an error before linking. Or maybe irrliht need more checks inside ?

@Capehill
Ok so simple test case with arrays fail easy under nova:



And this one already have DRIVER ERROR about vLightColor's offset was: 1 via ShaderGetObjectInfoTags(), but 2 via ShaderGetOffset().

I do not remember, don't we have support for arrays already in Nova ? I know we do miss support of arrays in structs, etc, but are we in troubles with _any_ arrays ?

Anyway, is there any easy was how we can get rid of arrays in shaders to make them works as expected just without arrays ?:)

@kas1e

Interesting bug. After some testing (glslangvalidator + Nova only), it seems to me that the minimum condition for crashing W3DN_CreateShaderPipeline is to define 2 "out" arrays of size 2 in vertex shader and similarly 2 "in" arrays of size 2 in fragment shader, like

out vec2 foo[2];
out vec2 bar[2];

and

in vec2 foo[2];
in vec2 bar[2];

Removing the other array, or using size 1 doesn't seem to crash. I suppose we need Hans here.

Quote:

You can unroll the light loops and use separate variables as a workaround.

@Capehill

Btw, remain Irrlicht's author says that OGLES2 support in Irrlicht mean to have those shaders all the time used, because they simulate the old fixed function pipeline - bit horrible, but allows to have old Irrlicht code mostly work on ES2 without changes.

So basically OGLES2 there is also emulate the fixing pipeline, so that to be seen if this faster than GL4ES or not (which also emulate fixed pipeline). But at least we can see if removing of GL4ES giving any perfomance boost or not.

But we firstly need to fix shaders..

@kas1e

Looks like there's a bug in ShaderGetObjectInfoTags(). ShaderGetOffset() is returning the correct value. Please submit a bug report, and I'll fix it when I get a chance.

Hans

@Hans,Capehill

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

@Capehill

Quote:

I asked them to add error checking there for both glCreateShader() and glCompileShader(), so to have proper error instead of "GLSL shader programm failed to link"

@kas1eQuote:

how can i get a user on mantis? any idea? i tried so severeal weeks ago.
i tried to create one (userid + password) but cannot log in.

I retry to create a user and it tells me that my email address is in use.
ok - so i tried the "forget password" thing - but that does not send my any email...

i also contracted the admin. and also did not receive an answer.

any idea?

thanks and regards
michael

@Michael
Quote:
Imho you need to wrote to Mattew about

@Capehill
Good news, Hans fixed this bug, so i tested in with new beta of nova: all shaders from ogles2 version of Irrlicht compiles fine now and my small test case too. So, will continue now to works on.