GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

@kas1e
Quote:
Should be. The debug log confirms that the GPU is hanging, and the minimal shader will make tracking down why a lot easier.

Hans

@Hans
Just strange why it lockups, as it looks very basic. Maybe just all the ifs/else/? code was broken at some point and even didn't works for now in NOVA ?

Because if those lines freezes:

if(X>0.0)

X = (Y>0.)?(Y * X * Z.A):vec3(0.);

X = (Y>0. && Y2>0.)?(Z.A):vec3(0.);

Its all didn't looks like only one obscure case.

@kas1e
Quote:
Nope.

I run my test suite before every release, and all tests pass, including one that looks remarkably similar to Daniel's test shader (except it's a fragment shader not a vertex one).

I just reran it again, and all tests are passing as expected. I've also had a look at the generated shader assembly, and haven't seen anything wrong yet. Will have more time to analyse it later...

Hans

@Hans
Maybe just swap in your tests fragment shader on vertex one, maybe it will lockup ?

Quote:

Thanks, gl4es wait for it (and Regal too). Should i create official bz for you, or it enough of what we disscus here ?

@Hans
Quote:
Remarkably similar is not identical and fragment- is not vertex-shader

Quote:
For even more simplicity and so you don't have ogles2 in the middle and no other uniform and no other client code than your own, please do the following (and probably add the result to your list of std. tests):
Take your own W3DNHelloTriangle example that ships with Nova. Don't modify anything but the ColourArray2D.vert shader.

Here's the original shader:



Just change that to:



Compile it using
glslangvalidator -G -o ColourArray2D.vert.spv ColourArray2D.vert
(which is what your makefile does), start the triangle-example -> Freeze.
Needless to say it's the "if" only. If you remove the condition-check and always do gl_Position.x += vertCol.x , then it works.

Preprepared download of this is available here.
Curious what your working test-shaders look like. Can you please put them online?

Good luck!
Daniel

@kas1e
Quote:
Yes, create a bug ticket. You can keep it brief and add a link to the first post in this thread about the issue.

@Daytona675x
Quote:
Very true. Here's my test frag shader:


I'll add a vertex shader equivalent to my test suite as soon as I can.

Hans

@Hans
Quote:

Done!

Just hope it can't take long, as it really problem which make it hard to port regal and gl4es. Polaris drivers are good, but well.. Fingers crossed ! :)

@Hans
Quote:
Sounds as if there's no vertex-shader-with-if test in your suite at all so far?
Okay, that explains why this one slipped through, because if-handling in vertex-shaders is apparently broken so hard that it seems to be impossible to come up with a working one.
And it also explains why your other tests pass - because they all miss the topic

As being said: just use your HelloTriangle example with the modified shader as outlined above and already prepared for you, then you have your vertex-shader-equivalent for your test suite, you don't need to waste time coming up with sth. new.

@all
In meantime, with fast-hacked sdl1 to be build with gl4es instead of minigl, have first primitive game runs on it !

Through, colors is swapped, so time to deal with Endianes in the gl4es (probably).

Legacy MiniGL original:



GL4ES:



To those ones who think now "wtf, why need all those copies of minigl based apps" : that all for tests. Once all minigl based , but compiled over gl4es will works as over minigl, then it will mean that gl4es ready for some ports which minigl can't do, but gl4es at this time will works without bugs => yeah.

@kas1e

Really great work and wonderful progress !!

When I am back in the U.K. on weekend i will send you an email.

@kas1e

Niiice

@all
First round of Endian fixes in GL4ES done! First game which works fully over GL4ES (so OGLES2, but legacy OpenGL call):






Now to something more heavy ..

ps. who can imagine that we can go that far.. If not GL4ES author, i doubt we ever have all that.

Yeah ! Thanks to him.

Let's hope you are not doing all this for nothing and that it will improve speed over MiniGL.

@K-L
Whole amiga work it work for nothing :)

Even if speed will worse, and all will be shit and crap, because of work on gl4es we fix issues in ogles2 and nova, which, will help to all other stuff, even not to gl4es.

And, speed of simple things will not be better, it will be the same. But speed of "heavy" things should be better. In theory :)) As well as can be ported big things which can't be ported on MiniGL.

@all
Bloboats have fps counter, so:

minigl: 123fps
gl4es: 113fps


So, gl4es slower (!) on 10 fps. Through, whole game code of Bloboats its just big chunks of glbegin/glend , and almost no textures, etc => not GPU intensive. We can say it "almost" the same as minigl. For seing real differences, need big, GPU intensive games.

@Hans
I have encountered too the 'if' problem when coding the NovaOnda demo in a frag shader

if(pos.y < waterlevel)
Fail
But if transmitting only a float from vert to frag shader it was working

in float depth;
....
if(depth<waterlevel)

So i mean test on float works but test on struct like vec3 fails

@thellier
Hans fixed "if" problem already

Quote:
Great
The thellier-message above contains way too less information to come to any conclusion though, it doesn't even say if it freezes or if it creates false results or if it doesn't compile, "fail" can be pretty much anything of those.
But since he's talking about a fragment shader and the "if" itself seems to work for him, it's a most likely a totally different thing.
But without full shaders, version info, test-exe, whatever, only wild speculations are possible. Maybe he doesn't even set pos correctly in the vertex-shader, unfortunately one simply cannot tell.

Quote:
Very nice progress with gl4es
113 vs 123 fps? That means that the overhead of gl4es -> ogles2 -> Nova is really low, great!
As soon as you (can) throw sth. fatter at it, MiniGL should "lose" quickly.
Although: you're testing on an X5000, right? Presumably you'd have to throw sth. real big at MiniGL before its software TCL becomes so much of a bottleneck that the netto frame-rate drops so much that gl4es is of true benefit (or in other words: an X5000 is so fast that it can probably handle 95% of all existing MiniGL games so fast that it doesn't make a true difference, at least from game-play experience)

On a system with less CPU power all this would be more interesting. SAM users with SI will certainly benefit from this much more.
Can you please send me your build, then I can measure on my sam460 here.

@Daytona675x
Quote:

Yeah, no probs, there is:
http://kas1e.mikendezign.com/aos4/gl4 ... mes/bloboads/bloboats.lha

There 2 binaries inside, mgl and gl4es one. Gl4es one works in fullscreen mode , and swithing to window crashes, as my fast-hacked-sdl1-to-have-gl4es-in, do not catch all conditions,etc, just for tests.

When you run it, just "enter enter enter" etc, and then inside of game press "f2", and it will show at right uppear side of screen fps counter.

Will be interesting to know how it on your SAM will be and mgl, and gl4es, and mgl-reloaded :)

@kas1e
Quote:
LOL, and my MGLReloaded crashs in fullscreen mode

For whatever reason the MGL-version (no matter if running on top of MiniGL or MGLReloaded), as well as the gl4es version, refuse to run in window mode, only spitting out the message "no double buffer" :P

Anyway, here are the my results for fullscreen (sam460ex, tutorial level 1, pretty identical game situation, after about 30 seconds (fps need some time to stabilize / settle)) :

MiniGL: 81 fps
gl4es: 81 fps

Happy?

Cheers,
Daniel