Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
40 user(s) are online (22 user(s) are browsing Forums)

Members: 0
Guests: 40

more...

Headlines

 
  Register To Post  

« 1 (2) 3 4 »
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@Georg
Quote:

Btw, what does "not work" mean? Does it crash? Does it quit?


Does work : shaders compiles, does not work : shaders didn't compiles.

In InitShaders() we have:

/* Compile all the shaders */
  
245     for (0NUM_SHADERS; ++i) {
  
246         if (!CompileShaderProgram(&shaders[i])) {
  
247             SDL_LogError(SDL_LOG_CATEGORY_APPLICATION"Unable to compile shader!\n");
  
248             return SDL_FALSE;
  
249         }
  
250     }


If i add before that part in any part of the whole initshader() function prinfs or delay(1), then they compiles and works. If it as it (without printf before or delay), then we have "unable to compile shaders"

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just can't stay away
Just can't stay away


See User information
@kas1e

Which SW layer triggers the error: test program, GL4ES, OGLES2 or NOVA? Have you checked for example with glSnoop?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@Capehill

At the moment dunno about layers, but you mean to find out which one with glSnoop ? Or you mean and check with glSnoop, and to check something else ?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just can't stay away
Just can't stay away


See User information
@kas1e

If glSnoop confirms that OGLES2 compiles shader OK, then I suppose problem must be somewhere above.

On the other hand, if OGLES2 failed compilation, we should see the parameters in case there is some corruption or such.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
@kas1e

Do you know which shader fails? Just add an SDL log error whenever a shader is compiled and you should see… 4 of them, I guess from looking at the code linked.

Something like this:
if (!CompileShaderProgram(&shaders[i])) {    
  
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION"Unable to compile shader!n");   
  return 
SDL_FALSE;    
} else {
  
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION"Compiled one shader!n"
}

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@Bszili
Aha got it, but

Quote:

Basically you add a linenum = __LINE__; before return statements to track where it returned.


It returned in this loop:

/* Compile all the shaders */
    
for (0NUM_SHADERS; ++i) {
        if (!
CompileShaderProgram(&shaders[i])) {
            
SDL_LogError(SDL_LOG_CATEGORY_APPLICATION"Unable to compile shader!n");
            return 
SDL_FALSE;
        }
    }


@Capehill
Thanks will check. At least we will see indeed where things corrupt.


@jaokim
Just to clear the things if you didn't read the whole topic :): shaders works, they are correct. They work once we add "delay". And didn't when there was no "delay". And i can't add any "new" prinfs anywhere, because it fixes the things. I.e. my question in that topic and problem we discuss, is that everything worked when we add prinf (anywhere), or Delay(1) (anywhere) in that whole initshader() function.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
@kas1e

I don't think it's a race condition.
What if Delay (0)?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@flash

IDOS->Delay(1); make it works/compiles , IDOS->Delay(0); make it not.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@Capehill
How funny is: when i run glSnoop, then, in any case, i have "failed to compile shader:", with or without prints. Once i quite glSnoop, then the version without prints the same "failed to compile", but the version with prints starts to compile it.

Wtf ?:)

There is i have output from glSnoop (doesn't matter with or without prints, always fail):


http://kas1e.mikendezign.com/aos4/ogl ... lsnoop_without_printf.txt

Can you spot anything intersting here?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just can't stay away
Just can't stay away


See User information
@kas1e

Quote:

Shell Process 'test2': OGLES2_glCreateShader: type 0x8B31 (GL_VERTEX_SHADER). Created shader 256
Shell Process 'test2': OGLES2_glShaderSource: shader 256, count 4, string 0x5f517b68 length 0x0
Line 0: '#version 120'
Line 1: '
layout(location = 0) in vec4 vecPos;
'
Line 2: 'layout(location = 0) uniform mat4 matMVP;
'
Line 3: 'void main() {
gl_Position = matMVP * vecPos;
}
'
Shell Process 'test2': OGLES2_glCompileShader: shader 256
Shell Process 'test2': GL error 1282 (GL_INVALID_OPERATION) detected


It seems that OGLES2 actually returned error, but I don't know why.

https://www.khronos.org/registry/OpenG ... tml/glCompileShader.xhtml - "GL_INVALID_OPERATION is generated if shader is not a shader object."

Maybe Daniel needs to comment?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
My guess now is that it's most likely some unimplemented functionality which causes some uninitialized variable to stay uninitialized and therefore causing random behaviour (which can be influenced by adding removing "magic" calls)

Like maybe in SDL_shaders_gl.c:

GLint status;

...

ctx->glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);

If this GL_OBJECT_COMPILE_STATUS_ARB param/flag/whatever is not implemented in the GL libraries or whereever ...

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
@kas1e
Quote:
Just to clear the things if you didn't read the whole topic :): shaders works, they are correct. They work once we add "delay". And didn't when there was no "delay".

I think I read it all. And I didn’t ask to add a printf, but the sdl error print. But perhaps that does the same thing. Just wanted to find out if the first shader in the loop failed or the last.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@jaokim
Quote:

Just wanted to find out if the first shader in the loop failed or the last.


Yeah, tried what you says, and have in return "unable to compiled shaders", so i even didn't have "compiled one shader", which mean, we fail even on first one.

@Georg

In my case we didn't use the original "shaders" code from the SDL2, in my case, we use SDL2 built around GL4ES, which, has the ability to use ARB shaders based functions. So it's just "SDL2 with OpenGL 2.x" and no shaders involved from SDL2 itself.

But then, this GL version I use (GL4ES), has the ability to use ARB functions, etc so that is what i have.

Through, interesting that you point out on that, that in SDL_shaders_gl.c there are 13 ARB functions initialized, while in my case 12. So i add 13st one "glUniform1fARB" and recompile without prinfs - nope, still "shaders can't be compiled".


@Capehill
Do you know if ARB shaders work with MiniGL? Or it's too much for MiniGL ?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
@kas1e

Now, Im just guessing obviously. But I found this link, glgeterror not resesseting its flag, that says that "glGetError should always be called in a loop, until it returns GL_NO_ERROR".

Could it be that glGetError (line 156 testherader.c) doesn't clear all flags, but calling printf and delay does (since tehy succeed)? Perhaps just check what glGetErrors returns, and possibly wrap it in a loop?
while(glGetError() != GL_NO_ERROR) ;


Or something?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
@jaokim
hmm... interesting you might have hit on something there, for instance does ppc have a clear flag (status register), and btw. if it really is delay(1); that makes it work.. how about NOP's in the code instead of delay(1), it should do the same thing... if it doesn't work then it isn't the wait that makes the code work, then it is most likely a status flag (register) that is 'misbehaving',

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@trgswe
Quote:

if it really is delay(1); that makes it work.. how about NOP's in the code instead of delay(1), it should do the same thing... if it doesn't work then it isn't the wait that makes the code work, then it is most likely a status flag (register) that is 'misbehaving',



Just tried:

asm volatile("nop\n" 
              "nop\n"
               
);


And nope, no differences. But i should say that not _any_ function fix things. For example adding rand() instead of prinfs or delay(1) didn't fix thing.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just can't stay away
Just can't stay away


See User information
@kas1e

Didn't test anything myself, but just judging from the comments so far, any call to a function causing a task switch "fixes" it, adding any other delay doesn't "fix" it, it looks too me like an IGraphics->WaitBlit() call is missing somewhere. Might be in SDL, in gl4es, Warp3D, the Radeon driver, or even something else used by those parts.

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Home away from home
Home away from home


See User information
@joerg
Just for sake of tests put IGraphics->WaitBlit() instead of prinfs/delay(1) - nope, no luck.

Intersting, that things also stop works, when i run glSnoop (glsnoop is tool which patch ogles2/warp3dnova, and trace the calls, so we can see what happens inside). Even delay(1) and prinfs("aaa"); didn't help anymore if i run it over glsnoop. That probably point out on some unitialized crap which reacts completely different, depends on what happens in system

edit:

those which _didn't_ fix issue:

printf("");
IDOS->Lock("",SHARED_LOCK);
IDOS->Open("aa", MODE_NEWFILE);
IDOS->PutStr("");

those which _do_ fix issue:

prinf("\n");
IDOS->Printf("");
IDOS->Delay(1);
IDOS->PutStr("\n");


Edited by kas1e on 2022/3/5 20:43:52
Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Just popping in
Just popping in


See User information
@kas1e

What if you put the printf() or Delay() at the very beginning of your function, before making any of the SDL calls? Does it work there? What if you put it at the very end, just before the "return SDL_TRUE;"? (Which means it won't even be called if compiling the shaders fails.) Or does it have to be in between the two sets of SDL calls in order to make a difference?

And what if you use IExec->DebugPrintF() rather than printf()?

Go to top
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
Quite a regular


See User information
@kas1e

Please try using IExec->DebugPrintF() instead of printf(). "printf()" calls a clib/newlib library function which WILL inevitably cause a Reschedule() and that will allow other tasks to run, even if only briefly.

DebugPrintF() does NOT call any C library code: it writes directly to the serial port without using interrupts, or Waits, or any code that could encourage or force a Reschedule().

My guess is that DebugPrintF() will act the same as (no printf() at all) does, suggesting that your problem is "fixed" by forcing a Reschedule().

If that is true, then you have to find out why preventing a Reschedule() prevents the "compile" from working. I don't know anything about these advanced graphics, so I don't even understand what you are "compiling".
But presumably there is a Process that has to operate on some pseudo-code or tokenised code, and it fails unless something else gets control of the CPU sometimes. Correct?

Go to top

  Register To Post
« 1 (2) 3 4 »

 




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




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project