Who's Online |
50 user(s) are online ( 44 user(s) are browsing Forums)
Members: 1
Guests: 49
VooDoo,
more...
|
|
|
|
|
Re: Does AOS4 continue to keep the pointer to Exec library at address 0x4?
|
|
Just popping in 
|
@tonywQuote: tonyw wrote:@rjd324
So you must have the address of exec.library first of all.
Since it can change at any time (could be loaded in a different place since it's not in ROM any more), the address is stored in a known place, ie 0x4. It's always possible to write things in such a way that this is never necessary. Libraries/Devices get SysBase as param in init call and can store it somewhere else for future use. Similiar thing when creating new processes. There's always some way to pass knowledge about SysBase along. In AROS/hosted for example there is no SysBase at 0x4. Instead trying to access that address causes segfault (AROS/hosted is really just a normal linux process/program but still 99% identical to the native version).
|
|
|
|
|
|
Re: Qt 6 progress
|
|
Just popping in
|
How much sense do this funny shared objs make anyway, with something as big as the QT libs? They are not really shared anyway in most important place (memory), only in least important place nowadays (disk). Only advantage is, that if new version of libs come out, the exe using them does not need to be re-linked statically.
How big is a simple QT gui sample program if linked statically? Size in memory will be somewhat similiar.
If you have same sample program but linked with shared objects then complete huge (I guess) QT shared objs used by program will end up in memory. If some stuff in the shared obj is referenced. Unlike static linking where parts (.o files) in the lib which are not needed do not end up in exe and later in memory. And if you start program twice or have other QT programs running then each will have their own copy of huge (I guess) QT shared objs in memory.
I think ... (I'm no AOS4 guy)
|
|
|
|
|
|
Re: System crashes in loop
|
Posted on: 2022/6/22 7:43
#5
|
Just popping in
|
@RazielQuote: Raziel wrote:@LiveForIt
The infamous "soft reboot gfx card crash", see also here for some more detail.
Nothing can be done about it... is being said ... but has anyone ever tested this under Linux? I never tried but it seems to be actually possible to have an Amiga-like soft-reboot in Linux using kexec or kexec-reboot. So nothing goes through hardware/BIOS/whatever initialization. Also in Linux and other OSes you have virtual machines which allow gfx card pass through. Starting/quitting/restarting virtual machine would then for the gfx card be like a soft reboot, where it is not re-hw-initialized in BIOS/whatever. If "nothing can be done about it", it would mean you could start virtual machine only once and second and future starts it would fail, too.
|
|
|
|
|
|
Re: Why call to or any "empty" functions cause different results of the other code execution ? FIXED!
|
Posted on: 2022/3/12 17:24
#6
|
Just popping in
|
@Daytona675xQuote: @kas1e
As I said: there's no word about that in the OpenGL ES 2 specs (unless I'm totally blind). So an implementation may chose whichever ID generation algorithm it may like.
I'm not sure and I don't know OpenGL but https://www.khronos.org/registry/OpenG ... /2.0/es_full_spec_2.0.pdf in chapter "2.10.1" says: "The name space for shader objects is the unsigned integers, with zero reserved for the GL. This name space is shared with program objects"
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/12 6:37
#7
|
Just popping in
|
In test program print out the the return values of glCreateProgremObjectARB() (data->program) and glCreateShaderObjectARB() calls (data->vert_shader and data->frag_shader) to see what they return.
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/12 6:34
#8
|
Just popping in
|
Quote:
gl4es seems to think that passed shader object is a program object and then it calls glGetProgramiv with GL_COMPILE_STATUS which triggers GL_INVALID_ENUM and uninitialized status, because
Yes, if shader creation and program creation on Amiga side of things (ogles2.library?) return integer IDs that may match (ie. a created program could return ID 1 and a created shader could also return ID 1) then this is likely what is happening and causing the problem.
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/7 13:27
#9
|
Just popping in
|
@CapehillQuote: @kas1e
If not uninitialized variable or stack related It's only the GetObjectParameterivARB() function call to check compile status which fails at least in first call for some reason (either function buggy or since it is a function pointer, it is not pointing to correct function) and the biggest fail is that it does not set status variable at all which should never happen. That's why the status variable stays undefined after first call and why he can ~"fix" it with magic printf() or other function calls in parent function or by setting it to a defined value (like 1234) before call to GetObjectgParamterivARB().
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/7 13:17
#10
|
Just popping in
|
glGetObjectParameterivARB(), glCompileShaderARB(), etc. are function pointers set up with SDL_GL_GetProcAddress(). But where are this #?ARB functions listed? In https://github.com/kas1e/SDL2_GL4ES/bl ... SDL_os4opengles2wrapper.c they don't show up in the table in there. Which would normally cause SDL_GL_GetProcAddress() to return NULL I guess. Idea was that maybe there's some typo in some table and the function name is resolved to the wrong function. Btw, what if you change glGetObjectParameterivARB() calls (and function pointer setup) to glGetShaderiv() calls. Seems to do the same thing.
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/6 13:06
#11
|
Just popping in
|
What happens if you call
glFlush();
before
glGetObjectParameterivARB(...);
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/6 11:56
#12
|
Just popping in
|
Buggy glGetObjectParameterivARB() maybe. What happens if you call the function twice:
glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);
glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/6 11:38
#13
|
Just popping in
|
[quote]
do
status = 1234;
before calling
glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);
to see if the function modifies the status variable at all or not (would mean unimplemented attribute or something).
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/6 11:32
#14
|
Just popping in
|
As said IMO it's very likely problem of some uninitialized variable in this shader compiling stuff. Maybe somewhat hidden (compiler may not warn about it) if for exampled caused as side effect of unimplemented/unhandled functionality/attributes/whatever.
The thing with the call of the magic functions (printf(), Delay(1)) that make things work, is, that the calling of this functions will cause modification of things on the stack so they will influence how uninitialized variables look like when they end up being used in other code (shader compilation) which is exectuted after that = ~"in the future".
Funny experiment: If
Delay(1);
works, but Delay(0) doesn't it probably is possible to make the working thing not-work again by calling both:
Delay(1);
Delay(0);
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/4 16:33
#15
|
Just popping in
|
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 ...
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/4 7:40
#16
|
Just popping in
|
IIRC in AROS I once had a funny situation in a some test program which opened a window and would quit when you press some key. In the shell you typed in the command, pressed RETURN key, the window opened quickly and the RETURN key release happened after that and so the event went to the window/test program which then quit immediately.
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/4 7:32
#17
|
Just popping in
|
Btw, what does "not work" mean? Does it crash? Does it quit?
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/3 12:07
#18
|
Just popping in
|
To me this does not look or "smell" like race condition or timing related at all. Add an always failing runtime checked (to make sure it can't be optimized away) check around printf call that usually makes the thing work and see what happens. If it still works even if the actual printf() call never gets executed then you know it's not timing/race condition problem.
- printf("blablabla")
+ if ((int)SysBase == 0x1234) printf("blablabla");
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/2 17:12
#19
|
Just popping in
|
Quote:
I just add before another function in the whole source, like:
static SDL_bool Omega1200(void)
{
IDOS->Delay(1);
}
If the function never gets called it may be optimized away. Quote:
What is more fun, if i use small printf() like prinf("a"); then it also didn't fix issue, but more "a" i put, then it works.
The compiler may have optimized printf() into a putchar().
|
|
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
Posted on: 2022/3/2 15:20
#20
|
Just popping in
|
It may also just be that your magic function (Delay() or printf()) triggers some linker autoinit stuff which is otherwise not happening.
What happens if you put the Delay() or printf() in some place in the .c file which never gets called. Or inside some check which never is true (but make sure it's not something the compiler optimizes away completely). Like "if (SysBase->SysFlags == 0xABCD)"
|
|
|
|
|
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
TuneNet forum
Unsatisfactory Software forum
