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

@Raziel
At least you go far enough with gl4es already :)

So, now, when you certainly have running gl4es build as can be seen, you need to be sure you don't have shader-compilation errors.

What you need, is to enable output of not original shaders, but shaders generated by gl4es (internal ones and re-generated from shaders coming with scummvm if there is any). So then you grab then one by one, and firstly by using glslangvalidator port from Daniel (last one from latest warp3dnova releases) compile SPRV files from them (to see, that syntax all correct and so on), and then, after, you use Hans's W3DNShaderInfo (coming with warp3dnova in example/Shaderinfo/). To see if it bring errors.

@kas1e

Yeah, not only is it hard to understand, but it also is so illogical sometimes...

I'll have to put this on hold in the meantime, anyway.
There seems to be some missing extensions, which would normally be included if the backend uses GLEW (which we don't).

Have to wait for some PR getting merged and then try again.

Will surely get back to you all

Thanks for the help so far

@All

Want to resurrect this thread with some interesting info which I know those who are interested in 3D on OS4 (especially on x5000), will be interested in the info above.

So, yesterday I just tested some beta components: the latest kernel and the latest Radeon RX driver. The kernel I tested doesn't mean being multicore, just the usual kernel with some improvements mostly from Thomas, and just the next version of the Radeon RX driver by Hans.





Together kernel and new gfx drivers bring some unbelievable speed up in ports i do via GL4ES (which use Warp3DNova and ogles2.library). MiniGL apps also have some speed up, but not that big as with GL4ES apps.

For example, take the quake3 and 1920x1080 fullscreen / all settings max / usual "timedemo 1/demo four running 3 times" on my X5000:

MiniGL version on RadeonHD SI: ~75 FPS
GL4ES version on public components on Radeon RX: ~78 FPS
GL4ES version on beta components on Radeon RX: ~133 FPS (!)

Yes, +55FPS!

I retested more games, and there are results:

"Quake3"'s timedemo1/demo four: +55fps
"HCraft" vary, from 30 to 50 fps more
Worlds: vary, in general from 15-30FPS more
SuperTuxKart : +15 FPS more
FooBillard++ : +25 FPS more
NeverBall : + 100 FPS more
NeverPutt : + 150 FPS more
Friking Shark: +50 FPS more
Irrlicht_demos: Quaketest + 25FPS, shaders tests + 800FPS, meshviwer test + 200 fps, "demo" example + 35 FPS.

In other words, it is just something unbelievable. I find out that speed increase comes from both kernel and Radeon RX drivers. About 30% come from Kernel (probably once Thomas add "dcbz only use half cache lines on X5000") and 70% come from Radeon RX change which is "Reduced overhead of getBMBytesPerRow(). It used to lock and unlock the bitmap, which is rather slow". Not sure that authors expect such a massive change, but that comes as a real unexpected bonus.

To see it all in action, you can watch a video made (as usual with comments and stuff) where I test 7-8 GL4ES game ports, so you can see the figures of FPS and compare if you are in interest.

There is:

Beta tests of 3D graphics on X5000 in november 2011. 1920x1080 full HD


Yeah, I still can't believe in such massive change. That of course without real DMA, which should bring even more at the end.

@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.