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

@kas1e

Great news!! Looking forward to what will happen with the Southern Island framerates with this newer kernel.

@Skateman
The most speed up comes from Radeon RX, see the example of gl4es's version of quake3 in 1920x1080:

public kernel + Radeon RX 2.7 : 78 FPS
beta kernel + same Radeon RX 2.7 : 89 FPS
beta kernel + Radeon RX 2.8 : 133 FPS

So we have + 11 FPS from just a kernel and + 44 FPS from Radeon RX, which means that about 80% of speed up is from RadeonRX and only 20% from the kernel.

For sake of tests, I put RadeonHD in and checked, that the results:


public kernel + Radeon HD 3.7: 80 FPS
beta kernel + Radeon HD 3.7: 91 FPS

So, the same + 11 FPS. But that on x5000, and kernel changes guilty for speed up probably only x5000 related.

@kas1e

Very good work, well done to all involved.
Do you know if this is likely to be close to the limit of performance increase?
Or is there more to come?


Cheers

@kas1e

Are those changes to the RadeonRX driver aplliable to the RadeonHD driver aswell?
Or were those limited to the RX range of cards?

Could we also get some figures on an X1000?

@TiredOfLive
Quote:

I think that such a speed increase wasn't expected at all. It was just some pleasant side effect. I asked Thomas about kernel, he has no idea why there was a speed increase in kernel, and he say that _maybe_ that was due to "dcbz only use half cache lines on X5000" fix. So 99% that this is speed increase only x5000 related.

Another speed increase comes from RadeonRX, which also seems kind of unexpected (i only find about it yesterday, and Hans maybe even not aware at moment, only tomorrow when he will read my mail).

So, to answer to if there is room for improvements: of course. Because drivers still have no real DMA/GART in parts where is need it. Our games still do not have that much FPS as need it. SuperTuxKart for example start to be better than before, but still not good enough. Same for a few other games, which have a little boost, but not that big one we all expect.

That speed increase is just something no one expects and comes from the usual work of developers that were shot by luck. Because if any of the devs know that this will change things in that way, that surely wasn't waited till now :)


@Raziel

Quote:

I do not know, I will ask Hans tomorrow if the same can be done for RadeonHD too.

Quote:

Dunno, hope Hans will sort it as soon as he will read my mail with the results.

Quote:

On x1000 nothing will be changed. As changes in the kernel were x5000 specific, and changes in RadeonRX make no sense for x1000 users as no RadeonRX on x1000 still (as far as I know).

@All
I tested the latest stuff also with RadeonHD, and yes, such a change which was done for Radeon RX driver, added to the latest beta of RadeonHD driver too, but it didn't give such a bit speed boost as in the case with Radeon RX. Added a bit, but not that much. I will post figures a little bit later

@all
So I tested with the latest beta kernel and the latest beta RadeonHD, on x5000, and as a test case i take again quake3, GL4ES version. My HD card is some HD verde r5-270 so not the fastest one.

1920x1080, all settings on max, "time demo/demo four" running 3 times for each config and max fps taken, so:

kernel public 54.34 + public Radeon HD 3.7 : 81.0 FPS

I.e. that is what all x5000 owners can have now.

Then:

kernel public 54.34 + latest radeonhd beta : 85.7 FPS

So we have +5 fps only by a driver update, and:

kernel beta 54.43 + latest Radeon HD beta: 96.4 FPS.

So +11 fps more by updating the kernel. I.e. in whole by updating 2 components we have +16FPS in quake3 in 1920x1080.


Not that good as the case of Radeon RX, just updating which from version 2.7 to 2.8 (as i see 2.8 version is public one already?) cause +36 FPS, and updating kernel from public to latest beta give another +19FPS, so in summary 55 fps more.

It's all more looks like a combo. I.e. just updating driver and not updating kernel, or just updating kernel and not updating driver give less separately, but when combined, give more.

But kernel speed increase is probably only for x5000, where one related thing was fixed.

@kas1e

Great to see that squeezing the fps out of the drivers is progressing

As long as certain OpenGL stuff gets beyond 20 FPS and becomes playable/enjoyable i'm good.

And who knows...maybe we will get a CFE update and RX support even on older hardware...

@Raziel

Unfortunately almost all HD series graphics card have a VERY low spec, like they are not recommened to run games at HD resolutuions (more like 640x480, perhaps up to 1280x720) you probably hitting hardware limitations when running the HD series cards (they are usually low-level, the fastest HD series card is the 7970 GHz Edition almost RX 470 (122% of a 7970 HD)) even on lowend Amigas

@trgswe

One more reason to get the RX series supported on older NG hardware.

@kas1e

Do i understand it correctly that the gl4es SDL2 libraries need to be adapted/recompiled with a new SDL2 release?

I installed SDL2.0.20 RC1 and get undefinded references with the available gl4es release now

SDL_SetWindowMouseRect was added in 2.0.18 (see also the SDL2 thread)

@Raziel
Quote:

Yes.

@All
Checked that post:
https://www.amigans.net/modules/xforum ... id=109989#forumpost109989

See the values of FPS in quake3 when we start almost 4 years ago :):

Quote:

And today's values in the same 1024x768:

Quote:

That is quite a big improvement.

@all

I remember that was a Doom3 WIP port for OS4.

Perhaps these performance updates will make the port playable when/if it is released.

@Sinan
Imho it was playable even a year(s) ago, just port by Huno wasn't finished. There are already morphos and aros ports, and morphos one even playable on old Radeon. So it is just a matter of somebody making a port (besides, both morphos and aros source code are open).

I'm trying a game that is using this code:

GL_CHECK(glGenFramebuffers(1, &m_handle));
GL_CHECK(glBindFramebuffer(GL_FRAMEBUFFER, m_handle));
GL_CHECK(glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, m_texture.getHandle(), 0));
#ifndef __amigaos4__
assert(glCheckFramebufferStatus(GL_FRAMEBUFFER) == GL_FRAMEBUFFER_COMPLETE);
#endif
GL_CHECK(glBindFramebuffer(GL_FRAMEBUFFER, 0));

I've noticed that with OpenGLES directly glCheckFramebufferStatus returns correctly GL_FRAMEBUFFER_COMPLETE while with GLES it is always incomplete. Is a solution available? Or maybe i have to set something before launching the game?

@Adrea
If you think that is a gl4es bug, plz fill the bug report here: https://github.com/ptitSeb/gl4es/issues

Or at least if you are not sure, making a report there will bring some discussion, and ptitSeb can help surely if that will be an issue on his side.

@All
Btw, if any of you don't use my prebuild SDK, but want to use the latest GL4ES from ptitSeb's GitHub, then be sure that you compile it like this:

Quote:

Also, there is a hint :

Quote:

And at the end of all, if you build the latest version from github, it has broken .psa support. Issue is:
http://www.amiga.org/developer/bugreports/view.php?id=869

So in meantime, you will need to disable .psa generation from gl.init in the function void initialize_gl4es(), by adding:

Quote:

But that only, if you want the very latest version of gl4es until I did not make a new version of SDK.

Also, as 2 more speed hints, I want to bring 2 moments that may help to speed things up in your ported OpenGL over gl4es apps.

By default _in most_ cases what the gl4es default states have are enough, but, in some cases, some additional tricks can be done to speed things up (and radically).

One of them is environment LIBGL_BATCH:

Quote:


What it means in the reality, is that when you build any of your apps, and it didn't have FPS you are satisfied with, or, you simply want to have as much as possible, you then in the shell firstly play with this Env before running your port like: "setenv LIBGL_BATCH 0-40", and so on, or 0-20 or 20-50, i.e. you got an idea.

If, under some values, you have really better performance, then to avoid issues/worry for users, you do as I do for NeverBall/NeverPutt ports: you just build your special gl4es build, with settings necessary value again in the initializing function of gl4es, like you do for disabling .psa. if you build the latest version. That trick brings in NeverBall quite a lot FPS more, the same as in my local test of Cube port. So, that must check always.


A second speed-hint which you may try for your ports, is happening for me only in the FrickingShark game, and so far i do not know the reasons of it, just found it by some luck. It's the usage of MAX_Textures in gl4es.

For FrikingShark i found that if i use in config.h #define MAX_TEX 8, or 4, or 2 instead of 16, i have better and better FPS in-game. And by better, i mean almost 50% increase with MAX_TEX 2. But that _ONLY_ in fricking shark. In no other games that make any difference (but I tried all my ports). The reason for that is still unknown but we think it can be some weird stuff in FrickingShark itself (i.e. game's code) that enables a VA for every existing TMU (without actually using them then). At least that would explain the performance differences. But that's just a guess.
Through it is worth noting that this was the second hint helping me to increase the speed.

So that is all you need for the current maximum usage of gl4es if you build your own versions.

Also, be sure your checked always https://github.com/ptitSeb/gl4es/blob/master/USAGE.md.

All the environment there works for AmigaOS4 as well, via "setenv LIBGL_xxxx blablaba". And there is a lot, and some of them surely can bring some performance too, just i didn't find with ptitSeb anything else more or less important as LIBGL_BATCH and that MAX_TMU switch in FrickingShark.

@kas1e

I assume you'll do a new gl4es release once SDL2 gets it's release?

@Raziel
I can build easily if you need new gl4es and new sdl2 at any time, but not the new full SDK as I have more plans for it to add. But for your use with scummvm, etc that will be more than fine, just tell me when you will need it