Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
57 user(s) are online (38 user(s) are browsing Forums)

Members: 0
Guests: 57

more...

Headlines

 
  Register To Post
« 1 ... 38 39 40 (41) 42 »

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Just popping in


See User information
@kas1e

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


AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon R7 250 / M-Audio 5.1 -> AmigaOS 4.1 FE / Ubuntu Linux
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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.



Edited by kas1e on 2021/11/28 15:05:54
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Quite a regular
Quite a regular


See User information
@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

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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?

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@TiredOfLive
Quote:

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?


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:

Are those changes to the Radeon RX driver applicable to the RadeonHD driver as well?


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

Quote:

Or were those limited to the RX range of cards?


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

Quote:

Could we also get some figures on an X1000?


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

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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...

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Just popping in


See User information
@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

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@trgswe

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

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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
backends/platform/sdl/sdl-window.oIn function `SdlWindow::grabMouse(bool)':
backends/platform/sdl/sdl-window.cpp:154: undefined reference to 
`SDL_SetWindowMouseRect'
backends/platform/sdl/sdl-window.cpp:154: undefined reference to `SDL_SetWindowMouseRect'
backends/platform/sdl/sdl-window.oIn function `SdlWindow::setMouseRect(Common::Rect const&)':
backends/platform/sdl/sdl-window.cpp:178: undefined reference to 
`SDL_SetWindowMouseRect'
backends/platform/sdl/sdl-window.o: In function `SdlWindow::createOrUpdateWindow(int, int, unsigned long)'
:
backends/platform/sdl/sdl-window.cpp:417undefined reference to `SDL_SetWindowMouseRect'
backends/platform/sdl/sdl-window.cpp:417: undefined reference to 
`SDL_SetWindowMouseRect'
gmake: *** [scummvm] Error 1

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

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@Raziel
Quote:

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


Yes.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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:

--1024x768--

MGL/SDL2: 89.1
GL4ES/SDL1: 38.8


And today's values in the same 1024x768:

Quote:

MGL/SDL2 over NovaBridge : 135 FPS
GL4ES/SDL2: 170 FPS


That is quite a big improvement.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Just popping in


See User information
@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 - AmigaOS4 Beta-Tester
- AmigaOne X5000
- AmigaOne A1222
- Sam460ex
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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).


Edited by kas1e on 2022/1/30 10:38:54
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Amigans Defender
Amigans Defender


See User information
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?

i'm really tired...
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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:

mkdir build
cd build

cmake \
-DCMAKE_SYSTEM_NAME=Generic \
-DAMIGAOS4=1 \
-DSTATICLIB=ON \
-DCMAKE_SYSTEM_VERSION=1 \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_C_COMPILER="/usr/local/amiga/bin/ppc-amigaos-gcc" \
-DCMAKE_CXX_COMPILER="/usr/local/amiga/bin/ppc-amigaos-g++" \
-DCMAKE_LINKER="/usr/local/amiga/bin/ppc-amigaos-ld" \
-DCMAKE_AR="/usr/local/amiga/bin/ppc-amigaos-ar" \
-DCMAKE_RANLIB="/usr/local/amiga/bin/ppc-amigaos-ranlib" \
-DCMAKE_FIND_ROOT_PATH="/usr/local/amiga/ppc-amigaos/" \
..


make -j4



Also, there is a hint :

Quote:

for full normal debug version instead of -DCMAKE_BUILD_TYPE=Release do -DCMAKE_BUILD_TYPE=Debug
if we want only "-gstabs" without gl4es debug output, then -DCMAKE_BUILD_TYPE=RelWithDebInfo


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:

// temporary fix until Daniel add necessary things to ogles2.
#ifdef __amigaos4__
globals4es.nopsa = 1;
#endif


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:

LIBGL_BATCH

BATCH simply tries to merge subsequent glDrawXXXXX (glDrawArrays, glDrawElements...). It only tries to merge if arrays are between MINBATCH and MAXBATCH (inclusive) The Batching stop when there is a change of GL State, but also if an Array of more than 100*N is encountered.

0 : Default: don't try to merge glDrawXXXXX
N: Any number: try to merge arrays, 1st must be between 0 and 100*N
MIN-MAX: 2 numbers separated by minus, to try merge arrays that are between MIN and MAX vertices



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.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@kas1e

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

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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

Go to top

  Register To Post
« 1 ... 38 39 40 (41) 42 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project