The functions wazp3d that I added in minigl are essential in my humble opinion otherwise I will not have lost my time to add all these functions. As for wazp3d the author (alain thellier) wants to monitor the number of downloads aminet so possibility to put it in the archive, that's why there is an installer. On the other hand how many real users of x1000 and x5000 (I am very curious) I have an idea but I would like to know the real number. For my part I think that the greatest number of users are still on old machines with radeons 9xxx and I can say that wazp3d is useful on some games or emulators (example: pegasos2: gngeo opengl Warp3D 640x480 = 35 fps and with WaZp3D composite = 60 fps), taking advantage of the composite some programs can take off I'm sure on old cards. I am aware that minigl is not perfect but to say that add options without optimizing it is useless and is not essential, it is not true and it would be too easy. We can not forget the users of old machines because we have the latest generations of NG machines equipped with big cards. Then I will end up with the users that everyone forget, WINUAE the emulation on PC, they use what? Warp3d with which card? Well no, waZp3D is essential and allows things that could not be done before, from where integration into minigl. I understand that everyone does not have the same ideas, I also want it to advance and I'm working quite a bit right now (without making real releases) but do not go too fast and forget the whole community. Finally I work hard on my EGL library so that all active players can make good portages. Thank you all for moving things forward and you've re-motivated me. I think of Daniel, Hans, kas1e, ptitseb and my all betatesters HunoPPC
2) If in the first stage you go on the mirror , so to see in full yourself, then you can see there some "black dots" all around mesh, as well as 2 diagonal purple lines in the quake3 banner (at top , in the mirror)
Could you double-check if anisotropic filtering is enabled (for textures)? It shouldn't make a difference, but worth checking.
Given issue #1 as well, I wonder if the vertices are being preprocessed somewhere, resulting in gaps...
For my part I think that the greatest number of users are still on old machines with radeons 9xxx ...
I've got hard data on this, and users of old Radeon 7xxx-9xxx are now a minority (round 27% still using them as their primary card).
Of couse, you're welcome to optimize things for the older cards if you feel it's worthwhile. Please make sure it doesn't impact newer ones, though (NOTE: I've got no idea what changes you're putting into MiniGL, so can't comment on that).
It also says that, for all the criticism leveled at MiniGL, it actually does a decent job. It's still faster than GL4ES with glBegin()/glEnd(), even with software TCL. Granted, W3D_SI is optimized for the very fixed data it's sent, but MiniGL is vlearly doing a decent job. There must be more optimizations possible GL4ES' pipeline...
What is surprise me, is how then ppls on those old PCs and radeond of really worse sort of what we have now, have 200,300,500 fps in the same tests.
What is so wrong in our side, that we have 50fps wiht glBegin/glEnd, and 100 with gldrawelements in minigl version.
Before , i think that "minigl bad, warp3d bad, all done wrong". But now, when we on new drivers with gl4es, it kind of give the same perfomance in end. Why ?:) I mean how it possible ?:)
@Hans & kas1e "black dots": To me this looks as if some meshs were drawn in wire-frame mode in a second render-path, with texturing enabled and with a bit of z-fighting so the lines' pixels sometimes don't get through. Totally weird.
@HunoPPC Cheers mate
@kas1e Quote:
But now, when we on new drivers with gl4es, it kind of give the same perfomance in end. Why ?:) I mean how it possible ?:)
I told you and it also was proven already, simply due to the existence of the last updates, what was done and what tests revealed: gl4es required and still requires optimizations / fixes, obviously. Despite the last improvements it's still the major time-eater, simple as that. And if current gl4es performs better on other platforms, I already said it, but I say it again: it's easily possible that other platforms don't suffer that much as we do from things like heavy malloc/free or cache-unfriendlyness etc. (or are simply faster per se; other platforms performed even worse if compared correctly, namely that Pandora).
And regarding VBO: it's a difference like night / day if you have *real* VBOs or no or only emulated VBOs. Quote:
What is surprise me...
Taking all this into account all those comparisons above are no surprise at all.
So for gods sake, keep calm and let the guy improve it; then let Hans improve Nova and then let me improve ogles2. And then let the gl4es-guy finally add real VBOs and all will be good Certainly not tomorrow though. And following Hans advice I'm now definitely out until Nova has been updated
That what i have from gl4es author when i show him those 2 screenhots of issues:
Quote:
I haven't seen any of the issues on the Pandora. Not sure what the sky issue can be. Some kind of Z fighting? The black dot issue is even more strange. Maybe it's a precision issue? Remove the "-ffast-math" on the gl4es compil to be safe, but most of the TnL is done in the vertex shader, so not gl4es.
@Hans Quote:
Could you double-check if anisotropic filtering is enabled (for textures)? It shouldn't make a difference, but worth checking.
At moment that ogles2.library which i test, didn't have GL_EXT_texture_filter_anisotropic enabled. If i understand things right, Daniel add it few days ago only.
But anyway, all the tests we do now, are without gl_extensision enabled, pure non-extensions tests.
So for gods sake, keep calm and let the guy improve it;
From his words i got that it was probably maximum he can do for glBegin/glEnd, without total rewriting of gl4es, which he obviously will not do :) And, he expect that once vertexattrib stuff will be done, and we can use glDrawElements in q3, then, it will have no CPU load and all will be well.
Real VBO in his TODO, but , we all know that TODO can easyly mean years or never, so i prepered that we will have what we have.
As for wazp3d the author (alain thellier) wants to monitor the number of downloads aminet so possibility to put it in the archive, that's why there is an installer.
Writing an installer script is fine , but embedded that in minigl would be bad idea, assuming I haven't misread what you said.
It's a shame that Wazp3d replaces the warp3d.library and does not implment a software driver library that would go in LIBS:Warp3D , which would be the proper way to do it IMHO.
The emphasis on this thread seems to be on speed but does this wrapper give any extention over the miniGL functionailty? For example Blender can render the 3D editor window preview with shaders / textures on a full OpenGL implmention but not with MiniGL. And aspects of the game engine are less functional that they could be.
What is so wrong in our side, that we have 50fps wiht glBegin/glEnd, and 100 with gldrawelements in minigl version.
Before , i think that "minigl bad, warp3d bad, all done wrong". But now, when we on new drivers with gl4es, it kind of give the same perfomance in end. Why ?:) I mean how it possible ?:)
There are multiple bottlenecks: 1. MiniGL having to do TCL in software is a major bottleneck that hurts performance. GL4ES should eliminate this one, but let's wait until we have compiled vertex arrays working before making judgements. GlBegin()/glEnd() isn't used by Q3 (or any well-written game/app) for a reason... 2. MiniGL uses fat vertices internally regardless of the data being sent. This fills the caches faster, thereby slowing things down. GL4ES may well do the same 3. Those other platforms use GART which allows the GPU to slurp vertices, indices, and command packets directly from RAM, whereas we still have to copy them to VRAM using the CPU (which is slow compared to GART/DMA). VRAM also has coherency issues, so the CPU has to do a wait-for-idle just before submitting the next batch of commands or it'll randomly hang. This is a serious bottleneck that we have yet to overcome. We'll get there eventually...
That said, it's important to remember that 100 fps is already faster than your monitor, and even 50 fps is playable. Having shaders support is also a big leap forward.
I understand that everyone does not have the same ideas
Of course, but putting wazp3d with installers to the minigl's code (!) it's wrong. Wazp3d instead should be done as proper warp3d library, which you put to the LIBS:Warp3D/SWDrivers or how it called. Just like Andy say. Then any minigl app just works as before, it will be work of main warp3d libary to choice what driver to use (hw one, or sw one) automatically. As well, as that software library should have no GUI prefs, installers and whatever else. It should be just library, just works, without needs to do anything with it. But even if, it still should be done as proper warp3d software driver. And that should't be putting to the minigl code.
Its just different levels , different kind of drivers. How it possible to mix it up ?
By puttin wazp3d to the minigl, you just mess it all. Its not work of MiniGL to deal with it. Its work of Allain to make a proper warp3d software library, which user just puts to the LIBS:Warp3d/SWDrivers or how it called.
And then, in wazp3d archive, which when will be done right, anyone can put downlaoders, installers, wgets, curls, firefox, quake3 and what else anyone wish, but not with that damn MiniGL , which cry because of it :)
If anyone want to know downloads, upload on os4depot, or on your site, and you will see downloads. There no needs to put installers, wgets, to the library archive which mean to be opengl library. Its just mess all things in one place.
Its like you take parts of some ANGLE or GLUT, and put it inside of DirectX, with adding some new gui prefs .. i do not know. Its just wrong.
Instead, you need to remove all that wazp3d from minigl, remove all those downloaders, gui prefs for it , and let's Alain do it just right : poper software warp3d driver, which users install to the LIBS:Warp3D/swdrivers, without needs to replace original warp3d.library. If Alain do not want to it, so , bad luck for winuae users and for those who do not have real warp3d.
But minigl should be just be as it was : minigl.library / glut.library.
As you want to do it now, its just .. just wrong. Imho of course, and we appreacte all your work so you don't think that we crude :)
@Broadblues
Quote:
but embedded that in minigl would be bad idea, assuming I haven't misread what you said.
Yes, that happens. Exactly from MiniGL code (!!). Real mess. That should't be in MiniGL, ever. Everything should be done properly from Alain's side first. Without needs to have tons of configs for different games, prefs guis, without needs to replace warp3d original library. If Alain do not want to do it , bad luck. But putting it as it to the minigl, wrong very wrong wrong wrong bad bad :)
Quote:
It's a shame that Wazp3d replaces the warp3d.library and does not implment a software driver library that would go in LIBS:Warp3D , which would be the proper way to do it IMHO.
The emphasis on this thread seems to be on speed but does this wrapper give any extention over the miniGL functionailty?
Well, from one side: yes. Its just OpenGL1.x/2.x , with support almost of everything, including OpenGL2.x shaders, but the conversion OpenGL ->GLES2 is a crude, so some shader may fail to convert. But he will for sure fix it , if you will find issues with.
There was question to the gl4es author:
Quote:
Is it currently possible to use custom OpenGL 2.0 shaders (i.e. shaders with fixed pipeline uniforms and attributes)?
And the answer was:
Quote:
You can use some (most) fixed pipeline uniforms and attributes in the shaders yes.
What is not supported (yet) is to define only 1 shader (fragment or vertex) and rely on the fixed pipeline one to link the program.
From my side, i port at moment just 3 games: Cadog, LettersFall and Quake3. Despite some rendering glitches in LettersFall and in Quake3 (which not happens in gl4es on Pandora, so its "our" problems) , i can say that Cadog's code works as it. While for MiniGL i had to play with it, to make it ok for MiniGL. Then, in MiniGL version of quake3, when you lower all stuff to the minimum in settings, everythng looks wrong (by colors , and by look). While with GL4ES version, does not matter how i play with settings, everything renders correctly always.
But from another side, MiniGL have not many, but still, GL Extensions (about 20). That helps. OGLES2/Nova at moment have not many (if i understand things right).
Take a look on what ones MiniGL driver have inside (as i understand warp3d support all of them):
And take a look on what ones GL4ES driver _can_ support, if they found in the GLES2/Nova:
Quite a lot of extensions there, and as can be seen, quake3's driver info page just can't fit all of them into the screen area, so there is many more, about 50. There is full list from gl4es code:
When i port yesterday IrrLicht engine to GL4ES, it just cry loud about tons of unsupported GL extensision, but, i do not know how they all usable and need it by opengl, and which ones the most common and need it ones. More the better probably.
But from quake3 side, can say, that even have just enabled "GL_EXT_texture_env_add" and "GL_ARB_multitexture", add +5fps to all tests. So probably the more, the faster.
Quote:
For example Blender can render the 3D editor window preview with shaders / textures on a full OpenGL implmention but not with MiniGL.
Blender 2.68 for sure works via that wrapper (tested by GL4ES guy on Pandora), with all the shaders and stuff. He haven't tried latest Blender yet, so he don't know how it work. But 2.68 for sure was ok.
Also a few OpenGL 2.x only games have been tested, like OpenRA or GZDoom.
That how looks like OpenRA (opengl2.x/shaders):
Glest:
Pre 2.x stuff tested a lot too and works, such as: Minecraft, OpenMW, SeriousSam (both First and Second Encounters), RVGL (ReVolt GL), TSMC (The Secret Maryo Chronicles), TORCS, SpeedDreams, GL-117, Foobillard(plus), Blender 2.68 as was said, to name just a few.
OpenMW over gl4es screenshot:
So probably, everything till OpenGL 3.x (not included) will work. With shaders and stuff.
Edited by kas1e on 2018/3/4 7:40:34 Edited by kas1e on 2018/3/4 7:47:56 Edited by kas1e on 2018/3/4 7:49:38 Edited by kas1e on 2018/3/4 8:11:36 Edited by kas1e on 2018/3/4 8:15:34 Edited by kas1e on 2018/3/4 8:39:13
1. MiniGL having to do TCL in software is a major bottleneck that hurts performance. GL4ES should eliminate this one, but let's wait until we have compiled vertex arrays working before making judgements. GlBegin()/glEnd() isn't used by Q3 (or any well-written game/app) for a reason...
Yeah, we wait Hans for :)) But as for GlBegin/glEnd, minigl version still faster that gl4es one there , so something wrong with gl4es still, seems so.
As it looks like that MiniGL with glbegin/glend is BETTER, even with software TCL : that what i can't understand why. Is MiniGl use real VBO ?
Quote:
2. MiniGL uses fat vertices internally regardless of the data being sent. This fills the caches faster, thereby slowing things down. GL4ES may well do the same
gl4es has 2 strategies. If the data are compatible with GLES driver, and the data can be shown immediately (so within a glDrawArrays(...) or a glDrawElements(...) and without sepcial things not possible in pure GLES), then the data is used "as-is", to avoid unnecessary copy. If a copy is needed (like for glBegin(...)/glEnd() block or some other cases), the "full" vertex is used (all vertex, color and texcoord are vec4, normal is vec3).
Quote:
3. Those other platforms use GART which allows the GPU to slurp vertices, indices, and command packets directly from RAM, whereas we still have to copy them to VRAM using the CPU (which is slow compared to GART/DMA). VRAM also has coherency issues, so the CPU has to do a wait-for-idle just before submitting the next batch of commands or it'll randomly hang. This is a serious bottleneck that we have yet to overcome. We'll get there eventually...
I not sure that guys who have 130 fps on the Radeon9250, have GART support. Did they ?:)
Quote:
That said, it's important to remember that 100 fps is already faster than your monitor, and even 50 fps is playable. Having shaders support is also a big leap forward.
No no, basically in that particular thread its _not_ important. As we do benchmarks there to see perfomance, not to what is playable. Its all about perfomance , and making maximum from it, so everything else later will won.
And i am currently just about GlBegin/GlEnd path. MiniGL have software TCL, no shaders, GL4ES woring over gles/nova, have no problesm with softeware TCL, have shaders, but slower :)
And i want to point again: we about glbegin/glend only now. In that particular case, i somehow expect more than in minigl twice, just because of not software TCL and becuase of shaders.
And there (with GlBegin/GlEnd route) vertexattrib fix and co, will make no diffences. It will (we all can hope) big differences when gl_exe_compiled_vertex_arrays + gldrawelements will works, but it will not help probably GlBegin/GlEnd route.
So, to summorize, about GLBegin/GlEnd route:
1). MiniGL slow, ok. Software TCL, no shaders, fat verties internally. I can understand that.
2). Gl4ES slow, SLOWER than MiniGL, NOT ok , because : no software TCL, have shaders, and ok, let it be same far vertices internally, but no software TCL and have damns shaders :))
I mean, we can explain why minigl slow. But we can't explain why, in the same glBegin/glEnd route, gl4es , with no software TCL, and with shaders, on the same as minigl level !
Was all those "TCL in software are problems of speed" talks was just a bull, then ?:)
Edited by kas1e on 2018/3/4 8:18:09 Edited by kas1e on 2018/3/4 8:18:45
But from another side, MiniGL have not many, but still, GL Extensions (about 20). That helps. OGLES2/Nova at moment have not many (if i understand things right).
Apparently you don't understand what those extensions actually mean. And that there's a reason why ogles2 doesn't report so many. Let me clear things up a bit:
Now let's remove those which are implicitely covered by ogles2 or which make no real sense in ogles2 because we got shaders. Ooops, only 6 remaining...:
Out of those GL_EXT_texture_filter_anisotropic is covered by ogles2 explicitely too, so let's remove that too. And from the special formats defined by GL_EXT_packed_pixels half (the most common) are supported implicitely, so that leaves us with 4,5 remaining:
Now lets take a close look at those remaining ones:
- GL_ARB_texture_compression / GL_EXT_texture_compression_s3tc Those are actually the only extension in MiniGL that give some additional value over ogles2 / Nova at this time.
- GL_EXT_draw_range_elements This would be a nice extension - if MiniGL truely supported it. However, it does not: internally it simply calls glDrawElements. So the caller gains exactly nothing, it's a dummy. Nevertheless it would be a nice extension to ogles2 because it would spare me a min/max index detection run.
- GL_EXT_color_table This feature is a pure software extension. It's not as if only an index-texture plus palette would be sent to the GPU. No, MiniGL internally converts it to one of the normal texture formats. MiniGL. What was the equivalent for MiniGL again? Right, gl4es. If you look for such an extension from the stoneage, expect it to be implemented in gl4es, not ogles2.
The point is: the extension string reported by ogles2 is so short because practically everything is already inside ogles2 by default. It is a mistake to expect ogles2 to return extension strings that are actually meaningless to ogles2. It's the job of gl4es to translate those implicit and explicit features of ogles2 to OGL1 extensions.
Or put in different words: if gl4es wanted / had implemented all that's supported, it could return an equally large extension string as MiniGL does... (actually it could most likely provide many more extensions with relative ease).
On top of that it sounds as if gl4es doesn't support true VBOs right now, which is something ogles2 offers by default too - and which is the big thing that gives superior performance.
Quote:
And take a look on what ones GL4ES driver _can_ support, if they found in the GLES2/Nova
No.All that stuff (with the exception of texture compression) is implicitely inside ogles2. It is a mistake by gl4es if it doesn't use those features / returns matching ext strings.
So, it looks as if I have to repeat myself again: gl4es needs much more work before you can expect great performance. At this time it a) wastes time internally for whatever logic (we can measure that fact) and b) it doesn't actually use what ogles2 offers to speed things up, a short extension string is just another proof of that.
Sidenote: let's not be unfair and not forget that there are issues in ogles2 / Nova too (e.g. 4 component extension, maybe bug in ogles2 with certain glDrawElements pointer setups) which right now prevent gl4es to use ogles2 to full degree in terms of glDrawElements and certain shader setups.
Quote:
I not sure that guys who have 130 fps on the Radeon9250, have GART support. Did they ?
With practically absolute certainty, yes.
Quote:
What is so wrong in our side, that we have 50fps wiht glBegin/glEnd, and 100 with gldrawelements in minigl version.
Naturally even the best glBegin / glEnd implementation is much much slower than a direct glDrawElements, and gl4es' implementation is apparently not the fastest, simple as that.
Edited by Daytona675x on 2018/3/4 10:31:01 Edited by Daytona675x on 2018/3/4 10:32:40 Edited by Daytona675x on 2018/3/4 10:44:36 Edited by Daytona675x on 2018/3/4 10:50:42
The point is: the extension string reported by ogles2 is so short because practically everything is already inside ogles2 by default. It is a mistake to expect ogles2 to return extension strings that are actually meaningless to ogles2. It's the job of gl4es to translate those implicit and explicit features of ogles2 to OGL1 extensions.
Or put in different words: if gl4es wanted / had implemented all that's supported, it could return an equally large extension string as MiniGL does... (actually it could most likely provide many more extensions with relative ease).
Author ask:
About extension, doesn't OGLES2 support any of those: Framebuffer: GL_OES_packed_depth_stencil GL_OES_depth24 Texture support : GL_OES_rgb8_rgba8 GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_OES_depth_texture Shader: GL_OES_standard_derivatives
Quote:
It's the job of gl4es to translate those implicit and explicit features of ogles2 to OGL1 extensions.
I may talk a bull, but author do all already like he do in meaning ogles2 drivers on pandora, android and where they are else. Is there special changes realted to our (if it to only our realisation) ogles2 only should be done, so gl4es can "translate those implicit and explicit features of ogles2 to OGL1 extensions.". If so, plz say what need to do, to properly translate it all, so i can forward that to author and he can implemnt it in the way our olges2 expect everything to be.
Quote:
Sidenote: let's not be unfair and not forget that there are issues in ogles2 / Nova too (e.g. 4 component extension, maybe bug in ogles2 with certain glDrawElements pointer setups) which right now prevent gl4es to use ogles2 to full degree in terms of glDrawElements and certain shader setups.
Yeah, and don't forget sky overlaping, z-fighting (or whatever, i just call it like this) when we watch in the mirror, and mess of textures in the letters fall (which can be side effect of that issues with gldrawlements). Also i found another bug, but will keep it for ourself, until Hans done with vertexattrib, as it can be side effect of it, as well.
We just can't progress until vertexattrib stuff done. Hans know it, and i should't be pushy, i know. And have a rest, yes :))
Quote:
With practically absolute certainty, yes.
If, GART is soo much cool and nice, why amigans in last years all the time keep told that its software TCL which make problems with speed :) Probably, if it _that_ nice and good , then instead of polaris drivers, having GART support in drivers we have , much much better course ?:) But its ritorical question :)
But in reality, then, TCL mean nothing seems so (in that particular glBegin/glEnd case). As even if gl4es realisation of glbegin/glend not the best one, it is probably not the worse one now (after all those improvements), as on pair as in minigl one. But, minigl don't have TCL in hardware, gl4es have => still the same fps for glbegin/glend => TCL make no differences then.
But i remember how it was told milion times, TCL ! TCL in software ! That why minigl slow ! :)
Quote:
Naturally even the best glBegin / glEnd implementation is much much slower than a direct glDrawElements, and gl4es' implementation is apparently not the fastest, simple as that.
Imagine then how it done in Regal (if we take last tests with rotated cube in Regal topic).
Surpise for me is: TCL in software or in hardware, seems make no differences in that particular case. As if we take that glBegin/glEnd code path done on the same level in both minigl and gl4es, and still gl4es version there slower, then, TCL make no differences at all.
But let's see what will changes after glDrawElements version will works.
@kas1e Makes you wonder why the entire industry moved to H/W TnL in the early 2000s if it makes no difference. You are comparing apples to oranges, and your heaviest test case (Quake3) doesn't even have that many triangles.
This is just like television, only you can see much further.
@BSzili Its all sarcastic and ritorical in some ways. I know how it all good for other platfoms.
I just remember how everyone keep saing that quake3 perfoms slow on minigl/warp3d, as it didnt' have hardware TCL. Now we have it , and no diffirences.
I just disappointed a bit by resulst we have in end, to say truth. Even in pure glBegin/glEnd, with _hadware_ tcl. Like, you know, its only problem of how handle glBegin/glEnd, and minigl do it better, and because of it it faster (or the same , not so matter).
Everyone keep saying and explain things, but result is : gl4es quake3 in glBegin/glEnd , with HARDWARE TCL, slower/the same as quake3 for minigl in glBegin/glEnd with SOFTWARE TCL. And that its after author of GL4ES make lots of optimisation (yeah, we all remember how we talk that Regaaaal ! Regalll will help us ! Which is slower than gl4es in 2 times :) )
Just a bit disappoined, that all. Was expected to have 150-200 fps in compare with minigl's 50 , even on pure glBegin/glEnd. Even with worse than in minigl implementation of it. Just because we have shaders and hardware TCL in gl4es version. But it just give no big sense with glBegin/glEnd route, at least. I expected more. Not the same 50 fps, but 150, 250, 350.
I feel your pain, but it's difficult to compare things this way, so everybody keeps guessing. You could take Hieronymus and collect some profiling data to see what takes up the CPU time.
If vertex array were available, Jedi Outcast and Jedi Academy would be better test cases, since they have high poly models. When running MOS and OS4 on the same machine the performance gap gets smaller if you lower the model detail. With glBegin/glEnd you would end up with a gazillion function calls, again more work for the CPU while the GPU sits idle :(
This is just like television, only you can see much further.
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
