Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
50 user(s) are online (44 user(s) are browsing Forums)

Members: 1
Guests: 49

VooDoo, more...

Headlines

Forum Index


Board index » All Posts (Georg)




Re: Does AOS4 continue to keep the pointer to Exec library at address 0x4?
Just popping in
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).

Go to top


Re: Qt 6 progress
Just popping in
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)

Go to top


Re: I like to write graphic-card.chip file of my own, how do I start?
Just popping in
Just popping in


On this page

http://wiki.icomp.de/wiki/P96#Hardware_manufacturer_archive

it's possible to download "CardDevelop.lha" which seems to contain headers and sample driver source code.

Go to top


Re: I like to write graphic-card.chip file of my own, how do I start?
Just popping in
Just popping in


68k P96 driver development infos and docs are public since some time:

http://wiki.icomp.de/wiki/P96_Driver_Development

Go to top


Re: System crashes in loop
Just popping in
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.

Go to top


Re: Why call to or any "empty" functions cause different results of the other code execution ? FIXED!
Just popping in
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"

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


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.

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


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.

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


@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().

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


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.

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


What happens if you call

glFlush();

before

glGetObjectParameterivARB(...);

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


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);

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


[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).

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


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);

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


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


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.

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


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

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


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");

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


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().

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


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)"

Go to top



TopTop
(1) 2 3 4 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project