That's not too bad as you have at moment glClear working. When I read the context.c code in Regal last night I would think there would still need to be some specific Amiga code in there but seeing glClear work it seems not
It can be that only the same 1:1 calls works .. I mean, OGLES2 also have glClear, and it can be that regal translate the same calls just as it, without doing anything.
Quote:
Does Regal expect something regarding default state management to setup that might not be correct. As that can mess up a simple triangle. I had issue with minigl defaulting depth testing on when it is supposed to be off according to documentation regarding OpenGL spec.
From another side, if it works on MiniGL, it's expected to work in Regal without changes of OLG code. Of course, if not only our example is totally out of OGL specification, and works on MiniGL by some luck :)
@Capehill Quote:
I can't see glViewPort and model/projection matrix setup done. Does Regal provide something for the defaults?
Dunno about details, but it expected that if it works on opengl (minigl) it should the same works in Regal as well, without special code changes.
I will try your triangle way as well now, maybe will make differences.
@All Found that Regal use classic environment variables, so once i buid all with debug info and all loging possibilities, i can then just do:
Quote:
ram:>setenv REGAL_LOG_APP 1
And run test case to see logs from APP.
Or i can do:
Quote:
ram:>setenv REGAL_LOG_DRIVER 1
To see logs from Regal driver when run app.
By default binary builds with REGAL_LOG_INFO, so you can see general info which i post above.
Now, i log : info , app, internal and driver logs, there they are:
And, there is binary if anyone want to play with (there is a loot of possible ENVs, you will see their name just after you will run binary from shell):
There can be seen, that together with all shit, shaders are trying to creates (check from the lines 176). What there happens i do not understand at momen much, but it seems it create shaders, and trying to use them, and , probably fail ? Bunch of glGetUniformLocation returned -1 , dunno what it mean as well.
I also asking for some tech. help from Daniel, and he say that Regal, do use shaders for everything, as its only way to make it all works on ogles2. And they may fail or something..
But, if i just remove part about glBegin/glEnd, and keep only 2 color based functions, shaders didn't creates. What mean, that Regal may indeed translate "the same" calls from ogl to ogles as it, and only do "magic" when there is unsupported functions (and that always will include creating shaders).
Now.. I may try to just grab those shaders from the internal log, and trying to compile them over NOVA, to see if they works at all.
And that explain those glGetUniformLocation return -1 in log: sure they return -1, as shader fail => we see nothing on screen.
@Hans
Is it possible to fix that error, so i can continue with it ?:) I mean to fix in some acceptable timeframe (like in next few days), or , you will not touch shaders in nova until polaris driver done ?:(
Or , for the fast check, maybe you know (i don't) how rewrite those shaders so they will works on NOVA.
This is great progress. glGetUniformLocation returned -1 when a uniform variable is not bound it looks like the driver is just checking all possibilities to manage states maybe just the way it works as the scripts don't appear to have those variables so it appears that failure is ok.
I take back what I said. Looking at the log this stands out about -1.
<code> driver | glGetUniformLocation (256, "rglNormalMatrix") returned -1 driver | glGetUniformLocation (256, "rglModelViewMatrix") returned -1 driver | glGetUniformLocation (256, "rglProjectionMatrix") returned -1 driver | glGetUniformLocation (256, "rglModelViewProjectionMatrix") returned -1 </code>
This might be cause failure to transform the 2d triangle correctly and might be issue.
Do you have a platform to test Regal on so we can see if the sample I provide really works correctly or maybe we need a simple 3d transformed triangle.
Is it possible to fix that error, so i can continue with it ?:) I mean to fix in some acceptable timeframe (like in next few days), or , you will not touch shaders in nova until polaris driver done ?:(
Yes, I'll have a look at fixing it soon. However, see the comments below...
Quote:
Or , for the fast check, maybe you know (i don't) how rewrite those shaders so they will works on NOVA.
The offending line is: gl_Position = rglProjectionMatrix * rglModelViewMatrix * rglVertex;
The shader compiler doesn't like multiplying two uniforms together. I thought I'd fixed all of those, but obviously not.
If you can switch it to using rglModelViewProjectionMatrix instead, then it'll work. Plus, it'll be better code. The above line is wasteful, because you end up multiplying those matrices for every vertex. By switching to rglModelViewProjectionMatrix , the calculation is done once on the CPU, and you only need to upload one matrix to the GPU instead of two.
Do you have a platform to test Regal on so we can see if the sample I provide really works correctly or maybe we need a simple 3d transformed triangle.
Not at moment, but probably can make a linux install somewhere, to test it all. Through with linux it will mean we need use EGL, or X11 directly and their ogl drivers => which can be different for default olg states, and it may work different on 2 platforms.
Quote:
driver | glGetUniformLocation (256, "rglNormalMatrix") returned -1 driver | glGetUniformLocation (256, "rglModelViewMatrix") returned -1 driver | glGetUniformLocation (256, "rglProjectionMatrix") returned -1 driver | glGetUniformLocation (256, "rglModelViewProjectionMatrix") returned -1
If vertex shader fail, then that can be also reassons we will see nothing. Dunno if those -1 related to the output shader do (i.e. if shaders fail, then its all return -1, and if not , then its will be ok), or it's 2 independent issue, but to be sure we firstly need to fix shaders.
I just checked on the first one which return -1: rglSampler0 in whole Regal code, and it founds only in RegalIff.cpp:
Quote:
ss << "#define gl_Sampler0 rglSampler0\n\n";
And function where it happens called: void Iff::ShaderSource().
What mean it's also about shaders, and there possibility it fail because our vertex one fail.
@Hans I know nothing about shaders language at moment sadly :( And i fear if we change Regal shader it can make Regal works wrong (or don't works at all), but for sake of tests, will be interesting to check it with working shaders.
How should that vertex shader looks like, so to works on NOVA right now, without waitin for fix ? I mean that one:
#version 100
// program number 1
#define in attribute
#define out varying
#define FLAT
precision highp float;
uniform mat4 rglModelViewMatrix;
uniform mat4 rglProjectionMatrix;
in vec4 rglVertex;
in vec4 rglColor;
FLAT out vec4 rglFrontColor;
void main() {
gl_Position = rglProjectionMatrix * rglModelViewMatrix * rglVertex;
rglFrontColor = rglColor;
rglFrontColor = clamp( rglFrontColor, 0.0, 1.0 );
}
I.e. to not have issues which you descibe on bugtrucker (A single vertex shader output can't exceed vec4 and The shader compiler currently can't handle multiplying two uniforms together).
I mean someone need to bring working on current NOVA shader version of that piece of code, and i will just copy+paste it to Regal for tests :)
Edited by kas1e on 2018/2/14 9:09:33 Edited by kas1e on 2018/2/14 9:10:17
And also didn't see triangle (in minigl version that triangle shows fine too). And , output from driver the same: the same shaders creates, and the same -1 erorrs from glGetUniforLocation calls. Strange through, i was expected shaders be a bit different, for different versions of triangles, but maybe they should not..
Anyway, problem is not our OGL code imho then, if both versions of triangles fail the same.
Now we need working on current NOVA version of vertex shader, to see if that help. And if no, then will thing what to do with those -1 returns from glUniforms
I also asking for some tech. help from Daniel, and he say that Regal, do use shaders for everything, as its only way to make it all works on ogles2.
OpenGLES 2 has no fixed function pipeline by definition. That's the whole point of Regal: to implement those missing functions (and mimic some more). And the *only* way to implement those missing functions using ogles2 is by creating a matching GLSL vertex / fragment shader pair. This is true even for the most simple triangle-draw code.
Quote:
But, if i just remove part about glBegin/glEnd, and keep only 2 color based functions, shaders didn't creates. What mean, that Regal may indeed translate "the same" calls from ogl to ogles as it, and only do "magic" when there is unsupported functions (and that always will include creating shaders).
If Regal didn't create any shaders, then you either created invalid OpenGL code. E.g. a glBegin / glEnd without meaningful / invalid vertex content won't trigger Regal's drawing system and thus won't trigger shader creation (I suppose this is exactly the scenario you told above?). Or you only called functions that don't require shader-usages. Such things are state-changes, texture uploads, etc. And the only draw-command that doesn't require a shader-program: glClear (which is why you see your blue background in any case). In short: *any* geometry drawing *requires* Regal to create a valid shader-program consisting out of vertex- and fragment-shader!
Quote:
Strange through, i was expected shaders be a bit different, for different versions of triangles, but maybe they should not..
Not necessarily. In both cases you are trying to draw a bunch of colored vertices, using the same OpenGL states. The only difference is that with the white triangle the color is not redefined per vertex. Apparently Regal doesn't optimize for this case (it could send the color as uniform) and always sends vertex color attributes even if not really required.
Quote:
driver | glGetUniformLocation (256, "rglNormalMatrix") returned -1
Of course the ogles2.library will return -1 because there's no active valid shader-program. A valid bound shader-program is the requirement for glGetUniformLocation and similar functions to do sth. useful. -1 is the expected result if that's not the case.
Anyway, the thing simply is: Nova (and maybe ogles2.lib too, depending on GLSL-feature) still needs some more improvements in its SPIRV-to-native-assembler before you can expect Regal to work. And / or manual modifications of Regal's shader generator are required. Regal expects full GSLS support which we simply don't have at this time, although Hans already implemented quite a lot of stuff. But right now you simply cannot expect Regal to run out of the box.
That being said: I know 100% for sure that Nova and ogles2.library are mature enough to create shaders that can do everything required to come up with shaders that can mimic the old fixed function pipeline However it might be quite a task to come up with such shaders and to integrate them into Regal / make the required changes to Regal. Good luck!
If Regal didn't create any shaders, then you either created invalid OpenGL code. E.g. a glBegin / glEnd without meaningful / invalid vertex content won't trigger Regal's drawing system and thus won't trigger shader creation (I suppose this is exactly the scenario you told above?). Or you only called functions that don't require shader-usages. Such things are state-changes, texture uploads, etc. And the only draw-command that doesn't require a shader-program: glClear (which is why you see your blue background in any case).
Shaders dind't creates if i have only those calls in use, without anything else:
Once i use something with glBegin/glEnd, then shaders creates. That prove that you are right there again :) : glClear(), glClearColor() and glFlush() do not need shaders to make them works on ogles2 context.
Quote:
Anyway, the thing simply is: Nova (and maybe ogles2.lib too, depending on GLSL-feature) still needs some more improvements in its SPIRV-to-native-assembler before you can expect Regal to work. And / or manual modifications of Regal's shader generator are required. Regal expects full GSLS support which we simply don't have at this time, although Hans already implemented quite a lot of stuff. But right now you simply cannot expect Regal to run out of the box.
That being said: I know 100% for sure that Nova and ogles2.library are mature enough to create shaders that can do everything required to come up with shaders that can mimic the old fixed function pipeline However it might be quite a task to come up with such shaders and to integrate them into Regal / make the required changes to Regal. Good luck!
We can start from simple Triangles, those 2 examples (white one and colored one), are good for begining imho. Once shaders for them will works, we then can try some more heavy examples.
I mean that rewriting Regal's shader generator, will be kind of workaround (and no one can do it except Hans and you anyway), while we need NOVA's shader works fine with what Regal generate => that will mean in end all other apps will benefit from, and whole NOVA shaders will works better.
But at begining dealing with triangles will be fine enough, to see that Regal works at all.
> glGetUniformLocation (256, "rglNormalMatrix") returned -1
I dont think that GlEs use a name like rglNormalMatrix for this uniform (=global variable in GLSL langage) rgl looks like regal glNormalMatrix is a name certainly more GL compliant
Same apply for this "in" (=parameter variable in GLSL langage) in vec4 rglVertex
so having shaders with rgl* changed to gl* would certainly help
>I know nothing about shaders language at moment sadly Have a look here : you will understand enough for your triangles code:
I dont think that GlEs use a name like rglNormalMatrix for this uniform (=global variable in GLSL langage) rgl looks like regal glNormalMatrix is a name certainly more GL compliant
Same apply for this "in" (=parameter variable in GLSL langage) in vec4 rglVertex
so having shaders with rgl* changed to gl* would certainly help
Imho you got it a bit wrong :) There in log we debug Regal's driver: so internally regal generate all shaders with rGL because its how generator of shaders done. Of course after all of this its all translates to gl* when need it.
dont think that GlEs use a name like rglNormalMatrix for this uniform (=global variable in GLSL langage) rgl looks like regal glNormalMatrix is a name certainly more GL compliant
Same apply for this "in" (=parameter variable in GLSL langage) in vec4 rglVertex
so having shaders with rgl* changed to gl* would certainly help
It's just a variable name, you could call it the pinkMatrix for all it matters, the 'rgl' just gives a clue that regal generated it.
@all Tararam !! Who is your daddy ! Only amiga 1200 (and 4000) make it possible and unpossible !
(press to open in new tab, to have it in fullsize)
So, what i do its after reading link from Alain on nehe example and words from Hans about needs to replace on rgl_ModelViewProjectionMatrix , i just change shader generator to provide such vertex shader:
#version 100
// program number 1
#define in attribute
#define out varying
#define FLAT
precision highp float;
uniform mat4 rglModelViewProjectionMatrix;
uniform mat4 rglModelViewMatrix;
uniform mat4 rglProjectionMatrix;
in vec4 rglVertex;
in vec4 rglColor;
FLAT out vec4 rglFrontColor;
void main() {
gl_Position = rgl_ModelViewProjectionMatrix * rglVertex;
rglFrontColor = rglColor;
rglFrontColor = clamp( rglFrontColor, 0.0, 1.0 );
}
And now it works ! Damn triangles ! Both white from dbstany's example , and colored from Capehill.
Also, i do capture driver log again, so to better understanding how regal works,there is:
As you can see there, there is still lots of -1 , but with working shader, not everything, see:
Quote:
driver | glGetUniformLocation (256, "rglModelViewMatrix") returned 1 driver | glGetUniformLocation (256, "rglProjectionMatrix") returned 2 driver | glGetUniformLocation (256, "rglModelViewProjectionMatrix") returned 0
What mean that for every shader code apply those glGetUniformLocation() so to check what returns in positive and then do works with it.
Now , need to try some more heavy GL example. Can anybody provide some more interesting code, which i can just put to the void display() ? Just want to see how good emulation is.
I dont think that GlEs use a name like rglNormalMatrix for this uniform (=global variable in GLSL langage) rgl looks like regal glNormalMatrix is a name certainly more GL compliant
Same apply for this "in" (=parameter variable in GLSL langage) in vec4 rglVertex
so having shaders with rgl* changed to gl* would certainly help
That's all wrong. GLSL for OpenGLES2 doesn't support *any* built-in variables (with the exception of gl_Position). Again: there's *zero* remaining of any fixed-function pipeling with OGLES2. Where should a built-in gl_NormalMatrix come from?! Out of nowhere? *All* such variables are uniforms (or attributes) supplied and calculated by the client program or variables calculated manually inside the shader and their names have zero meaning for the functionality. The only thing that a variable change like the one you proposed will provoko is a compile or runtime failure - unless you consistently rename the variables all over the place, not just in the shader...
Quote:
Have a look here : you will understand enough for your triangles code:
Better don't. This is outdated and asumes a typical GLSL1-on-desktop-with-fixed-function-stuff combination from the stoneage.
@kas1e Quote:
Imho you got it a bit wrong :) There in log we debug Regal's driver: so internally regal generate all shaders with rGL because its how generator of shaders done.
That's right. The variable names can be pretty much anything. *But don't change them!* Unless you also scan Regal's other C++ code and change the names all over the place, e.g. in an glGetUniformLocation call...
Quote:
Of course after all of this its all translates to gl* when need it.
As you can see there is much more gl calls of all sort, and so, Regal generate for it 2 shaders as usuall: fragment one are the same as in case with triangles, but vertex one are a lot different now (and its already with our fix in terms of rglModelViewProjectionMatrix):
#version 100
// program number 1
#define in attribute
#define out varying
#define FLAT
And that shader also fail on NOVA, because of Arrays :) I.e. those uniform vec4 rglMaterialFront[ ME_ELEMENTS ]; and co. I also create a BZ about it before and Hans aware about: http://amigadeveloper.com/bugreports/view.php?id=297
So, or we need Hans to add arrays support, or, somebody should show how we can replace shader generator in terms of arrays, to be able to compile valid shader for NOVA.
All of them works, except GL_QUADS and GL_QUAD_STRIP.
Regal docs says:
Quote:
Compatible:
Immediate mode, fixed function, GL_QUADS work everywhere, emulated as necessary.
Limitation:
GL_QUADS only works in immediate mode or with DrawArrays for ES and core profiles.
I not expert why all others things like TRIANGLES , LINES and co not mentioned, probably GL_QUADS are different from them all when it come to ogl->ogles.
Anyway, immediate mode mean glBegin()/glEnd() combo, and that what i trying there : while same example with QUADS works in minigl, it didn't in regal->ogles2.
But that seems don't work as expected (or buggy?).
So i do check also driver logs when i run 3 versions: gl_lines, gl_triangles and gl_quads. For gl_lines and gl_triangles logs, i see that after glBufferData calls, it do for GL_LINES:
I do not know it expected to be like this by Regal or not. But even if, docs says "GL_QUADS only works in immediate mode or with DrawArrays for ES and core profiles.". But didn't glBegin/glEnd by itself mean immediate mode ? And as we can see, when we use GL_TRIANGLE and GL_LINES, driver do call glDrawArrays anyway, but not for GL_QUADS.
Have anyone a clue/idea about ?
There is full logs for GL_LINES, GL_TRIANGLES and GL_QUADS:
If those quads don't work with your simple single-colored tests then Regal's mandatory emulation is probably flawed here - which would be kind of a surprise if it failed with sth. that basic!
Actually it would be such a big surprise that I don't believe it Because of that and because your log output smells like it (3 lines being drawn...):
May it be that you try to draw a quad with only 3 vertices... ?
That probably can explain not accurate emulation of polygon :)
Quote:
Actually it would be such a big surprise that I don't believe it Because of that and because your log output smells like it (3 lines being drawn...):
I just messed in previous post, and put 2 times triangle log, updated now. But anyway, in those previous logs i indeed checking with 3 vertices only, but in MiniGL, even that "broken" code works:
While app one looks not interesting (our original gl calls), internal one looks interesting: it shows that Regal::Emu::Quads emulation take place (that RegalQuads.cpp and RegalQuads.h), and it in end tries to call glDrawElements().. Just seems fail ?
I hope it not related to that fixed vertex shader where we do that:
Edited by kas1e on 2018/2/14 19:21:54 Edited by kas1e on 2018/2/14 19:31:32 Edited by kas1e on 2018/2/14 19:37:44 Edited by kas1e on 2018/2/14 19:55:48 Edited by kas1e on 2018/2/14 20:04:20 Edited by kas1e on 2018/2/14 20:06:23
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
