@Daytona675x :)) to be happy it should be 81 vs 235 or something of that sort :) at moment it start to looks like that speed of titles which works on minigl will works same speed over gl4es as they most of time not gpu heavy. Through without technical knowledge, i was expecting boost everywhere, taking in account what kind of gfx boards we have.
Should something like quake2 , for example, give boost over minigl in pure fps compare ? I mean it theory at least, can it be that minigl version will give 80 fps, but gl4es one, 250 ?
Edited by kas1e on 2018/2/25 20:26:38 Edited by kas1e on 2018/2/25 20:34:13 Edited by kas1e on 2018/2/25 20:36:32
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
I've already got multiple "Pos.x < something" style tests, and they're working. So something else must be the matter.
If you have something that you're convinced is a shader compiler bug, then please submit a report via http://amigadeveloper.com/bugreports/ (make sure you assign the bug to me, or I might miss it).
Should something like quake2 , for example, give boost over minigl in pure fps compare ? I mean it theory at least, can it be that minigl version will give 80 fps, but gl4es one, 250 ?
I'd expect Quake2 to be faster in GL4ES because it's got a lot more vertices than the simple tests you've done so far, and more complex lighting too. That's where the computation time of doing TCL on the CPU really starts to add up.
@all While wait for some necessary fixes in ogles2/warp3dnova (mostly warp3dnova), do play a little with other games. And found one which i port some eyars ago, called "Cadog Adventure" (for minigl, of course).
On that time, i has to fix it a bit to make it works, as minigl do not support some of opengl stuff game use, but then, with gl4es, it compiles just as it, without needs to touch code !
Through, from gl4es side there was some more "endian" fixes. As at first try it was like this:
Now all is fine, as in first screenshot.
All of this, make me think about Regal a bit: if Regal do not worry about big-endian cpus (what very-very possible), we will have hard times to do endian fixes :) But that to be seen once we done with gl4es.
Ah, and we also add "hardware test" for amigaos4 version too (before we disable it , to make initial things works), and that what we have :
Quote:
LIBGL: Initialising gl4es LIBGL: v1.0.5 built on Feb 27 2018 01:38:02 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Targeting OpenGL 2.0
LIBGL: Hardware limited NPOT detected, and so used LIBGL: FBO are in core, and so used LIBGL: PointSprite are in core, and so used LIBGL: high precision float in fragment shader available and used LIBGL: Max vertex attrib: 16 LIBGL: Max texture size: 16384 LIBGL: Max Varying Vector: 32 LIBGL: Texture Units: 8(8), Max lights: 8, Max planes: 6
On what author of gl4es says:
Quote:
Not a lot of stuff (sadly no Cube Maps for example). In fact, it seems there is mostly no extensions detected, so that's a bit strange. I was expecting to see a few stuff like GL_OES_element_index_uint, GL_OES_texture_float, GL_OES_packed_depth_stencil or maybe even GL_EXT_frag_depth.
It's extension, they are out of main gles2 spec. But I was expecting some of them. It's ok if they are not there. But better if they are present.
Edited by kas1e on 2018/2/27 7:32:58 Edited by kas1e on 2018/2/27 7:39:20
@all Another + to the gl4es (but probably there to OGLES2) -> all resziing of window content done under the good. I.e, with minigl , you create resizable window, and then, draw something in. Then, if you resize window , window resizes, but content are not.
With olges2 whole content resizes always, and seems didn't make any problems with speed. That really looks handy !
@Daniel Is it ogles2 which handle internally all that content-resizing ?
@kas1e Regarding GLES2 extensions in general: Extensions are what their name implies: not mandatory, no core GLES2, not required. And they usually don't just fall out of thin air, they usually mean additional effort
Therefore I will add extensions only if all of the following conditions are true:
- somebody actively asks for them (just like you did with GL_UNSIGNED_INT for glDrawElements). - it's a reasonable request. - Nova supports it. - I can do it. - a-eon says "do it".
Regarding the GLES2 extensions string: it's indeed just empty until now - either simply because there was nothing to add or there's no common extension string that fits the few existing addons or because I forgot to extend the string
- "no Cube Maps for example": ogles2.lib actually contains everything to support cube-maps because it's core GLES2. However Nova doesn't support it yet, which is why glGet(GL_MAX_CUBE_MAP_TEXTURE_SIZE) will return 0 although it should not. Once Nova supports it it will work automagically in ogles2.library (unless I made a mistake while coding it blindly ).
- GL_OES_element_index_uint: that ext-string will be inside for the next update, I forgot to add it when I added that feature for you some days ago.
- GL_EXT_frag_depth: supported for quite a long time already, I just forgot to add that to the ext-string (actually I wasn't aware that there even existed an extension string for it ), will be inside next update.
- GL_OES_texture_float: not supported because nobody asked for it yet, but if I'm not mistaken Nova supports it, so it's technically possible already.
Then there are some features that are only partially supported, so that I cannot really add the matching extension string, one example being:
- GL_OES_texture_npot: while NPOT textures including all wrap-modes are supported, mipmapping of those doesn't work reliable yet (since v1.17 ogles2 will silently disable mipmapping for such textures if you request it).
Quote:
With olges2 whole content resizes always, and seems didn't make any problems with speed.
Your test progs are far far away from becoming fill-rate-bound.
Quote:
Is it ogles2 which handle internally all that content-resizing ?
If you supplied a window pointer then ogles2 will internally detect window size changes and adjust the back-, depth-, etc-buffers accordingly. If this happens it will also automatically adjust the viewport to match the new window dimensions.
Quote:
I mean it theory at least, can it be that minigl version will give 80 fps, but gl4es one, 250 ?
Here I gave you some hints how to quickly come up with something that puts more pressure on MiniGL. However, as being said: you'd probably have to put really a lot of pressure to it because your X5000 is so fast that it can crunch even a huge amount of software TCL just like that. I wouldn't wonder too much if even Quake2 doesn't result in such a big difference as you hope for. At least not on an X5000. On a sam460 or so this will certainly be different.
@broadblues I do not say it unpossible (even some of ports i do have the same ability to be resized over minigl). I just compare the same test cases, where i have no needs to worry about "how to code right", it just works as it with ogles2.
There is just builded version of Cadog Adventures for MiniGL directly, and over GL4ES (so ogles2), running in window mode, and then, resized.
MiniGL There you can see untouched game's souce code, builded with MiniGL directly, and so, resized window from initial 640x480:
You can see , that there is just all going to mess, once you resize window.
GL4ES (so ogles2) There you can see the same 1:1 souce code, builded with gl4es, and so, resized window from initial 640x480:
The main point: the same, unmodified source code. Taking aside that minigl version have some bugs by default which i had to fix before when make a os4depot release some years ago.
I mean, even if speed of the same "old" titles, will be the same as with MiniGL, its anyway already better, then, even in that particular case.
@Hans Plz consider to make fast fix for "Shader attribute expansion to four components" , as almost everything rely on it.
Note: that's no bug-fix, but a feature request for Nova!
Strictly spoken it's a specs violation in ogles2.library, because the GLES2 specs defined that behaviour, not the Nova specs! Considering that Nova currently strictly enforces shader attributes variables to be of the very same type as the attributes sent by the client-app, it would actually be ogles2.lib's job to adjust such data before sending it to Nova. However, the potential performance impact would be high if doing that in ogles2.lib. I originally thought about making it optional in ogles2, so that coders who write their shaders with strict type matching wouldn't get "punished". But luckily Hans told me that it's practically for free inside Nova, that's why he was kind enough to take this on his shoulders.
Quote:
Going more heavy, trying quake3, first run of course mess, burn and amiga1200:
Keep calm, step by step We just got Cadog up and running and you come with Quake3
Regarding the MiniGL vs. gl4es/ogles2 window resizing thingy from above: it's unfair to say that MiniGL would do something wrong / that gl4es/ogles2 would do something better here And, as you'll see, it's not even true:
- AFAIK the original game's window is not resizable, so it's absolutely valid that the author didn't implement proper resizing. - MiniGL, as every other GL implementation, has functions to take care. If you use MGLResizeContext and glViewport on resize, then all is fine. - ogles2.lib doesn't need something like an explicit MGLResizeContext. That's just a different convention compared to MGL. In MiniGL you must call this function on window resize, in ogles2 it's done automatically. Both ways of doing it are equally good / bad / legal. - ogles2.lib automatically adjusts the glViewport internally, as if you had attached the window to the context for the first time. But ...:
Actually this is incorrect behaviour and I did just remove it It was most likely a relic from the very first versions to enforce sane values for the viewport during development / testing. Although you apparently liked that behaviour, it's unfortunately bad, because depending on your game's code flow it could actually interphere with your own glViewport calls...
Keep calm, step by step We just got Cadog up and running and you come with Quake3
:) As far as i see, quake3 not _that_ heavy by gl calls, so probably should be ok. At least author of gl4es, have ported quake3 to gl4es and it working. He will recheck it today, just to be sure that gl4es is ok (but even if, it also can be endianes which somehow make problems).
Problem throuh happens not even in game itself, just in the menu. I.e. when begining "shooting to ID" movie ends, and we should have "ENTER CD KEY, ACCEPT", we have intead that mess as on screenshot.
As far as i see there is nothing heavy happens, shaders are primitive ones, a lot of texture2d stuff, etc..
Quote:
- AFAIK the original game's window is not resizable, so it's absolutely valid that the author didn't implement proper resizing.
By default resizing was there in Cadog (i mean window was created with resizing gadget, by game's author), but no code for car eabout. Its just me disable gadget years back as it didn't works as it for minigl. It probably works for win32 SDL/their drivers as it, and their driver deal with it, as was ogles2, before :)
Quote:
Actually this is incorrect behaviour and I did just remove it It was most likely a relic from the very first versions to enforce sane values for the viewport during development / testing. Although you apparently liked that behaviour, it's unfortunately bad, because depending on your game's code flow it could actually interphere with your own glViewport calls...
Not that i worry that much about resizing in games, authors of which do not handle it as they should, but then it mean that for games ports we will have again the same issues. As probably, for most platforms drivers do what ogles2 driver do before you remove it , and that probably reassons why in many games authors didn't add such a code to games itself, as it "just works". But i can be wrong of course.
Sadly of course, but not big deal, just no resizing for games which ones do rely on drivers which will do so for them :)
Good news is that i found, that when i _disable_ GL extensions in the ioquake's settings, it all start to work:
As we have in ogles2 not many extensions, and that what quake3 found when build on gl4es:
Quote:
Initializing OpenGL extensions ...ignoring GL_EXT_texture_compression_s3tc ...GL_S3_s3tc not found ...using GL_EXT_texture_env_add ...using GL_ARB_multitexture ...using GL_EXT_compiled_vertex_array ...GL_EXT_texture_filter_anisotropic not found
Then, there is just 3 candidates for such distortion mess: GL_EXT_texture_env_add, GL_ARB_multitexture and GL_EXT_compiled_vertex_array.
Good there also that renderin almost without glitches which need to fix, what mean that gl4es/ogles there do things right. But (!)..
Bad news, it give 5 fps only in the place where minigl give 22fps :( While i of course expect about 60-70 at minimum, but was in hope to see about 200 or something.
Something is for sure wrong somewhere.
EDIT: I was able to build Capehill's old ioquake3 which is not based on SDL (pure minigl rendering), where i just swap it all on gl4es-ogles, and , as result, the same 5fps. So, we can rule out SDL1 as potential perfomance penalty.
Edited by kas1e on 2018/2/28 18:40:22 Edited by kas1e on 2018/2/28 18:42:26 Edited by kas1e on 2018/2/28 19:04:21
@Capehill Sorry, i don't understand. What,where,how ?:) Is it quakes3's some flag on compilation, or where/how/what to do to enable it ? As far as i can see, i can't choice from quake3's menu what extensions to disable or to enable. They or disable all, or enabled all.
You wrote earlier that you disabled GL extensions. So is there one master switch or how? From your log:
Initializing OpenGL extensions ...ignoring GL_EXT_texture_compression_s3tc ...GL_S3_s3tc not found ...using GL_EXT_texture_env_add ...using GL_ARB_multitexture ...using GL_EXT_compiled_vertex_array ...GL_EXT_texture_filter_anisotropic not found
@Capehill No, there wasn't master swtich, but then i do disable GL_EXT_compiled_vertex_array in the gl4es, recompiled it, recompile quake3 with it, and then no distortion !
In other words, you are right its GL_EXT_compiled_vertex_array which make things looks messy. Probably that one to report to Daniel..
Thanks for point!
Throuh main problem, is that fps in 4 times lower than in minigl. That show that somehitng really wrong somewhere ..
Put more emphasize on the good news The rendering output looks almost perfect.
@Capehill Quote:
What if you enable compiled vertex arrays?
Yes, that was my first thought too.
@kas1e / all However, even without VBOs it shouldn't be that slow, at least not at the ogles2 / Nova level. Each of the three involved libs (gle4es, ogles2, Nova) can be the cause for this, of course. It can probably also be some kind of shader problem, you cannot tell without some real measuring and lib-logging.
Therefore: please pack all your stuff (ready to run please) into a nice zip and put it on my FTP (don't try to mail me such a fat pile), so that I can profile and rule out / rule in / locate problems in ogles2 and shaders at least.
While I was typing this your GL_EXT_compiled_vertex_array report appeared. Please put that build in the zip too. VBOs and such are actually well tested in ogles2, so I think it's unlikely that there's an issue there, but we'll see and better make sure
Please don't expect results too quickly, I also have other things to do
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
