Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
52 user(s) are online (37 user(s) are browsing Forums)

Members: 1
Guests: 51

LiveForIt, more...

Support us!

Headlines




« 1 2 3 (4)


Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 401
@Capehill
Now that I saw it: yes, definitely a Nova bug, no need to look at the source, thanks.

   Report Go to top

Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 401
@Capehill
@kas1e
New ogles2 v3.0 wip version is on my FTP. I further improved the unused variable detector (whopping 185 lines now ). As a direct result it now also correctly detects the missing initialization of the int "temp" in this shader. Until now stuff like that could eventually slip through undetected because I didn't correctly handle certain OpDecorations (in this case RelaxedPrecision).

   Report Go to top

Re: The OpenGL ES 2.0 thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6374
@Daniel
Yeah, works!

But now, when it not "forced" version, then in ShaderJoy we didn't have a warning window about non-init-vars, but only have them when enabled "verbose log" and it just hides in the deep of other output. + shader execution didn't stop. But that all to Capehill, of course :) Check ShaderJoy thread anyway.


Edited by kas1e on 2020/8/6 12:39:10
Edited by kas1e on 2020/8/6 12:46:01
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 401
@Capehill
@kas1e
Another ogles2 v3 wip update with even more improvements of the uninitialized variables detector is on my FTP. It now correctly detects even more stuff, e.g. in these shaders:

KissingDonuts, "g" (note: this is the only critical uninitialized variable here, despite what's being said here)
Glowing Stone, "color"
Aya Tunnel, "dO" (note: this is the only critical uninitialized variable here, despite what's being said here)
Glass looking modulo trick, "acc"
Dancing circles, "f"

A stupid typo prevented the detection of some of those until now. Essentially this typo made the detector look for invalid jump target names in one situation, which in turn led to early quits. The second stupid typo eventually made the detector not start at the true entry point, also leading to early quits sometimes. This one was responsible for the other missed hits.
En passant the performance was increased significantly (although the detector's impact wasn't measurable before already ).

EDIT: didn't check if the followin weren't detected before, those were just coming around in the Mantis right now, so I quickly used those for verification.

Valentiness, "z" (note: this is the only critical uninitialized variable here, despite what's being said here)
Intricate circles, "col"
Another Cloudy Tunnel, "vecOld"
Solar distortion, "dpMin"



Edited by Daytona675x on 2020/8/7 12:38:00
Edited by Daytona675x on 2020/8/7 12:41:27
   Report Go to top

Re: The OpenGL ES 2.0 thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6374
@Daniel
Yeah, detection is better for sure. From all Hans finds find out 2 ones which weren't detected:

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

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


One in MainImage() probabaly is out of detection as you explain before, but another one seems unitialized var in the image() function, so should be detected imho ?

Btw, offten we have in different function declared vars with the same name, and only one or some of them are really unitialized. Question is : is it of much hassle, in the error output with name of unitialized var print a number of string in the shader, or it all up to high level's code ?

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

Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 401
@kas1e
Those are the two which I told you on FB cannot be detected "by design". The detector currently doesn't track such (in)outs, they are completely ignored. This won't change in the foreseeable future, most likely.

You mean line numbers? Those are gone in the SPIR-V, usually. However, I could add an aglSetParam-option to enable the emitting of OpLine instructions, which the detector could then pick up easily.
But IMHO that's not worth the bloat. Such shaders usually don't consist out of hundreds of lines. A search for the respective variable name will most often immediately and the rest of the time very quickly lead you to the critical location in the shader anyway.
But if you really want it real hard, then I'll add it
(but note that the line numbers won't necessarily be what you expect in case of ShaderJoy, because the listings get a trailing "invisible" static piece of code attached internally... So if I add support for this, then another optional int agl-parameter for a line-number report-offset would be mandatory, I guess).


Edited by Daytona675x on 2020/8/8 7:56:19
   Report Go to top

Re: The OpenGL ES 2.0 thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6374
@Daniel
No no, not of big deal. Just if it was something very simply like adding another byte to printf, but if not, no need to spend time on. Its good enough already :)

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

Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2011/6/3 13:49
Posts: 264
Does those shaders works if those unintialized vars are set manually ?
( I mean edit the shader)

   Report Go to top

Re: The OpenGL ES 2.0 thread
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6374
Of course (that what we are talk about). But they tested with 1.74 betas of Nova, so not sure if they all will work after you fix vars with public 1.68.

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

Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 401
OpenGL ES 2 version 3.0 for Warp3D Nova / AmigaOS4 has been finalized.
It's available on my FTP for testers and A-Eon devs, as usual, for a last check.

- new aglSetParamTags / aglCreateContextTags2 parameter OGLES2_CCT_DEBUG_SHADER_LOG. If set to TRUE then the library asks Nova for extra shader compiler info. A detailed log will be returned even on successful shader compilation. If this flag is set to FALSE (default) then only the usual standard error log will be returned.

- extended the extensions string by GL_ARB_texture_non_power_of_two and GL_OES_texture_npot. The lib implicitely supported those since day one but not mentioning them explicitely in the ext-string could cause some progs to execute internal pot-scale workarounds or to fails needlessly.

- Fix: design flaw. Every shader had its own internal variable-cache. Which at first glance seems to be all good and which most often works. But actually it's wrong because that cache also handles the mapping of uniform locations. But those can vary for the very same shader if it's being used by multiple programs! So, this bug could cause all sorts of hard to track issues if the client used shared shader objects for multiple programs. Now the variable-caches have been moved into the program objects (simply spoken, in fact the shaders still have their own cache but the programs get their own autarkic set of dedicated variable-representations).

- while I was at it I trashed all the old program introspection code and rewrote it from scratch. As a result the lib now also supports uniform arrays. Sometimes trashing your old broken stuff is way better than trying to fix it - only to probably add more sideeffects. No, better accept your failure and start over

- extended the extensions string by GL_ARB_arrays_of_arrays. This is because the new introspection system didn't just add array support but multidimensional array support too.

- new aglSetParamTags / aglCreateContextTags2 parameter OGLES2_CCT_DETECT_UNINITIALIZED_GLSL_VARS. If set to 1 or 2 (default 0) then the library will analyze the generated SPIR-V code and look for uninitialized shader variables. If set to 1 then it will only put a warning in the log and continue, if set to 2 then glCompileShader will return with an error if something suspicious is being detected.
Note that the scanner is considered "good enough for us", it's certainly not perfect (well, it cannot possibly be without simulating all possible inputs and fully emulating the shader, so... it's just a ~200 liner ;) ). While it does analyze all different code-paths (branches, conditional branches, function calls, loops) it will not detect stuff like a vector variable being only partially initialized (e.g. a vec4 whose .xyz are initialized but not its .a won't be detected) or structs that are only partially initialized (e.g. struct s {vec2 a; vec2;b} won't be reported if a is being set but b is not). Other than that it gives pretty good results with only a minimal, practically not measurable, performance impact on glCompileShader (depends on shader size / complexity / num variables, but even checking real big ones didn't hit performance measurably so far).
Thanks to kas1e for requesting!

- glslangvalidator_redux shell tool extended by an equivalent -varcheck option to enable scanning for uninitialized shader variables.

- Fix: standard violation. If you attached a texture to an FBO then a resize of said texture using glTexture2D should be enough to trigger a resize of the whole FBO. Before that fix this led to gfx coruption because Nova doesn't automatically handle that case neither. The necessary workaround until now was to unattach and reattach the texture to force ogles2 lib into updating the FBO. Now all you need is glTexture2D.
Thanks to Capehill for reporting!

- new aglCreateContext / aglSetParam parameters OGLES2_CCT_SPIRV_OPLINES (bool) and OGLES2_CCT_SPIRV_OPLINES_OFFSET (int) which extend the uninitialized-variables-detector by optionally telling you the source-code's line where the shite happened. For that it tells the integrated glslangvalidator to generate SPIR-V which contains OpLine opcodes, which in turn is now handled by the detector. OGLES2_CCT_SPIRV_OPLINES_OFFSET is useful to e.g. make the output 0 or 1 relative or to compensate for any eventual prefix (e.g. ShaderJoy adds a static prefix and should therefore adjust the offset).
Note that this feature is being disabled if you don't have installed the latest Nova 1.76+. Reason is that among some others it didn't correctly handle the OpLine opcode, which in turn resulted in the whole shader not being compiled at all.

- !don't forget to download the new include-folder too!

- version set to 3.0 (14.9.2020) (yep, it's that much of an improvement ;) )

Thanks to kas1e and Capehill for testing!

Cheers,
Daniel

   Report Go to top

Re: The OpenGL ES 2.0 thread
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 3741
@Daytona675x

Quote:

As a result the lib now also supports uniform arrays.

Is that Boolean uniforms support?
Or is that something completely different?

_________________
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
   Report Go to top

Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 401
@Raziel
No, that's sth. completely different indeed.

Boolean uniforms are just uniform variables of type bool. Those are not supported by Nova yet, so when you try to use those inside a shader it won't compile.

This here is general support for arrays of uniform variables, like e.g. uniform float x[10];

Back in the early days of ogles2.lib I had blindly coded support for those, however Nova didn't support them at that time. As it turned out my code was partially buggy. The main problem was that the introspection system wasn't correct in terms of arrays, which prevented proper use of those.
This has now been fixed and improved.

   Report Go to top


« 1 2 3 (4)



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project