Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
55 user(s) are online (46 user(s) are browsing Forums)

Members: 0
Guests: 55

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 (2) 3 4 »


Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@DStastny
Quote:

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:

http://kas1e.mikendezign.com/aos4/Regal/regal_log_info.txt
http://kas1e.mikendezign.com/aos4/Regal/regal_log_app.txt
http://kas1e.mikendezign.com/aos4/Regal/regal_log_driver.txt
http://kas1e.mikendezign.com/aos4/Regal/regal_log_internal.txt

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):

http://kas1e.mikendezign.com/aos4/Regal/testdbany_gles.zip

Very interesting regal_log_driver.txt

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.


Edited by kas1e on 2018/2/14 8:36:19
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@All
Ok ! Now, regal make 2 shaders when we do our triangle:

shader.vert:

#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 clamprglFrontColor0.01.0 );
}


And shader.frag:

#version 100
// program number 1
#define in varying
#define rglFragColor gl_FragColor
#define FLAT  
precision highp float;
FLAT in vec4 rglFrontColor;
void main() {
    
vec4 p rglFrontColor;
    
rglFragColor p;
}


I do check via glslangValidator them both: all is ok. So they ok by specification.

Then, i tested them both via W3DNShaderInfo, and BAM ! Vertex one fail !

Fragment one are ok, but vertex one fail with that kind of errors:

Quote:

W3DNShaderInfo - Get shader information

Shader: vert.spv
Compiling vert.spv failed (23) with error: shader compilation failed due to errors
Log:
ERROR: Code generation failed.
Error log:
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR1) src0(SGPR8) src1(SGPR24) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR1) src0(SGPR12) src1(SGPR25) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR1) src0(SGPR16) src1(SGPR26) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR1) src0(SGPR20) src1(SGPR27) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR2) src0(SGPR9) src1(SGPR24) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR2) src0(SGPR13) src1(SGPR25) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR2) src0(SGPR17) src1(SGPR26) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR2) src0(SGPR21) src1(SGPR27) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR3) src0(SGPR10) src1(SGPR24) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR3) src0(SGPR14) src1(SGPR25) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR3) src0(SGPR18) src1(SGPR26) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR3) src0(SGPR22) src1(SGPR27) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR4) src0(SGPR11) src1(SGPR24) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR4) src0(SGPR15) src1(SGPR25) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR4) src0(SGPR19) src1(SGPR26) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR4) src0(SGPR23) src1(SGPR27) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR5) src0(SGPR8) src1(SGPR28) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR5) src0(SGPR12) src1(SGPR29) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR5) src0(SGPR16) src1(SGPR30) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR5) src0(SGPR20) src1(SGPR31) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR6) src0(SGPR9) src1(SGPR28) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR6) src0(SGPR13) src1(SGPR29) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR6) src0(SGPR17) src1(SGPR30) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR6) src0(SGPR21) src1(SGPR31) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR7) src0(SGPR10) src1(SGPR28) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR7) src0(SGPR14) src1(SGPR29) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR7) src0(SGPR18) src1(SGPR30) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR7) src0(SGPR22) src1(SGPR31) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR8) src0(SGPR11) src1(SGPR28) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR8) src0(SGPR15) src1(SGPR29) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR8) src0(SGPR19) src1(SGPR30) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR8) src0(SGPR23) src1(SGPR31) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR9) src0(SGPR8) src1(SGPR32) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR9) src0(SGPR12) src1(SGPR33) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR9) src0(SGPR16) src1(SGPR34) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR9) src0(SGPR20) src1(SGPR35) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR10) src0(SGPR9) src1(SGPR32) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR10) src0(SGPR13) src1(SGPR33) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR10) src0(SGPR17) src1(SGPR34) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR10) src0(SGPR21) src1(SGPR35) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR11) src0(SGPR10) src1(SGPR32) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR11) src0(SGPR14) src1(SGPR33) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR11) src0(SGPR18) src1(SGPR34) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR11) src0(SGPR22) src1(SGPR35) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR12) src0(SGPR11) src1(SGPR32) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR12) src0(SGPR15) src1(SGPR33) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR12) src0(SGPR19) src1(SGPR34) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR12) src0(SGPR23) src1(SGPR35) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR13) src0(SGPR8) src1(SGPR36) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR13) src0(SGPR12) src1(SGPR37) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR13) src0(SGPR16) src1(SGPR38) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR13) src0(SGPR20) src1(SGPR39) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR14) src0(SGPR9) src1(SGPR36) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR14) src0(SGPR13) src1(SGPR37) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR14) src0(SGPR17) src1(SGPR38) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR14) src0(SGPR21) src1(SGPR39) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR15) src0(SGPR10) src1(SGPR36) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR15) src0(SGPR14) src1(SGPR37) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR15) src0(SGPR18) src1(SGPR38) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR15) src0(SGPR22) src1(SGPR39) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MUL_F32 vDst(VGPR16) src0(SGPR11) src1(SGPR36) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR16) src0(SGPR15) src1(SGPR37) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR16) src0(SGPR19) src1(SGPR38) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3
INTERNAL ERROR: Invalid VOP2/3 instruction. Cannot have more than one SGPR input:
V_MAC_F32 vDst(VGPR16) src0(SGPR23) src1(SGPR39) src2(N/A) abs(0) clamp(0) omod(0) neg(0) // VOP3




Done.


And, that seems the same problem which i reported to Hans before:

http://amigadeveloper.com/bugreports/view.php?id=301

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.

Function GenerateVertexShaderSource() are there: https://github.com/p3/regal/blob/master/src/regal/RegalIff.cpp


Edited by kas1e on 2018/2/13 20:16:09
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2017/1/3 6:03
From Atlanta GA
Posts: 44
@Kas1e

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.

The logging that Regal produces is terrific.

Regards
Doug

   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2017/1/3 6:03
From Atlanta GA
Posts: 44
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.

Regards
Doug


   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1949
@kas1e
Quote:
@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 ?:(

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.

Function GenerateVertexShaderSource() are there: https://github.com/p3/regal/blob/master/src/regal/RegalIff.cpp

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.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@DStastny
Quote:

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 clamprglFrontColor0.01.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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@All
I also just tryied triangle from Capehill's example, i.e. render part just:

void display() 
{         
        
glMatrixMode(GL_PROJECTION);
        
glLoadIdentity();

        
glMatrixMode(GL_MODELVIEW);
        
glLoadIdentity();

        
glClearColor(0.0f0.0f0.0f1.0f);
        
glClear(GL_COLOR_BUFFER_BIT);

        
glBegin(GL_TRIANGLES);

        
glColor4f(1.0f0.0f0.0f1.0f);
        
glVertex3f(-0.5f, -0.5f0.0f);

        
glColor4f(0.0f1.0f0.0f1.0f);
        
glVertex3f(0.5f, -0.5f0.0f);

        
glColor4f(0.0f0.0f1.0f1.0f);
        
glVertex3f(0.0f0.5f0.0f);

        
glEnd();
                
                
    
glFlush(); 
        
//mglSwitchDisplay(); 
    
IOGLES2->aglSwapBuffers();
}


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

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

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 122
Quote:
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!

   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@Daniel
Quote:

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:

Quote:

void display()
{
glClearColor(0.5f, 0.3f, 1.0f, 0.4f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glFlush();
IOGLES2->aglSwapBuffers();
}


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.

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

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2011/6/3 12:49
Posts: 203
> 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:

http://nehe.gamedev.net/article/glsl_an_introduction/25007/

Alain

   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@thellier
Quote:

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.

Check that:
https://github.com/p3/regal/blob/master/src/regal/RegalIff.cpp

Quote:

Have a look here : you will understand enough for your triangles code:

http://nehe.gamedev.net/article/glsl_an_introduction/25007/


Thanks ! Indeed helpull ! Will try to fix those triangle shaders now to make it works on NOVA and will see what will happens.



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

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2006/12/4 23:15
Posts: 1999
@thellier

Quote:


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.


_________________
Blender For OS4.x : Blues : Walker Broad
   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@all
Tararam !! Who is your daddy ! Only amiga 1200 (and 4000) make it possible and unpossible !

Resized Image
(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 clamprglFrontColor0.01.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:

http://kas1e.mikendezign.com/aos4/Reg ... driver_working_shader.txt

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.

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

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 122
@thellier
Quote:
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:

http://nehe.gamedev.net/article/glsl_an_introduction/25007/

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.

No, nothing gets "translated".

   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@Daniel
Quote:

No, nothing gets "translated".


Right, just variable names.

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

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 122
@kas1e
Congrats

   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@all
Tried a little more heavy example: some rotated cube from minigl SDK, called draw_buffer.c, with a bit of tweaking to make it works on gles2:

#include <GL/Regal.h>
#include <stdlib.h> 
#include <proto/intuition.h> 
#include <proto/exec.h> 
#include <proto/dos.h>
#include <stdio.h>
#include <proto/ogles2.h>


/* Minimum stack space */
static USED const char *stack "$STACK:65535"

GLfloat light_diffuse[] = {1.01.01.01.0};  /* Red diffuse light. */
GLfloat light_position[] = {1.01.01.00.0};  /* Infinite light location. */
GLfloat n[6][3] = {  /* Normals for the 6 faces of a cube. */
  
{-1.00.00.0}, {0.01.00.0}, {1.00.00.0},
  {
0.0, -1.00.0}, {0.00.01.0}, {0.00.0, -1.0} };
GLint faces[6][4] = {  /* Vertex indices for the 6 faces of a cube. */
  
{0123}, {3267}, {7654},
  {
4510}, {5621}, {7403} };
GLfloat v[8][3];  /* Will be filled in with X,Y,Z vertexes. */

GLfloat angle 0.0;

struct OGLES2IFace *IOGLES2 0

struct Interface *getInterface(char *libname

    
struct Library *lib
     
    
lib IExec->OpenLibrary("ogles2.library"0); 
    if (
lib
        return 
IExec->GetInterface(lib"main"1NULL); 
     
    return 
0


void dropInterface(struct Interface *iface

    if (
iface
    { 
        
struct Library *lib iface->Data.LibBase
        
IExec->DropInterface(iface); 
        
IExec->CloseLibrary(lib); 
    } 



void drawBox(void)
{
  
int i;
  
  static 
float colors[6][3] =
  {
      {
1.00.00.0},
      {
0.01.00.0},
      {
0.00.01.0},
      {
1.00.01.0},
      {
0.01.01.0},
      {
1.01.01.0}
  };

  for (
06i++) {
/*      
    glBegin(GL_QUADS);
    glNormal3fv(&n[i][0]);
    glVertex3fv(&v[faces[i][0]][0]);
    glVertex3fv(&v[faces[i][1]][0]);
    glVertex3fv(&v[faces[i][2]][0]);
    glVertex3fv(&v[faces[i][3]][0]);
    glEnd();
*/
    
glEnableClientState(GL_VERTEX_ARRAY);
    
glNormal3fv(&n[i][0]);
    
glVertexPointer(3GL_FLOAT0v);
    
glColor3fv(&colors[i][0]);
    
    
glDrawElements(GL_QUADS4GL_UNSIGNED_INTfaces[i]);

  }
}

void display(void)
{
  
glClearColor(0.40.00.01.0);
  
glClear(GL_COLOR_BUFFER_BIT GL_DEPTH_BUFFER_BIT);
  
glLightfv(GL_LIGHT0GL_POSITIONlight_position);
  
glPushMatrix();
  
glRotatef(angle1.00.00.0);
  
drawBox();
  
glPopMatrix();
}


void init(void)
{
  
/* Setup cube vertex data. */
  
v[0][0] = v[1][0] = v[2][0] = v[3][0] = -1;
  
v[4][0] = v[5][0] = v[6][0] = v[7][0] = 1;
  
v[0][1] = v[1][1] = v[4][1] = v[5][1] = -1;
  
v[2][1] = v[3][1] = v[6][1] = v[7][1] = 1;
  
v[0][2] = v[3][2] = v[4][2] = v[7][2] = 1;
  
v[1][2] = v[2][2] = v[5][2] = v[6][2] = -1;

  
/* Enable a single OpenGL light. */
  
glLightfv(GL_LIGHT0GL_DIFFUSElight_diffuse);
  
glLightfv(GL_LIGHT0GL_POSITIONlight_position);
  
glEnable(GL_LIGHT0);
  
glEnable(GL_LIGHTING);

  
glColorMaterial(GL_FRONT_AND_BACKGL_AMBIENT_AND_DIFFUSE);
  
glEnable(GL_COLOR_MATERIAL);
    
  
/* Use depth buffering for hidden surface elimination. */
  
glEnable(GL_DEPTH_TEST);

  
/* Setup the view of the cube. */
  
glMatrixMode(GL_PROJECTION);
      
  
glMatrixMode(GL_MODELVIEW);

  
/* Adjust cube position to be asthetic angle. */
  
glTranslatef(0.00.0, -1.0);
  
glRotatef(60.01.00.00.0);
  
glRotatef(-200.00.01.0);
}

void idle(void)
{     
    
angle += 0.1;
    if (
angle 360.0)
       
angle 0.0;
  
}


int main(int argcchar **argv)
{

    
IOGLES2 = (struct OGLES2IFace *)getInterface("ogles2.library"); 
    if (!
IOGLES2
        return 
20

        const 
char titleStrBase[] = "Hello OpenGLES2";
        
struct Window *win=IIntuition->OpenWindowTags(NULL,
                                
WA_Title,                titleStrBase,
                                
WA_Activate,            TRUE,
                                
WA_RMBTrap,                TRUE,
                                
WA_DragBar,                TRUE,
                                
WA_DepthGadget,            TRUE,
                                
WA_SimpleRefresh,        TRUE,
                                
WA_SizeGadget,            TRUE,
                                
WA_CloseGadget,            TRUE,
                                
WA_IDCMP,                IDCMP_REFRESHWINDOW IDCMP_NEWSIZE 
                                                        
IDCMP_CLOSEWINDOW IDCMP_RAWKEY,
                                
WA_InnerWidth,            640,
                                
WA_InnerHeight,            480,
                                
WA_MinWidth,            100,
                                
WA_MinHeight,            100,
                                
WA_MaxWidth,            2048,
                                
WA_MaxHeight,            2048,
                                
WA_BackFill,             LAYERS_NOBACKFILL,
                                
TAG_DONE);
                                                    
        
void *ogles_context=IOGLES2->aglCreateContextTags(0,
                
OGLES2_CCT_WINDOW,(ULONG)win,
                
OGLES2_CCT_DEPTH,16,
                
OGLES2_CCT_STENCIL,8,
                
OGLES2_CCT_VSYNC,0,
                
OGLES2_CCT_SINGLE_GET_ERROR_MODE,1,
            
TAG_DONE);

    
//RegalMakeCurrent((RegalSystemContext)1);
    
RegalMakeCurrent(ogles_context);


    if (
ogles_context)
    {
        
//mglMakeCurrent(IGL);
        //mglLockMode(MGL_LOCK_SMART);
        
IOGLES2->aglMakeCurrent(ogles_context);
        
init();

        
BOOL bRun TRUE;
        
        
//struct Window *win = mglGetWindowHandle();
        
if (!IIntuition->ModifyIDCMP(winIDCMP_CLOSEWINDOW))
            
bRun FALSE;

        
        
glDrawBuffer(GL_FRONT);

        while (
bRun)
        {
            
struct IntuiMessage *imsg;

            
display();
            
idle();
            
            
glFlush();
            
IOGLES2->aglSwapBuffers();            
            
//mglUnlockDisplay();
            
            
glDrawBuffer(GL_BACK);
            
display();
            
glDrawBuffer(GL_FRONT);
            
            
//struct Window *win = mglGetWindowHandle();

            
while ((imsg = (struct IntuiMessage *)IExec->GetMsg(win->UserPort)))
            {
                if (
imsg->Class == IDCMP_CLOSEWINDOW)
                    
bRun FALSE;
                
IExec->ReplyMsg((struct Message *)imsg);
            }
        }
        
        
//mglDeleteContext();
        
IOGLES2->aglDestroyContext(ogles_context);
        
IIntuition->CloseWindow(win);
        
    }
    
    
//dropInterface((struct Interface *)IMiniGL);
    
dropInterface((struct Interface *)IOGLES2); 
    
    return 
0;
}


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  

#define ME_AMBIENT 0
#define ME_DIFFUSE 1
#define ME_SPECULAR 2
#define ME_EMISSION 3
#define ME_SHININESS 4
#define ME_ELEMENTS 5

#define LE_AMBIENT 0
#define LE_DIFFUSE 1
#define LE_SPECULAR 2
#define LE_POSITION 3
#define LE_SPOTDIR 4
#define LE_ATTEN 5
#define LE_ELEMENTS 6

precision highp float;
uniform mat4 rglModelViewProjectionMatrix;
uniform vec4 rglAttrib[16];
uniform mat4 rglModelViewMatrix;
uniform mat4 rglProjectionMatrix;
in vec4 rglVertex;
uniform mat3 rglNormalMatrix;
in vec3 rglNormal;
uniform vec4 rglLightModelAmbient;
uniform vec4 rglMaterialFrontME_ELEMENTS ];
uniform vec4 rglLight0LE_ELEMENTS ];
#define rglColor rglAttrib[3]
FLAT out vec4 rglFrontColor;
void main() {
    
gl_Position rglModelViewProjectionMatrix rglVertex;
    
vec4 eh rglModelViewMatrix rglVertex;
    
vec4 ep eh eh.w;
    
vec3 ev = -normalizeep.xyz );
    
vec3 en rglNormalMatrix rglNormal;
    
vec4 mFrontME_ELEMENTS ];
    
mFrontME_AMBIENT   ] = rglMaterialFrontME_AMBIENT   ];
    
mFrontME_DIFFUSE   ] = rglMaterialFrontME_DIFFUSE   ];
    
mFrontME_SPECULAR  ] = rglMaterialFrontME_SPECULAR  ];
    
mFrontME_EMISSION  ] = rglMaterialFrontME_EMISSION  ];
    
mFrontME_SHININESS ] = rglMaterialFrontME_SHININESS ];
    
mFrontME_AMBIENT ] = rglColor;
    
mFrontME_DIFFUSE ] = rglColor;
    
rglFrontColor.xyz mFrontME_EMISSION ].xyz;
    
rglFrontColor.mFrontME_DIFFUSE ].w;
    
rglFrontColor.xyz += rglLightModelAmbient.xyz mFrontME_AMBIENT ].xyz;
    {
        
vec4 lvec rglLight0LE_POSITION ];
        
vec3 hvec normalizelvec.xyz vec300) );
        
vec3 ambient rglLight0LE_AMBIENT ].xyz mFrontME_AMBIENT ].xyz;
        
float dc maxdotenlvec.xyz ), 0.0 );
        
float sc maxdotenhvec ), 0.0 );
        
vec3 diffuse dc rglLight0LE_DIFFUSE ].xyz mFrontME_DIFFUSE ].xyz;
        
sc = ( dc 0.0 && sc 0.0 ) ? expmFrontME_SHININESS ].logsc ) ) : 0.0;
        
vec3 specular sc rglLight0LE_SPECULAR ].xyz mFrontME_SPECULAR ].xyz;
        
rglFrontColor.xyz +=  ( ambient diffuse specular );
    }
    
rglFrontColor clamprglFrontColor0.01.0 );
}


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.

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

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@all
Found another issue, dunno Regal or Ogles related (probably Regal of course). Issue is:

I tried to check all parameter glBegin can take by ogl2.1 specification. So those are:

GL_POINTS
GL_LINES
GL_LINE_STRIP
GL_LINE_LOOP
GL_TRIANGLES
GL_TRIANGLE_STRIP
GL_TRIANGLE_FAN
GL_QUADS
GL_QUAD_STRIP
GL_POLYGON


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.

I do check regal sources, and, indeed, for the QUADS there is special emulation layer:
https://github.com/p3/regal/blob/master/src/regal/RegalQuads.cpp

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:

Quote:

driver | glDrawArrays (GL_LINES, 0, 3)
driver | glBindBuffer (GL_ARRAY_BUFFER, 0)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 0)


for GL_TRIANGLES:

Quote:

driver | glDrawArrays (GL_TRIANGLES, 0, 3)
driver | glBindBuffer (GL_ARRAY_BUFFER, 0)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 0)


and then come other calls.

But with case of QUADS, i have in log that after glBufferData calls:

Quote:

driver | glBindBuffer (GL_ARRAY_BUFFER, 0)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 0)


I.e. no glDrawArrays call.

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:

http://kas1e.mikendezign.com/aos4/Regal/quads/driver_log_lines.txt
http://kas1e.mikendezign.com/aos4/Reg ... /driver_log_triangles.txt
http://kas1e.mikendezign.com/aos4/Regal/quads/driver_log_quads.txt

EDIT: there was wrong log for quads (2 times triangles instead), updated.


Edited by kas1e on 2018/2/14 19:54:31
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 122
@kas1e
GL_QUADS, GL_QUAD_STRIP and GL_POLYGON are not supported by OpenGL ES 2.

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... ?



   Report Go to top

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4544
@Daytona
GL_POLYGON works as far as i can see. And in minigl and in regal->ogles. I.e. that code works:

void display() 

    
    
glClearColor(0.5f0.3f1.0f0.4f);    
    
glClear(GL_COLOR_BUFFER_BIT GL_DEPTH_BUFFER_BIT);
    
    
glBegin GL_POLYGON );
        
glVertex2f(0.00.0);
        
glVertex2f(0.03.0);
        
glVertex2f(4.03.0);
        
glVertex2f(6.03.0);
        
glVertex2f(4.03.0);
    
glEnd();
     
    
glFlush(); 
    
    
IOGLES2->aglSwapBuffers();
}


Resized Image
(press open in new tab for full size)

So if GL_POLYGON not supported by GLES2, but we can see it, then Regal do emulate it allright. And problem only with QUADS.

Through, as you can see, GL_POLYGON don't looks very the same (like a bit different size, but that can be because of anything, not so matter for now).

And there is log for GL_POLYGON just for:
http://kas1e.mikendezign.com/aos4/Regal/gl_polygon_driver_log.txt

As you can see there is after glBufferData() call, going:
Quote:

driver | glDrawArrays (GL_TRIANGLE_FAN, 0, 5)
driver | glBindBuffer (GL_ARRAY_BUFFER, 0)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 0)


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:

void display() 
{        

    
glClearColor(0.5f0.3f1.0f0.4f);
    
glClear(GL_COLOR_BUFFER_BIT GL_DEPTH_BUFFER_BIT);

    
glBegin(GL_QUADS); 
    
glVertex2i(0,1);  
    
glVertex2i(1,-1);  
    
glVertex2i(-1,-1);  
    
glEnd(); 

    
glFlush();         
    
mglSwitchDisplay(); 
}


Resized Image

But anyway, i tried normal way as well too, of course (see below)

Quote:

May it be that you try to draw a quad with only 3 vertices... ?


I just tried new simple test case for now:

void display() 

     
glClearColor(0.4f0.3f0.3f255.0f);
     
glClear(GL_COLOR_BUFFER_BIT);

     
glBegin(GL_QUADS);
         
glColor3f(0.7f0.8f0.3f);
         
glVertex2f(-0.5f0.5f);
         
glVertex2f(0.5f0.5f);
         
glVertex2f(0.5f, -0.5f);
         
glVertex2f(-0.5f, -0.5f);
     
glEnd();

     
glFlush();

      
//mglSwitchDisplay(); 
     
IOGLES2->aglSwapBuffers();
}



For minigl it works, for regal->ogles nope:

Resized Image

There is new log:
http://kas1e.mikendezign.com/aos4/Reg ... _quads_new_driver_log.txt

And i see, its different. I.e. if for GL_TRIANGLES after glBufferData regal driver do:

Quote:

driver | glDrawArrays (GL_TRIANGLES, 0, 3)
driver | glBindBuffer (GL_ARRAY_BUFFER, 0)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 0)


Then in case with QUADS, it do:
Quote:

driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 256)
driver | glBufferData (GL_ELEMENT_ARRAY_BUFFER, 24, [ 00000000 00000001 00000002 00000003 00000000 00000002 ], GL_STATIC_DRAW)
driver | glDrawElements (GL_TRIANGLES, 6, GL_UNSIGNED_INT, 00000000)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 258)
driver | glBindBuffer (GL_ARRAY_BUFFER, 0)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 0)


Maybe that can explain problems ?

There is also logs for APP and INTERNAL:

http://kas1e.mikendezign.com/aos4/Regal/quads/gl_quads_app_log.txt
http://kas1e.mikendezign.com/aos4/Reg ... gl_quads_internal_log.txt

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:

Quote:

#ifdef __amigaos4__
src << " gl_Position = rglModelViewProjectionMatrix * rglVertex;\n";
#else
src << " gl_Position = rglProjectionMatrix * rglModelViewMatrix * rglVertex;\n";
#endif


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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top


« 1 (2) 3 4 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project