Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
94 user(s) are online (48 user(s) are browsing Forums)

Members: 0
Guests: 94

more...

Headlines

 
  Register To Post  

« 1 ... 14 15 16 (17) 18 19 20 ... 42 »
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

Quote:
Yeah, just some games done like this, and its good if they can works as well without total rewrite :)

Of course. My hint is for developers writing their own apps/games.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
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 wrote:

"Ok, let's start from the buggy ones (as find out roots and fix problems is more important than rereleasing another time quake3 :) ).

So, all the tests should be done on latest ogles2.library and warp3dnova.library. ogles2.library should be 1.22, and warp3dnova.library should be 1.58. It is very important to have those versions , as if not, tests may not help.

There is test archive of that LettersFall3 game:

http://kas1e.mikendezign.com/aos4/gl4 ... fall/find_the_bug/lf3.lha

There is how it looks like on my setup when i choice "options" or "howtoplay" or "highscores" or start a game (you can see distorted textures of text, they like doubled and shifted randombly):"
------------------------------------------------------------------------------------------

On my X1000 all screens look and work normal...screen resizing too went well

my setup:Corsair GS800 800w PSU, Western Digital 250 GB SATA HDD (model:WD2500YS), 4GB Ram, Radeon HD7950-3GB GDDR5- Dual Slot, Lite-On RW DVD/CD, On-Board Nemo sound,8139B NIC, Catweasel MK4+

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

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
@328gts
Quote:

On my X1000 all screens look and work normal...screen resizing too went well


That because you didn't play with settings a lot. Sometime there needs to go from/to many times to get trashing and that probably related to the amount of memory installed on gfx card.

But that anyway not important anymore, as Hans already fix that issue.

Now we fight with the same issues which was happens in quake3 and irrlicht engine before, to which Daniel add workaround before, but we want to be it without workaround and all necessar conversion code be in Nova (so, maybe it will give another speed up, if all goes well).

Join us to improve dopus5!
AmigaOS4 on youtube
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

sounds good ..be happy to try out any other beta versions as well

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

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
Currently Hans add necessary conversion code, so all almost works without Daniel's workaround, but just need some tweaks from ogles2 side, so we wait when Daniel will back from his trip.

@Hans,Daniel
Another new facts interesting to discuss about speed of q3 over gl4es/ogles2/warp3dnova.

Surprisingly, we think before, that "compiled vertex arrays" extension give us some fps in gl4es , but its not. I mean at all, its pure placeholder. That what say gl4es author:

Quote:

Really, that compiled vertex arrays extension is not usable by gl4es. What it does is tell the opengl driver that the vertex data (and only the vertex data) are set and will not change between glLockArrays(...) and glUnlockArrays() so a opengl driver that don't have hardware transform can transform the vertices... But has gl4es use Hardware T&L (in shaders), it's just useless.
And quake3 make changes to other arrays (colors, textures UV) in between, so I cannot really build anything stable...


What it mean, that it just placeholder, and doing nothing for us.

All the speed we gain when enable gl extensions in q3 in gl4es version, come from "multitexture" extension: it give 10fps+. And another speed up we have when just use glDrawElements() instead of glBegin/glEnd route (another 10fps+ only).

compiled vertex arrays extension - does nothing as author say.

texture_env_add - dunno if does, but add nothing in q3 as well.

Soo.. Problem is that author of gl4es can't come up with anything good to make that glLockArrays (compiled vertex arrays) extension. He already tried a few things, but it's really only good when you have to transform the vertices in full software, and he have not been able to do anything usefull with it.

Maybe any of us can give any ideas so he may try to implement it ?

Official spec of that extension here:
https://www.khronos.org/registry/OpenG ... compiled_vertex_array.txt

The problem with this extension is that we can enable Vertex Arrays after the Locking... Making this extension pretty unusable.

If we look here for example: https://github.com/ptitSeb/ioq3/blob/m ... derergl1/tr_shade.c#L1279

We see the call to glLockArrays(...) and then the engine enable GL_TEXTURE_COORD_ARRAY and GL_COLOR_ARRAY. That means those 2 arrays are not Locked, but still used for drawing (and the values of thoses 2 arrays will be changed between the Lock and Unlock)...

So the client software can enable Arrays that are not locked, so that make the Lock/Unlock mecanism useless (for gl4es at least), because a drawing command is part on locked Arrays (like Vertex coordinates) and part on unlocked Arrays (like vertex colors or UV).

If anyone have any ideas how to make anything usefull with gl4es with that extension, any idea can help us.

Join us to improve dopus5!
AmigaOS4 on youtube
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

Quote:
Maybe any of us can give any ideas so he may try to implement it ?


A few possible ideas:
1. Put the vertex position data into non-interleaved arrays in a VBO. Then you can update the colour & texture coordinates more efficiently (better with caches and non need to upload the positions again)
2. Put the vertex positions in a separate VBO. Again, you'll be able to update the colour & texture coordinates more efficiently

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
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
@Hans
ptitSeb answer about:

Quote:

No sure I understand but you mean I do:

1. Create a VBO with vertex position, color, texcoords, normals, but non interleaved. And only update changed color / texcoords.

2. Create a VBO with only vertex position. Color and Texcoords and Normals out of the VBO.

?

Well, for (1) I can probably try to implement, but that seems to be quite some work, and I'm unsure of the performances gain. Plus I don't know what vertex attributes (color, how many texcoords, normals) will be needed for drawing.

For (2) I'm unsure how standard this thing is: some vertex attributes in a VBO and some in another VBO. While I can probably try to implement that, again, I'm unsure of the performances gain (as you still need to transfert colors and other VA) and unsure how various GLESv2 driver will accept this kind of things.

Has this optimisation are only for old engine, and those engines probably are running pretty well on most hardware already, I don't think it's worth the risk of slowing other stuff down, and not worth the added complexity of the code.


Join us to improve dopus5!
AmigaOS4 on youtube
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

Okay...

Quote:
1. Create a VBO with vertex position, color, texcoords, normals, but non interleaved. And only update changed color / texcoords.

Yes. Something like glBufferSubData() can be used to upload just the changed attributes.

Quote:
2. Create a VBO with only vertex position. Color and Texcoords and Normals out of the VBO.

The remaining attributes would go into a separate VBO in this variation. Basically, you'd have one VBO for static data, and one VBO for the dynamic ones (with appropriate usage hints: GL_STATIC_DRAW and GL_STREAM_DRAW). This option would probably work best on OpenGL implementations where the driver can put GL_STREAM_DRAW buffers in GART space (which is on the to-do list for Nova).

This is an entirely valid and normal way to use VBOs, see this link.

Quote:
Has this optimisation are only for old engine, and those engines probably are running pretty well on most hardware already, I don't think it's worth the risk of slowing other stuff down, and not worth the added complexity of the code.

Your call ptitSeb. I doubt it'll slow stuff down because drivers for GLES2 level hardware use VBOs internally for the data, anyway. With option #2, you're actually giving the driver the hints to optimize each VBO for the data being sent.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
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
@Hans
Quote:

Mmm ok. I'll look at the separate VBO then, to change the current (quite inefective) VBO stuffs I implemented some time ago and see if this could be implemented. It should be easier to do (VBO for all vertex attrib active at the time of glLock, other vertex attrib will remain outside).

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
>We see the call to glLockArrays(...) and then the engine enable GL_TEXTURE_COORD_ARRAY and GL_COLOR_ARRAY. That means those 2 arrays are not Locked, but still used for drawing

What does it mean ? I mean what does the game want to do ?

Does it mean that the game want to no update the vertices but just update the texcoords and colors ?
Perhaps in this case the VBO will do the vertices transform GPU side but the lighting (colors) will be done by CPU ? and what about texcoords ?


It will looks more logical to have the whole array not updated and that light&transform is done GPU side , no ?

Anyway from my own experiments: updating a vbo is truly the bottleneck in Nova (so also in GL-ES and GL4ES)




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
@thellier
Quote:

It will looks more logical to have the whole array not updated and that light&transform is done GPU side , no ?


Its old quake3 code :) and gl4es use hardware TCL in shaders by using shaders.

Quote:

Anyway from my own experiments: updating a vbo is truly the bottleneck in Nova (so also in GL-ES and GL4ES)


Dunno about that, at least ogles2 works fine over nova.

Can you bring some test cases to Hans so we can see if anything wrong at all ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@kas1e
Quote:
Dunno about that, at least ogles2 works fine over nova. Can you bring some test cases to Hans so we can see if anything wrong at all ?

I asume he's simply talking about the fact that updating VBOs in general is a comparably slow process. Which is of course simply in the nature of things. And until Nova gets DMA/GART support here things are even slower on AOS4 compared to e.g. PC.
Those are all well known facts, nothing new at all. And of course Hans knows that
So I guess this isn't something anybody needs to come up with test cases for

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
@Daytona675x
Quote:

I asume he's simply talking about the fact that updating VBOs in general is a comparably slow process. Which is of course simply in the nature of things. And until Nova gets DMA/GART support here things are even slower on AOS4 compared to e.g. PC.
Those are all well known facts, nothing new at all. And of course Hans knows that
So I guess this isn't something anybody needs to come up with test cases for


Correct on all counts. Vertex uploads are relatively slow because we don't have DMA/GART yet. Hence avoiding uploading data more then necessary is a good idea.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
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
@Hans
Quote:

slow because we don't have DMA/GART yet


Is it necessary to update graphics.library as well, or all can be done outside of graphics.library (so to not rely on when hyperion will release updates) ?

I mean is it _that_ dma which we miss in graphics.library for x5k ?


Edited by kas1e on 2018/10/19 11:54:45
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
@Daytona675x

You are absolutely right

@kas1e
There are only 2 cases in fact:

1) Object & VBO got exacly the same points formats so you can memcpy the whole XYZUVWRGBA list in one call = slow but cant be faster

2) Object & VBO dont have the same points formats so you must pick xyz at one place to copy it elwhere in the VBO, uvw ditto, etc.... and so become more slow

A partial glLockArrays is case 2) because even if XYZ is in a separate static VBO you will (certainly) have to pick the UVW RGBA in the original points list to copy them to their VBO



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
Quote:
I mean is it _that_ dma which we miss in graphics.library for x5k ?

No. The graphics library's DMA is internal to it, so it's not available to external drivers.

I'm talking about using the graphics card's own GART/IOMMU and DMA. The Graphics Address Remapping Table, which these days is more of an I/O Memory Management Unit maps main memory into the GPU's address space. Once that's set up, the GPU can read stuff from main memory using its own DMA engines. It's on the to-do list for the future, and we will get there at some point...

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
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
While waiting for others to sort their real-life deals, hacking around and made some hacks to our (Capehill's) SDL2, so it can use GL4ES as well.

Changes was almost the same as for SDL1, with some small differences (like some different names of structs and datas in, but logic about the same). And as almost all initialisation done in the init stages of gl4es itself, i have no needs to open/close librairies from sdl1/sdl2 , and co, just createcontext/makeactivewindow. Also whole "wrapper" code for gl functions are inside gl4es too, so for sdl2 (and for sdl1 too) file is empty. In other words changes just in 1 file (SDL_os4opengl.c), and another one, wrapper one, are empty (SDL_os4opengglwrapper.c). There they are:

http://kas1e.mikendezign.com/aos4/gl4es/sdl2/SDL_os4opengl.c
http://kas1e.mikendezign.com/aos4/gl4 ... l2/SDL_os4openglwrapper.c

Sure its not way to go, as i just changes minigl based files in sdl2, but for test and co its ok imho.

At moment just tried that simple test case:

#include <stdio.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_opengl.h>

#define WINDOW_WIDTH 640
#define WINDOW_HEIGHT 480

int main(int argcchar const *argv[]) {
    
SDL_Window *window;
    
SDL_GLContext glContext;

    
SDL_Init(SDL_INIT_VIDEO);

    
window SDL_CreateWindow(
        
"Title",
        
SDL_WINDOWPOS_UNDEFINED,
        
SDL_WINDOWPOS_UNDEFINED,
        
WINDOW_WIDTH,
        
WINDOW_HEIGHT,
        
SDL_WINDOW_OPENGL
    
);

    if (
window == NULL) {
        
printf("SDL_CreateWindow error: %s\n"SDL_GetError());
    }
    
    
glContext SDL_GL_CreateContext(window);

    
glClearColor(1.0f1.0f1.0f1.0f);
    
glClear(GL_COLOR_BUFFER_BIT);

    
glBegin(GL_TRIANGLES);
        
glColor3f(1.0f0.0f0.0f);
        
glVertex3f0.0f1.0f0.0f);
        
glColor3f(0.0f1.0f0.0f);
        
glVertex3f(-1.0f, -1.0f0.0f);
        
glColor3f(0.0f0.0f1.0f);
        
glVertex3f1.0f, -1.0f0.0f);
    
glEnd();    

    
SDL_GL_SwapWindow(window);
    
SDL_Delay(3000);

    
SDL_DestroyWindow(window);
    
SDL_GL_DeleteContext(glContext);

    
SDL_Quit();
    return 
0;
}


And result are:
(press open image in new window for full size)

Resized Image

What good from it ? Authors of active projects start to move to SDL2, so its good that we can try to build not only SDL1 based apps over opengl, but also SDL2 ones. At moment it can be quake3 for seeing how it different by speed in compare with sdl1 version, when both over gl4es.

Join us to improve dopus5!
AmigaOS4 on youtube
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
@Hans
Trying to port latest cube2 (SDL2 for now), and seems cube2 now use shaders in any case (before it was possible to switch usage of shaders off), so we need firstly to fix some issues in warp3dnova shader's compiler before i can go futher with it

There are 4 of them which is necessary to deal with:

Unsupported opCode OpImageSampleProjImplicitLod

Warp3DNova didn't accept empty fragment shaders

Vertex shader with arrays support issue 1

Vertex shader with arrays support issue 2

@All
Also build SDL2 version (Capehil's one) of quake3 via gl4es, but it has some strange issue at first run which disappear once i start actual game, see screenshot:

(press to open in new tab for fullsize):
Resized Image

Very well can be because of the way i added hackingly gl4es support to SDL2 (like forgot something which wasn't need with SDL1?). Once i start levels itself, that trashing gone.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information

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
@Capehill
Yes, recompiled sdl2 version with that change over gl4es and vertex arrays works, thanks !

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 ... 14 15 16 (17) 18 19 20 ... 42 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project