Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
66 user(s) are online (54 user(s) are browsing Forums)

Members: 0
Guests: 66

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 ... 17 18 19 (20) 21 »


Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
Quote:

There's no bug in the way; it's all about optimization. However, I'm not sure why it's 30% slower, or how to optimize it. We don't have tools that could identify the bottlenecks (e.g., cache misses, etc.), so it's more guess work than anything else. I suppose I could try insert some cache prefetching instructions to see if that helps.


Its even not 30%, but almost 35% slow down.. Anyway i am ready to do any tests in fast time line :) Just send me any version with inserting cache prefetching instructions so we can see how it will behave and will there be any change.

In general, even if it will be not faster than with Daniel's patching code, it at least should be the same at minimum (i mean it can be even a little bit faster, as warp3dnova is more low-level than ogles2).

I also do check serial output , in hope you may forget to remove debugging stuff which make it slow down, nope, all clean on serial.. (if only you have some internal debugging code for patching left ?)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Daniel,Hans
I already asked about Capehill in SDL2 thread, but that can be and not because of SDL2, so maybe some of you may have some ideas what can cause that:

I build quake3 via SDL2/gl4es , and some time (not all the time, but from time to time, mostly when there is something else running which use warp3d/ogles2, like Candy for example, or Spencer, i.e.to fill VRAM more), then on running it looks like this:

(for all images press open image in new tab for full size)

Resized Image


Another time it may looks like this:

Resized Image

If i switch resolution, distortion removes, but then, mouse movement leave such trails:

Resized Image

It even can be like this:

Resized Image

I.e. can be seen some part of previous background from video, like it didn't erased fully.

I ask ptitSeb for help, and he do trace of how that black background draws in the q3 , and there noothing spectacular:

It's drawn using a fully white texture (the 2nd loaded texture) that is 8x8 RGB. It's setup as GL_REPEAT (if both direction). The color is applied is obviouvly black (using 4 GL_UNSIGNED_BYTE arrays), the vertices are 3 GL_FLOATS and textures coord are 2 GL_FLOAT.

Blend is activated, with GL_BLEND_SRC_ALPHA / GL_BLEND_ONE_MINUS_SRC_ALPHA, so with and RGB texture is the same as no blend. Depth text is also activated.

Of course, he on Pandora didn't have anything of that sort. And he say they (ioquake3) didn't change the way how it draws. He use some older build of Quake3 based on SDL1 , so, i can't rule out gl4es as well of course (but, most of time, it wasn't gl4es in end , so it is probabaly something on our side).


Edited by kas1e on 2018/12/3 9:37:42
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1976
@kas1e

Quick answer: try inserting code to clear the depth buffer to a constant value when it's first created. You may wish to stick that code in GL4ES (or GLES2), because there are multiple programs using the Q3 engine that make this mistake.

Longer answer:
That reminds me of something we saw with the old W3D_SI driver and OpenJK (which is based on the Q3 engine). Basically, the game doesn't clear the z-buffer prior to use. Since we're using a floating-point depth buffer, that means it may contain illegal floating-point values, which causes some pixels to fail the depth-test when they shouldn't. Pandora may well use an integer depth-buffer, in which case this can't happen.

In the W3D_SI driver I worked around this by clearing the depth buffer on allocation. I tried to do that too in Warp3D Nova, but Warp3D Nova is more complicated, e.g., you can have depth-textures. So I guess the workaround doesn't actually work.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
But then it should be the same and when i compile quake3 via SDL1/gl4es. With SDL1 it for sure didn't happens. I tried hard : running spencer, some gl4es game and then sdl1 version of quake3 compiled via gl4es : all fine. But with SDL2, its enough to run one single instance of something which use warp3dnova/ogles2, and then running quake3 compiled via SDL2 will cause that distortion.

Maybe in SDL1 there is some hack for it was done ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
Ptitseb says that yeah, that make sense, and also SDL1 and SDL2 may create the context slightly differently, get a depth+stencil in a side and only depth in another side, or with different bits 16 against 24.

I then check what kind of values have SDL1 and SDL2 for depth and buffer when create context, and while stencil always TRUE (0) , in both cases, DEPTH for SDL1 was 16, and 24 for SDL2. But when i set hardcode 16 for SDL2 as well, it didn't help at all too.

That strange , but maybe in SDL2 somewhere else something related to depth/stencil done, which didn't for SDL1.

Anyway, to test that theory we just after swapbuffer do:
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);

And it did the trick. But that mean its kind of hack, will give a little speed loss where it don't need as well as still strange why SDL1 behave different in that respect..

Another little issue i notice also , is that in the same menu, i can see a little small white point when run in window mode : it is where real amiga cursor stays. But that probabaly related just to SDL2 itself..

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From A haunted Castle somewhere in the Bavarian Mountains
Posts: 3169
@kas1e

That little dot where the hotspot of the mouse pointer is, is known since SDL2 got released the first time (I have it in ScummVM aswell), that isn't a problem in SDL1.

Normally you wouldn't see it as the pointer used would draw over it, but whenever there is some lag and the pointer behaves sluggish it's very good to see as the little dot moves faster.

There seems to be something not 100% erased when drawing/erasing the pointer gfx or SDL2 handles the pointer differently.

_________________
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr. John Zoidberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Raziel
Oh, that good ! I mean that good that its SDL2 issue and not minigl or gl4es ones. In the quake3 i can notice it pretty well! Is it reported already or should i create bugreport for ?


@Hans
Probabaly Mattew still not fix bug-report site and still no notification come when bugreports created.. So i just duplicate it here : i found another issue in the array's support, and made as small as possible test case. Check this out plz there:

Vertex shader with arrays support issue 3


_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From A haunted Castle somewhere in the Bavarian Mountains
Posts: 3169
@kas1e

I think i mentioned it back when the sdl2 code was still on sourceforge.

I don't see a bug item on github, so be my guest

_________________
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr. John Zoidberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1976
@kas1e
Quote:
I then check what kind of values have SDL1 and SDL2 for depth and buffer when create context, and while stencil always TRUE (0) , in both cases, DEPTH for SDL1 was 16, and 24 for SDL2. But when i set hardcode 16 for SDL2 as well, it didn't help at all too.

Warp3D Nova always uses floating-point depth buffers.

Quote:
Anyway, to test that theory we just after swapbuffer do:
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);

And it did the trick. But that mean its kind of hack, will give a little speed loss where it don't need as well as still strange why SDL1 behave different in that respect..

No need to clear the depth buffer every frame; just do it right after it's created.

Perhaps SDL1 does this, as I can't think of any other reason why this would only happen with SDL2.

Hans


_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
Quote:

Perhaps SDL1 does this, as I can't think of any other reason why this would only happen with SDL2.


Didn't find in SDL1 anything about glClear() being called, but probabaly maybe its done some other way..

Btw, updated bugreport with info you ask.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
Quote:

No need to clear the depth buffer every frame; just do it right after it's created.


Right, i just doing that in SDL2 now when create context:

SDL_GLContext OS4_GL_CreateContext(_THISSDL_Window window)
{
        
        
int widthheight;

        
OS4_GetWindowActiveSize(window, &width, &height);

        
ULONG errCode 0;

        
SDL_WindowData *data window->driverdata;

        if (
data->glContext) {
            
dprintf("Old context %p found, deletingn"data->glContext);

            
aglDestroyContext(data->glContext);

            
data->glContext NULL;
        }

        
dprintf("Depth buffer size %d, stencil buffer size %dn",
            
_this->gl_config.depth_size_this->gl_config.stencil_size);
            
            
        
struct TagItem create_context_taglist[] =
        {
            {
OGLES2_CCT_WINDOW, (ULONG)data->syswin},
            {
OGLES2_CCT_DEPTH_this->gl_config.depth_size},
            {
OGLES2_CCT_STENCIL_this->gl_config.stencil_size},
            {
OGLES2_CCT_VSYNC0},
            {
OGLES2_CCT_SINGLE_GET_ERROR_MODE,1},
            {
OGLES2_CCT_RESIZE_VIEWPORT,TRUE},
            {
TAG_DONE,    0}
        };

        
data->glContext aglCreateContext2(&errCode,create_context_taglist);

        if (
data->glContext) {

            
dprintf("OpenGL ES 2 context %p created for window '%s'n",
                
data->glContextwindow->title);
            
            
// Some games (like q3) doesn't clear the z-buffer prior to use. Since we're using a floating-point depth buffer in warp3dnova,
            // that means it may contain illegal floating-point values, which causes some pixels to fail the depth-test when they shouldn't,
            // so we clear the depth buffer to a constant value when it's first created.
            // Pandora may well use an integer depth-buffer, in which case this can't happen.
            // On MiniGL it didn't happens as there is workaround inside of warp3d (and probabaly inside of MiniGL itself too).
            // in SDL1 it didn't happens probabaly because SDL1 doing something like that (but not glClear).
            
            
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
            
            
aglMakeCurrent(data->glContext);
            
glViewport(00widthheight);
            
            return 
data->glContext;

        } else {
            
dprintf("Failed to create OpenGL ES 2 context for window '%s' (error code %d)n",
                
window->titleerrCode);

            
SDL_SetError("Failed to create OpenGL ES 2 context");
            return 
NULL;
        }


    return 
NULL;

    
}


And it seems to work as well. Maybe just in case clear stencil buffer as well ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1976
@kas1e
Quote:
And it seems to work as well. Maybe just in case clear stencil buffer as well ?

Glad that's solved it.

Might as well clear the stencil buffer too, although it's unlikely to have a problem (it'll never be a floating-point buffer).

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
I also found today a crash in warp3d (well, its last line in stack trace, it can be ogles2 too of course). At moment i didn't have small test case to reproduce, but crash happens in code which call glPushAttrib(0xFFFFF) (i.e. mask mean to push everything), and it crashes like this:

Quote:

Stack trace:
(0x59140D20) module LIBS:Warp3DNova/W3DN_SI.library at 0x7EFDFAC4 (section 0 @ 0x6AA0)
(0x59140FF0) module LIBS:ogles2.library at 0x7F455F0C (section 0 @ 0xBEE8)
(0x59141070) GameEngine:gl4es_glPushAttrib()+0xe50 (section 1 @ 0xB2C4D0)
(0x591410C0) GameEngine:_ZN13COpenGLRender5ClearERK7CVectord()+0x74 (section 1 @ 0x356224)
(0x59141100) GameEngine:_ZN15CGameWindowBase16OnDrawBackgroundEP14IGenericRender()+0x1bc (section 1 @ 0x9153B8)
(0x59141220) GameEngine:_ZN15CGameGUIManager12RenderWindowEP14IGenericRenderP11IGameWindow9SGameRect()+0x3ec (section 1 @ 0x417E08)
(0x59141430) GameEngine:_ZN15CGameGUIManager12RenderWindowEP14IGenericRenderP11IGameWindow9SGameRect()+0x6e4 (section 1 @ 0x418100)
(0x59141640) GameEngine:_ZN15CGameGUIManager8OnRenderEv()+0x11c (section 1 @ 0x418384)
(0x59141710) GameEngine:_ZN15COpenGLViewport6RenderEv()+0xf0 (section 1 @ 0x3B3F2C)
(0x59141730) GameEngine:_ZN15COpenGLViewport9EnterLoopEv()+0xfc (section 1 @ 0x3B491C)
(0x591417A0) GameEngine:_ZN15CGameGUIManager12EnterGUILoopEv()+0x50 (section 1 @ 0x4173D4)
(0x591417C0) GameEngine:_ZN14CGameEngineApp3RunEv()+0x53c (section 1 @ 0x5920)
(0x59141B60) GameEngine:main()+0x2f0 (section 1 @ 0x67DC)
(0x59141D10) native kernel module newlib.library.kmod+0x00001e7c
(0x59141D70) native kernel module newlib.library.kmod+0x00002d6c
(0x59141F20) native kernel module newlib.library.kmod+0x0000305c
(0x59141F50) GameEngine:_start()+0x170 (section 1 @ 0x1920)
(0x59141F90) native kernel module dos.library.kmod+0x00026724
(0x59141FC0) native kernel module kernel+0x0006b268
(0x59141FD0) native kernel module kernel+0x0006b2b0


We put printfs all over the place, and found that it crashes on stencil part of gles_glPushAttrib.

Ptitseb have a guess that there is a bug (in Warp3D?) when getting/settings stencil stuff and there is no stencil buffer.

But if that info not enough i may try to create some test case for, or get more info

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1976
@kas1e

Please send me the rest of the crash log. The stack trace alone is not enough.

It's crashing in GetStencilFunc(), but I'd like to know exactly where. I have spotted a potential issue, but the stack trace suggests that it might actually be an invalid Warp3D Nova context pointer.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
Yeah sure, there is full crashlog:
http://kas1e.mikendezign.com/aos4/gl4 ... e_2018-12-05_11-13-43.txt

Probabaly its indeed problem when getting/settings stencil stuff and there is no stencil buffer, as it is allowed to query stencil status even if no stencil buffer is present and change are also permited (but they'll have no effect with no stencil buffer) , but probabaly as we do not have buffer , nova just crashes.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 130
@Hans
Looking at the crash code line
Quote:
stw r9,0(r7)

and at the whole fragment
Quote:

7e7d4abc: 91260000 stw r9,0(r6)
7e7d4ac0: 812400b8 lwz r9,184(r4)
*7e7d4ac4: 91270000 stw r9,0(r7)
7e7d4ac8: 812400c0 lwz r9,192(r4)
7e7d4acc: 91280000 stw r9,0(r8)

while considering that r7 and r8 are both 0 in this stack trace, I'd like to place a bet on the following
Did you maybe forget to check the optional pointer-return-parameters of GetStencilFunc being NULL or not?



   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1976
@Daytona675x

Quote:
Did you maybe forget to check the optional pointer-return-parameters of GetStencilFunc being NULL or not?

Close. It checks the first pointer three times...

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 130
@Hans
Aaaah, a true classic

   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 130
@Hans
Quote:
Do you really want the responsibility of doing all the endianness conversion?

No, the driver knows best which endianness is needed.

Quote:
If there's enough interest, I could add the ability to check the GPU's endianness and disable the endianness conversion, making it the app's/game's responsibility (or the GLES2 wrapper's).

The only thing that comes to my mind where it could in theory result in somewhat better performance is if you are updating a VBO every frame and have direct access to the VRAM (if you don't then another internal copy is required anyway and then e.g. a tight stwbrx loop is likely better) and if you can do the conversion without poluting your code. IMHO it's not worth the trouble.
Althoug... if you can offer that feature for free and optional and if you don't have more important things to do, then go ahead

Quote:
There's no bug in the way; it's all about optimization. However, I'm not sure why it's 30% slower, or how to optimize it. We don't have tools that could identify the bottlenecks (e.g., cache misses, etc.), so it's more guess work than anything else. I suppose I could try insert some cache prefetching instructions to see if that helps.


Maybe the opposite is better. Did you by accident call dcbz on the (VRAM) destination? This could probably result in such a dramatic slowdown.
Also: are you 100% sure that there aren't any debugging artefacts remaining?

Other than that: we are talking about Roman's performance numbers here. He has an X5000 and from my experience (!) its automatic cache prefetching works pretty well, in contrast to other PPCs. So, unless you have any weird access pattern (which you should not have?) manual prefetching shouldn't change the picture toooo much in this case here.

But it's hard to come up with concrete hints without source, of course


   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4668
@Hans
I feel your pain, but there is another shader's issue: Just porting another game, and it fail right in the face: this time is fragment one (for fogging), and pretty small one. I attach all the stuff to the ticket (all info, shader, plain output of w3dnshaderinfo, and verbose one). There is:

Fragment's shader issue

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top


« 1 ... 17 18 19 (20) 21 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project