Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
22 user(s) are online (18 user(s) are browsing Forums)

Members: 1
Guests: 21

NinjaCyborg, more...

Support us!

Headlines

 
  Register To Post  

(1) 2 3 4 ... 43 »
GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@All

As some of you may know, there was another attempt we discuss before which make OpenGL apps to works on OpenGLES, which is called glshim.

I follow that development on the Pyra's/Pandora's forum, there was a pretty nice long discussion of 36 pages of how it all develops, what it can or don't, what games they port over it, and so on

Seeing from comments on GitHub, you may see that since 2016 development has mostly stopped, and in 2017 there was only one commit.

But it's all about glshim originally. Then, at some point (in 2015 or something), another author made a fork of it, and start to develop it further (at the beginning in parallel with glshim, then probably the author of glshim loses interest and only that fork continues to develop).

Name of fork: gl4es
It's quite active even today.

And to have 2 wrappers (Regal and GL4ES) is better than having only Regal, and I give it a go as well.

Structure of the project not as good as Regal's one, and it's depends not only on X11 in a few parts but also on EGL. It also uses CMAKE and not pure Make.

So, i just check how it all builds on Linux, and make a pure makefile for os4 which will build necessary objects, only to realize that X11 can be disabled easily (it is already disabled for Android), while EGL is used much. I then write a ticket for, in case to ask for some clarification, and author says:

Quote:

EGL is used at minimum in 3 places (besides the GLES context creation):

1. At init, to create a small pbuffer to get Hardware information support. This part can be skipped with LIBGL_NOTEST=1

2. For eglGetProcAddress to get extension function adresses.

3. for eglSwapBuffers to swap buffers (actually put drawing onscreen).



I then explain to him that we are at amiga and all that necessary stuff, and, he is still in interest to deal with it! Today he made a commit where add initial NOEGL stuff, and what he wrote about:

Quote:

It should be working for you now.
Some guidelines:

Compile with NOEGL (the NOX11 will be set anyway).
Use with Export LIBGL_ES=2 (or define a DEFAULT_ES=2 at compile time).
You will need to create the GLES context yourself
There is no Hardware checking for capability, so only basic functions will be used
You need to SwapBuffers yourself. To stay on the safe side (because gl4es has many optimizations and may cache/batch drawing calls), it's better to call either glFlush() or glFinish() before the SwapBuffers.


So, all of this is even better for checks: As i, of course, need and want to create GLES context myself, as well as i for myself, want to do aglSwapBuffers().

Through, at moment, not everything handled as needing it with NOEGL, as well as there are other code-compile bugs (strange!), but he seems still to work on, and we can expect something soon!

Stay tuned!


Edited by kas1e on 2022/2/7 15:30:40
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
Some info: we are able to build all objects of main gl4es code, make a link library from it, and even try to link it against test code : have some bunch of undefs which need to be fixed, but proably soon.

Also, he add amigaos4 target as well, so it's all will be in repo.

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


See User information
@all
Do i understand right, that our os4's dlopen/dlsym() will works only for sobjes, and not for real amiga libs ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information
Great work Kas1e !

I can't be of any help with all this stuff but you have all my support, hoping that you'll be able to do something with the final result.

--
AmigaONE X1000 and Radeon RX 560
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information
@kas1e

I can't answer your question regarding dlsym but if you need to find out the function addresses, "use the source": https://github.com/AmigaPorts/sdl2-ami ... SDL_os4opengles2wrapper.c

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


See User information
@Capehill
Yeah, that what exactly i need :)

At moment we have that:
https://github.com/ptitSeb/gl4es/blob/master/src/gl/loader.c

Which of course, will not work probably as imho dlopen/dlsym its all about shared obejects only.

Will try your solution now, thanks !

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


See User information
@Capehill
Can you also point out plz how later it used. I.e. you open somewhere ogles2.library, and when you call AmiGetGLESProc ?

Maybe you can have a look at that loader.c file, and have idea how we can integrate it all there.

That what author answer me about how it works with dlsym() in gl4es:

Quote:

For dlopen/dlsym.
dlopen open an handle, and "load" a dynamic library. Then, with dlsym, you get address of a function based on it's name.
gl4es works like this: for example, if your program use glDrawElements(...)
Because you are linked (staticaly or dynamcaly) to gl4es, you call the glDrawElements(...) from gl4es, that is an alias for gl4es_glDrawElements(...)
This fonction will do some specific stuff, depending on the parameters used (for example, you can call with GL_QUADS that is not supported on OGLES2, but is supported on full OpenGL, and gl4es will handle that as well).
At some point, gl4es will call the "real" glDrawElements(...) from OGLES2 driver, so it will get the function pointer using dlsym(gles, "glDrawElements") and call that function, so the GLES2 driver can draw the things.
All call in gl4es are wrapped in a similar way. You never call function from the GLES2 driver directly. It gl4es that does it. And gl4es will make some optimisation, cache things, and limits the number of calls to GLES2 driver to try get more speed...


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information
@kas1e

The rest of the code should be pretty much here: https://github.com/AmigaPorts/sdl2-ami ... os4/SDL_os4opengles.c#L82

Mind you, it's blindly coded, tested by the few brave..

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


See User information
@Capehill
Ok.. then it mean that ogles2.library should be opened from gl4es, then. Damn, was in hope to avoid it , just to make it same as regal (i.e. no opening of any libraries in, but doing all from users's code)

Now i am abit out of ideas, that what author say:

Quote:

I'm not confident this will work. You will have name collision between the ogles2 function name and gl4es funciton name, that will be the same. That's why I use dlopen on gl4es. the glXXX name of gl4es are the one to be used by the program, and the glXXX name of ogles2 are the one used only by gl4es. But those are the same name, so if you link with both ogles2 and gl4es, how to know wich one to use? Or maybe I haven't understood how that OpenLib works...

I must insist, gl4es is not working like Regal. Regal create some new function, with a different name, where gl4es create full OpenGL functions. I have not created any "mangling" mecanism for gl4es. gl4es is an OpenGL library: you put it in your system and you use OpenGL program without recompiling.

Now, can I just use that AmigaGetGLESProc(...) function from SDL? will it give the ogles2 function pointer without masking the gl4es function?


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


See User information
@kas1e

Use the interface to the ogles2.library directly rather than any stub library, that you might use for compiling simplicity.

eg MiniGL programs are usually linkied against libminigl.a or .so which contains stub functions that call the library calls. I'm assuming that ogles2.librray will work similarly.


olgesSomeFunc() will not then clash with IOgles->olglesSomefunc()


The library *could* be opened in a constructor, it need not be opend in the link lib ne it static or sobj.


The Interface could be extern to the new library and provided in the users code.

the new lib would just need to be compiked with

#include proto/ogles2.h

Adjust al the names to suit obviously


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


See User information
@broadblues
Thanks ! That was helpfull.

@All
Library done, author add amigaos4 bits, fixing for now some last issues. Some amigaos4 feteshism:

Resized Image

First test code even was compiled against it!:

Quote:

ram:> a.out
LIBGL: Initialising gl4es
LIBGL: v1.0.5 build on Feb 17 2018 12:36:08
LIBGL: Using GLES 2.0 backed
LIBGL: Hardware test disabld, nothing activated...
LIBGL: warning, gles_glGetIntegerv is NULL


But that for pure:

#include "include/GL/gl.h"
#include <proto/ogles2.h>

int main()
{
glBegin GL_POLYGON );
glEnd();
}


So kind of expected, but that quite step. Probably very soon we will see something rendered !


Edited by kas1e on 2018/2/17 10:56:51
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@all
Who is your daddy?:)

Resized Image

Source: http://kas1e.mikendezign.com/aos4/gl4es/test2.c

As you can see, there in source i didn't open ogles2.library, and didn't worry about interfaces and stuff: that done inside of gl4es.

Also as you can see, QUADS which should be drawns : didn't. That can make probably that gl4es shaders fail on NOVA's shaders. That to be checked.


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


See User information
@all
Resized Image

That was pain ! It was _much_ harder than Regal. Main author spend 2 full days on adding os4 support, finding bugs, fixing stuff, etc.

But good news : its all in repo. Even cmake updated to have amigaos4 target. Through, at moment i use pure sh script, which is easy for fast test.

Few more bugs to fix, and then same speed test to see if it faster or slower than Regal in same test case

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


See User information
@all
Ok all initial bugs fixed, and so to the same speed tests we do with Regal, MiniGL and MiniGL-Reloaded.

There is source: http://kas1e.mikendezign.com/aos4/gl4 ... _tests/gl4es_speed_test.c
There is binary compiled over gl4es: http://kas1e.mikendezign.com/aos4/gl4 ... ests/gl4es_speed_test.zip

Now, result is:

GL4ES:

Quote:

21483 frames drawn, for a total of 8169.000000 milliseconds
Took approximately 0.380254 milliseconds per frame
Avarage FPS: 2629.820051
Took approximately 0.474701 milliseconds per frame (with swap)
Avarage FPS (with swap): 2106.589527


And as i post in Regal's topic:

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:

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 you see, the result is much better than with Regal. Its on pair with MiniGL, which , do not be confused, very good result for such a simple test case because of reassons Daniel wrote in Regal's topic (slow first frame, too simple code, so not show potential of overload and so on).


@Daniel

Can you plz run that test on your Sam, so we will see how it in compare with MiniGL reloaded. Probably on the same level, or even better a little ?

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


See User information
@kas1e

Wonderful !!
followed a bit the discussion there and it was nice to see how much he was availible to help you

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


See User information
@All
Need some help.

There is test case: http://kas1e.mikendezign.com/aos4/gl4es/test_crash.c

ogles2.library and interface opened in the gl4es.a itself.

So, once i try to run it as it, it freeze amigaos. But not all the time on the same place. Sometime, it go till initialising gl4es, and then crash (so, even didn't touch a part of code where we do amiga stuff at all), sometime go futher and then crash right after i open window.

Of course for sake of tests tried to use bigger stack size too.

Then, once i start remove parts of code (different ones), it works. But not the same parts of code.

Its like the more code i have (does not matter what functions, etc, just more code), then it crashes.

For example, i may comment some parts in the main() : don't crash. Or may comment some parts in draw(), while keep what was commented in main : don't crash.

I.e. commenting out different parts of code, to make code of binary smaller (probably, i am not sure), make it not crash.

Its like some overbound/overflow/dunno what somewhere. But something general.

Have anyone any idea to where look at ? I mean that kind of symptoms can cause what ?

It also seems, that putting Delay() all over place, can make difference for point when crash happens. And that remind me some racecondition issues .. Maybe still that we open library and interface in the libgl4es.a itself, and in programm use just as it OGLES2, make problems ?

That the way we integrate it (taken from SDL2 as reference):
https://github.com/ptitSeb/gl4es/blob/master/src/agl/amigaos.c
https://github.com/ptitSeb/gl4es/blob/master/src/agl/amigaos.h

But that can be not the case of course ..


Edited by kas1e on 2018/2/18 7:16:48
Edited by kas1e on 2018/2/18 7:29:58
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Now, this looks even more promising as Regal
Checked your binary on my sam460:

Quote:

LIBGL: Initialising gl4es
LIBGL: v1.0.5 built on Feb 17 2018 23:41:49
LIBGL: Using GLES 2.0 backend
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Hardware test disabled, nothing activated...
LIBGL: Targeting OpenGL 2.0
LIBGL: Current folder is:RAM Disk:
20457 frames drawn, for a total of 11217.000000 milliseconds
Took approximately 0.548321 milliseconds per frame
Avarage FPS: 1823.749666
Took approximately 0.652686 milliseconds per frame (with swap)
Avarage FPS (with swap): 1532.130018


So on my side all the msec results for this test are (smaller = better):
Quote:

MiniGL: 0.488850
gl4es: 0.548321
MGLReloaded: 0.571977
Regal: 1.109902


So with this test it's a bit faster than my current MGLReloaded and, no surprise, slower as original MGL.

Didn't compare Regal vs gl4es, but if the feature-set is more or less identical I would concentrate on gl4es if I were you (also because the author apparently is both active and helpful)

Quote:
So, once i try to run it as it, it freeze amigaos. But not all the time on the same place.

From a quick look, you only defined 6 normals for 8 vertices.

Quote:

glFlush();
IOGLES2->aglSwapBuffers();
glDrawBuffer(GL_BACK);
display();
glDrawBuffer(GL_FRONT);


What is that supposed to do?
It should just be:

Quote:

display();
IOGLES2->aglSwapBuffers();


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


See User information
@Daytona675x
And the size of binary lots smaller than regal one. Through in terms of compatibility regal should be better, but that to be checked. Gl4ES mostly for opengl1.5 and 2.0 for moment , but author optimize and fine tune it very well (at least better than Regal). He even say that arrays in shaders always not so fast, and he get rid where it possible of them in the generated shaders.


As for crash: sure, gl-code-wise it can be wrong, but it works copy of minigl example, and even if call some stuff which make no sense to call, it shouldn't crash so heavy in different places (most of time right after open of window).

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another 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:
As for crash: sure, gl-code-wise it can be wrong, but it works copy of minigl example,

The normal array has to be larger and filled with correct normals, otherwise you are at least doing illegal memory reads with potentially trashed data.
And you know what trashed data for a normal likely is? Most likely not a normal anymore And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal.
Please fix the normal-array and try again.

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


See User information
@Daytona675x
Quote:

And you know what trashed data for a normal likely is? Most likely not a normal anymore And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal.





Quote:

Please fix the normal-array and try again.


Funny thing is that "random" crash wasn't random. Its just i run test case from shell, and window which opened put shell window behind the gles2 window, and while aglSwapBuffers() not done, there is copy of the screen in the window. So, i watch on that window thinking that there is just few printfs, while they go futher in the shell behind the window, which make me think nothing happens :)


It still strangely crashes: if i put bunch of printfs in Drawbox() before and after every gl call, then, its make 3 loops, and then crashes. But will firstly try to fix normales.

Probably it didn't crash in Regal before, because for that example Regal create shaders with arrays (and so nothing draws, but didn't crash), while, GL4ES create shaders without arrays -> code tryin to executes -> crash.

Through that only suggestion until didn't fix normales, maybe it bug in gl4es's glMatrixMode (as it works in MiniGL after all..). Will see now

@Daniel
Btw, just to be sure its not in spam box : did you recieve reports on mail about glGetActiveUniform(...) and glGetActiveAttrib(...) ?


Edited by kas1e on 2018/2/18 10:18:52
Edited by kas1e on 2018/2/18 10:20:09
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
(1) 2 3 4 ... 43 »

 




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




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project