@Daytona675x And the size of binary lots smaller than regal one. Through in terms of compatibility regal should be better, but that to be checked. Gl4ES mostly for opengl1.5 and 2.0 for moment , but author optimize and fine tune it very well (at least better than Regal). He even say that arrays in shaders always not so fast, and he get rid where it possible of them in the generated shaders.
As for crash: sure, gl-code-wise it can be wrong, but it works copy of minigl example, and even if call some stuff which make no sense to call, it shouldn't crash so heavy in different places (most of time right after open of window).
As for crash: sure, gl-code-wise it can be wrong, but it works copy of minigl example,
The normal array has to be larger and filled with correct normals, otherwise you are at least doing illegal memory reads with potentially trashed data. And you know what trashed data for a normal likely is? Most likely not a normal anymore And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal. Please fix the normal-array and try again.
And you know what trashed data for a normal likely is? Most likely not a normal anymore And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal.
Quote:
Please fix the normal-array and try again.
Funny thing is that "random" crash wasn't random. Its just i run test case from shell, and window which opened put shell window behind the gles2 window, and while aglSwapBuffers() not done, there is copy of the screen in the window. So, i watch on that window thinking that there is just few printfs, while they go futher in the shell behind the window, which make me think nothing happens :)
It still strangely crashes: if i put bunch of printfs in Drawbox() before and after every gl call, then, its make 3 loops, and then crashes. But will firstly try to fix normales.
Probably it didn't crash in Regal before, because for that example Regal create shaders with arrays (and so nothing draws, but didn't crash), while, GL4ES create shaders without arrays -> code tryin to executes -> crash.
Through that only suggestion until didn't fix normales, maybe it bug in gl4es's glMatrixMode (as it works in MiniGL after all..). Will see now
@Daniel Btw, just to be sure its not in spam box : did you recieve reports on mail about glGetActiveUniform(...) and glGetActiveAttrib(...) ?
Edited by kas1e on 2018/2/18 10:18:52 Edited by kas1e on 2018/2/18 10:20:09
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.
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.
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 ..
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.
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.
@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
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...
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:
...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.
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:
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
@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.
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.
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
@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
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...
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.:
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
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?
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.
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.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal.
You are calling glNormal and not glNormalPointer, so it's all good with the code in that area.
