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 (i = 0; i < NUM_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"
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")
}
Basically you add a linenum = __LINE__; before return statements to track where it returned.
It returned in this loop:
/* Compile all the shaders */
for (i = 0; i < NUM_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.
@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):
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)
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.
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 ?
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?
@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',
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.
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.
@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
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()?
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?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
