Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
110 user(s) are online (72 user(s) are browsing Forums)

Members: 1
Guests: 109

TheMagicSN, more...

Headlines

 
  Register To Post  

« 1 2 (3) 4 »
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Hmm, too bad, would have been an easy solution to the problem that you don't see quads because you forgot one vertex

Quote:
That probably can explain not accurate emulation of polygon :)

No, actually emulating GL_POLYGON via triangle-fans is the most common and a pretty good way to do it (and that's actually the way it is implemented in many drivers anyway).

Quote:
but in MiniGL, even that "broken" code works

No need to put the "broken" into quotation marks, it *is* broken and it actually should not render anything AFAIR the standard even says that incomplete primitives are not being rendered.

From your quad-log
Quote:
glDrawElements (GL_TRIANGLES, 6, GL_UNSIGNED_INT, 00000000)

This looks plausible, two triangles are being drawn to emulate the quad.
Your coordinates look okay too, the winding is the same as for your triangles, so it should not be culled. Unless Regal creates two triangles with the wrong binding?!
What happens if you glDisable(GL_CULL_FACE) before the glBegin()? Other than that: no idea.

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Daytona675x
Quote:

No, actually emulating GL_POLYGON via triangle-fans is the most common and a pretty good way to do it (and that's actually the way it is implemented in many drivers anyway).


Strange then why it looks different visually on the same 640x480 area.

Quote:

What happens if you glDisable(GL_CULL_FACE) before the glBegin()?


No difference..

Quote:

Other than that: no idea.


Its just something general and its for sure somewhere in the RegalQuads.cpp/RegalQuads.h. Maybe some endianes differences arise somewhere.

And internal log looks quite ok too imho:

Quote:

internal | Regal::Iff::UpdateUniforms 64ae2008
internal | Regal::Emu::Quads::glDrawArrays( GL_QUADS, 0, 4)
internal | Regal::Emu::Quads: shadeMode = GL_SMOOTH
internal | Regal::Emu::Quads: windingMode = GL_CCW
internal | Regal::Emu::Quads: provokeMode = GL_LAST_VERTEX_CONVENTION
internal | Regal::Emu::Quads: convention = false
internal | Regal::Emu::Quads: frontFaceMode = GL_FILL
internal | Regal::Emu::Quads: backFaceMode = GL_FILL
internal | Regal::Emu::Quads: cullingFaces = false
internal | Regal::Emu::Quads: cullFace = GL_BACK
internal | Regal::Emu::Quads: drawQuads = true
internal | Regal::Emu::Quads: drawLines = false
internal | Regal::Emu::Quads: drawPoints = false
internal | Regal::Emu::Quads::glDrawArrays glDrawElements(GL_TRIANGLES,6,GL_UNSIGNED_INT, [])


Btw, may it be theoreticaly differences between ogles implementations ?

Quote:

Unless Regal creates two triangles with the wrong binding?!


Dunno, its here: https://github.com/p3/regal/blob/master/src/regal/RegalQuads.cpp

Probably with my knowledge of things, the only way is just to put printfs everywhere, to see what part executes, then we will have something..


Edited by kas1e on 2018/2/14 23:07:07
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Just popping in


See User information
@kas1e

Congratulations on getting this working!

Regard
Doug


Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Congrats on getting this far! GLSL arrays support is definitely top priority for Warp3D Nova.

Nothing sticks out as wrong in the Regal logs. The vertex and index array data are what you'd expect them to be, and the glDrawElements() call looks right.

I'm surprised how wasteful Regal is, though. There's no reason to be creating all 16 vertex attrib arrays when you're only using one. I'm pretty certain that Daytona's MiniGL reloaded will be faster for legacy pre-shader stuff...

Mind you, Regal's quite an ambitious project, and there's a lot more that they're supporting than just the old fixed pipeline.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Okay, I just noticed something odd in the log. It does this:

driver | glBindBuffer (GL_ARRAY_BUFFER, 257)
driver | glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, 258)

... then a bunch of other stuff ...

then it calls glBufferData(GL_ARRAY_BUFFER,...) for the vertex array:
driver | glBufferData (GL_ARRAY_BUFFER, 1024, ..., GL_DYNAMIC_DRAW)

That should work, but it's a very odd order of operations. Normally you'd do this:
driver | glBindBuffer (GL_ARRAY_BUFFER, 257)
driver | glBufferData (GL_ARRAY_BUFFER, 1024, ..., GL_DYNAMIC_DRAW)

Perhaps the binding of the element array between those two is confusing our GLES2 lib?

It's a long shot, but worth taking a quick look at...

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@ Daytona675x
>That's all wrong.
>from the stoneage.

Could you have answers not so raw and pretentious (in a word "not so german")
Hans & Huno certainly have as much skill as you and always show a Zen attitude
By advance thanks to you : It's only to make life better to everyone

Alain

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@Hans
Quote:
I'm pretty certain that Daytona's MiniGL reloaded will be faster for legacy pre-shader stuff...

Yes, MiniGL Reloaded creates pretty optimal shaders and the whole lib is much more compact / tuned for performance.
Quote:
Regal's quite an ambitious project, and there's a lot more that they're supporting than just the old fixed pipeline

Yes, MiniGL Reloaded's aim is somewhat different to Regal's goal:
My MiniGL Reloaded "simply" wants to be a turbo-booster for MiniGL programs, using what we got now, whereas Regal wants to bring full desktop-OpenGL to systems with full OpenGLES2 / GLSL support.

Quote:
Perhaps the binding of the element array between those two is confusing our GLES2 lib?

While ogles2.library should not be confused by that command order I can of course not rule out that something goes wrong in my lib

@thellier
Nehe tutorials are from the stoneage and what you said was wrong and involved bad advices that had the potential to put kas1e into more trouble, therefore clear words were adequat. Plus I don't like you for reasons you certainly know, so I won't try to use even nicer wording just to make you feel more comfortable. But I'm sure you can live with that.
Now back on topic:

@kas1e
Please mail me your stuff (executable of the quad example is enough) so I can take a look here with a diagnostic build of ogles2.library!


Edited by Daytona675x on 2018/2/15 9:35:00
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
That may be it:

From the OGL ES 2.0 specs (which I comply to),
glDrawElements, type parameter:
Quote:
Specifies the type of the values in indices. Must be GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT.


But in Regal's quad emu you find this (RegalQuads.cpp, line 331):
Quote:
dt.call(&dt.glDrawElements)(GL_TRIANGLES, n*6, GL_UNSIGNED_INT, 0);


This is not legal ES 2.0 code, GL_UNSIGNED_INT is clearly not supported by the specs and therefore not in my ogles2 implementation. This glDrawElements - call will fail if it is parametrized like that.

However, it wouldn't be too hard to extend the library to swallow this.

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Daytona675x
I was about to upload test case binary :) But just in case so we can be sure:
http://kas1e.mikendezign.com/aos4/Regal/quads/testdbany_gles.zip

(big size because of debug, logs, and all crap)

EDIT: can confirm that probably you are right. I just for first trying do swap GL_UNSIGNED_INT on GL_UNSIGNED_BYTE - nothing draws, but then, i swap it on GL_UNSIGNED_SHORT - and it draws, just not quad, but some kind of triangle, but that expected imho, as short/byte 8 and int 16.

@Hans
Quote:

I'm surprised how wasteful Regal is, though. There's no reason to be creating all 16 vertex attrib arrays when you're only using one. I'm pretty certain that Daytona's MiniGL reloaded will be faster for legacy pre-shader stuff...


I will put it all in next few days on github, with all amiga-ready-to-build stuff, so anyone will be able to clone it, and just "make SYSTEM=amigaos4 MODE=debug V=1" and library will be ready to use.

Then, any of us can "speedup" it even a bit. For example that what you notice "creating all 16 vertex attrib arrays when you're only using one".

@All

How to measure FPS in easy way without much code ? I have for SDL SDL_Ticks(), which i can use with SDL like this:

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(); 
    
        
    
IOGLES2->aglSwapBuffers();
    
    
/* Gather our frames per second */
    
Frames++;
    {
    
GLint t SDL_GetTicks();
    if (
T0 >= 5000) {
        
GLfloat seconds = (T0) / 1000.0;
        
GLfloat fps Frames seconds;
        
printf("%d frames in %g seconds = %g FPS\n"Framessecondsfps);
        
T0 t;
        
Frames 0;
    }
    }
}


So i need or to replace SDL_GetTicks() on amiga specific code, or just some replacement function, so i will have in console FPS printfs.

Want this for compare the same source code over MGL and Regal->OGLES2


Edited by kas1e on 2018/2/15 12:28:29
Edited by kas1e on 2018/2/15 12:29:31
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Try this:

- change line 283:
GLuint indices[EMU_QUADS_BUFFER_SIZE * 6];
to
GLushort indices[EMU_QUADS_BUFFER_SIZE * 6];


- change line 329
dt.call(&dt.glBufferData)( GL_ELEMENT_ARRAY_BUFFER, n * 6 * sizeof( GLuint ), indices, GL_STATIC_DRAW );
to
dt.call(&dt.glBufferData)( GL_ELEMENT_ARRAY_BUFFER, n * 6 * sizeof( GLushort ), indices, GL_STATIC_DRAW );


- change line 331:
dt.call(&dt.glDrawElements)(GL_TRIANGLES, n*6, GL_UNSIGNED_INT, 0);
to
dt.call(&dt.glDrawElements)(GL_TRIANGLES, n*6, GL_UNSIGNED_SHORT, 0);

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Daytona675x
Resized Image

Yammy ! Thanks a bunch for worry !:)

Through, i do check on glDrawElements() in whole Regal sources, and there is quite a lot of place where it called, and, with GL_UNSIGNED_INT all the time :(

Sure, it's out of specs, but will it worth of to change library's code so it will take INT's too ?

EDIT: checked 2.0 specs and 3.0, 3.1 and 3.2, starting from 3.0 and up, it takes GL_UNSIGNED_INT.. So probably author of Regal or take it as granted, or, realisation of drivers where he work on, even if give GLES2 drivers, use some bits of GLES3.

But at least it will be not hack if you add INT, just again work to make ogles2 be ogles3 :))

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e

Great - and phew because it's no bug in my lib but a bug in Regal.
Since Regal claims to be a OpenGL layer explicitely for ES 2.0 this specs violation is a clear bug.

However:
you should *not* change Regal's code here and better revert the changes you just did for the purpose of this test.

I will tell Matthew about this issue and suggest to quickly enhance my OpenGLES2.library to support uint32 indices too, although that's OGLES 3 and not OGLES 2.

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Daytona675x
Quote:

I will tell Matthew about this issue and suggest to quickly enhance my OpenGLES2.library to support uint32 indices too, although that's OGLES 3 and not OGLES 2.


Yep ! Just he should know how important that are, to make fixes to support Regal.

Btw, maybe it worth to rename ogles2.library to ogles.library then ?:)(current software which used it, can rename it not big deal). Just it already has some gles3 features, and probably (?) will have more with time, so we will have ogles.library which currently mean ogles2 with partial ogles3, and someday maybe ogles2+ogles3 (and, SDL2 no need to be changed as well, when and if there will be ogles3.library) :)

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Quote:
Btw, maybe it worth to rename ogles2.library to ogles.library then ?

No, it'll remain ogles2.library, because that's what it is and what it will still be.
OpenGL ES (alone, without 2 or 3) is sth. *completely* different, it is a fixed function pipeline implementation much like desktop OpenGL 1.x

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information
Here is another GL wrapper. I haven't tried it but according to description it might support OpenGL 1.5 via OGLES 2.0.

https://github.com/ptitSeb/gl4es

EDIT: it's a small world, checked the issue tracker..

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Capehill
:)) if he will do what i ask him, then we will have 2 wrappers :) but when i yesterday works on it code layout much worse and hacky in compare with regal

I want currently test some examples over mgl and regal-gles2, which give fps counter. Maybe you have some for mgl without glut ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

Congrats on the further progress.

BTW, the shader compiler bug that prevented uniforms from being multiplied together is already fixed.

So the biggest barrier now is lack of array support...

Quote:
Then, any of us can "speedup" it even a bit. For example that what you notice "creating all 16 vertex attrib arrays when you're only using one".

Sounds good, although fixing it is harder than it sounds. MiniGL actually does something similar, where it has a static vertex structure that's designed for the max number of texture units. So the vertex array that's sent to Warp3D consumes more memory than needed, meaning it's less likely to fit in CPU caches and can't take advantage of fast consecutive memory reads.** This is especially true with CPUs that have smaller data caches.

Hans


** Reading memory in ascending order with no gaps tends to be very fast.

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
I just added the OGLES3 feature to support uint32 indices with glDrawElements to ogles2.library.
It's available on my FTP for ogles2 beta-testers now, including you. Give it a try

Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Daytona675x
Thanks a bunch ! Will test it now.

@All
In meantime, i do check speed differences. As example i take nehe's lesson5 example (which, can be crap of course, but as we test speed of emulation can be ok).

So, i port it to mgl and to regal->ogles2 from sdl and you can download binaries and sources there:

MiniGL:
src: http://kas1e.mikendezign.com/aos4/Reg ... _tests/nehe_lesson5_mgl.c
binary: http://kas1e.mikendezign.com/aos4/Reg ... ests/nehe_lesson5_mgl.zip

REGAL->GLES2 (no debug version, so output didn't slow things down):
src: http://kas1e.mikendezign.com/aos4/Reg ... tests/nehe_lesson5_gles.c
binary: http://kas1e.mikendezign.com/aos4/Reg ... sts/nehe_lesson5_gles.zip


You just run it, wait let's say 20-30 seconds, and then close by close gadget, and in console (from where you run them), you will see printfs about fps and stuff.


For me, in current form, and on that example, regal is slower :(

My results:

MiniGL:

Quote:

27488 frames drawn, for a total of 10097.000000 milliseconds
Took approximately 0.367324 milliseconds per frame
Avarage FPS: 2722.392790
Took approximately 0.470714 milliseconds per frame (with swap)
Avarage FPS (with swap): 2124.430018


Regal over GLES2:

Quote:

32814 frames drawn, for a total of 16080.000000 milliseconds
Took approximately 0.490035 milliseconds per frame
Avarage FPS: 2040.671642
Took approximately 0.587737 milliseconds per frame (with swap)
Avarage FPS (with swap): 1701.441460



As can be seen , minigl give 2124 fps, regal->ogles2 1700. I was in hope to see something like 5000 for regal->ogles2 at least :)

Through, to note, that is with fix about gl_int/gl_shorts which we tests yesterday, but imho that can't be reassons of that difference.

@Daniel
If you can, maybe you can throw minigl binary version over your minigl-reloaded, to see what we will get with ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Such simple benchmarks are pretty useless.
The number of vertices is so small that the time spent in MiniGL's software TCL->W3D-code is probably lower than Regal's Emu->OGLES2->Nova-code.
Also note that the very first frame may probably take quite some extra time for Regal, because that's the frame where it will prepare the required shaders.

However, here are my results (sam460ex, some low-end SI):

Quote:

Regal:
21046 frames drawn, for a total of 23359.000000 milliseconds
Took approximately 1.109902 milliseconds per frame
Avarage FPS: 900.980350
Took approximately 1.285803 milliseconds per frame (with swap)


Quote:

MiniGL:
31525 frames drawn, for a total of 15411.000000 milliseconds
Took approximately 0.488850 milliseconds per frame
Avarage FPS: 2045.616767
Took approximately 0.621570 milliseconds per frame (with swap)


Quote:

MiniGL Reloaded:
34108 frames drawn, for a total of 19509.000000 milliseconds
Took approximately 0.571977 milliseconds per frame
Avarage FPS: 1748.321288
Took approximately 0.692096 milliseconds per frame (with swap)



So here Regal is by faaar the slowest.
Classic MiniGL is fastest.
My MiniGL Reloaded is close.

MiniGL Reloaded and Regal have to do the same job in that case here (and both will suffer from the first frame being significantly slower than the others).

But in contrast to Regal my MGLReloaded sits directly on top of Nova, so it has one layer less.

However, ogles2 already contains optimizations MGLReloaded still doesn't have, it's still work in progress and actually not optimized at all yet... (e.g. in this example here ogles2 will detect that the internal vertex-arrays didn't change so it won't issue a VBO update).

So if you want to draw a conclusion out of those tests then maybe that if comparing Regal vs MGLReloaded one can asume that Regal itself is coded very sub-optimal.

Quote:
Through, to note, that is with fix about gl_int/gl_shorts which we tests yesterday, but imho that can't be reassons of that difference.

No.


Edited by Daytona675x on 2018/2/16 8:59:49
Go to top

  Register To Post
« 1 2 (3) 4 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project