Glide64 plugin not working

[delmonico]

Hi!

I can't get the Glide64 plugin to work Mupen will just crash. glN64 works, but its compatibility isn't too good. I tried on Arch and a fresh SuSE-Test-Installation, but I only get this error:

init timer!
memory initialized
[blight's SDL input plugin]: version 0.0.8-b initialized.
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
(II) JttL's sound plugin version 1.2
(II) Initializing SDL audio subsystem...
(II) Allocating memory for audio buffer: 65536 bytes.
demarrage r4300
Signal number 4 caught:
errno = 0 (Success)
Signal number 11 caught:
errno = 0 (Success)

Graphics card is a nvidia Geforce 2 GTS, current nvidia drivers are installed. Has anyone got an idea on how to fix this?

del

 

[rcgamer]

you did install a wrapper right.

 

[delmonico]

I emailed Hacktarux yesterday and he said I wouldnt need one. So where can I get a glide wraper for linux? I searched google but it looks like I'm missing the magic words

 

[BountyJedi]

well you wont be missing a wrapper for linux thats only for windows the wrapper is compiled in or something in the plugin of the linux version.
For windows you chould download one though and download latest version of glide.
But dont bother about that when running under linux.

 

[tkf]

I have a related question, do Hacktarux's ported gfx plugins require a SSE capable processor?
It seems so, since it compiles default with the -msse option and removing it breaks a lot of things I cannot figure out.
Since the emulator is receiving SIGILL it would seem to me that is your problem too, delmonico.

 

[Hacktarux]

I have a related question, do Hacktarux's ported gfx plugins require a SSE capable processor?
It seems so, since it compiles default with the -msse option and removing it breaks a lot of things I cannot figure out.
Since the emulator is receiving SIGILL it would seem to me that is your problem too, delmonico.

Interesting... this flag is supposed to enable sse instructions but it doesn't tell the compiler to generate sse instructions afaik... i'll try to check on my system if it still work when i remove this flag.

delmonico: what's your processor ?

 

[blight]

-msse makes gcc use SSE everywhere as far as i know (i.e. for memory moves, ...)

 

[ciruZ]

Hacktarux: Is your assembly code using some of the C code somewhere? That can be the reason why it's not compatible without SSE. GCC makes some calls different without SSE maybe.
If you are using gas (you are using it if you use gcc for compilation) it can be useful to add something like

#ifdef SSE
movq mm0, 0x123456789BCDEF00
#else
mov eax, 0x12345678
#endif

(Intel Syntax [.intel_syntax noprefix] with GAS using the C Preprocessor)

I really can imagine that gcc does a lot different with MMX/SSE activated since many 64-bit variables are used by Mupen64 - I think gcc stores them in MMX/SSE registers if SSE is enabled. And that can really cause trouble. For example, with SSE enabled an SSE register is overwritten, without it two 32-bit registers are overwritten.
Did you pay attention that you always save eax, ecx and edx before calls? The C Calling Convention says that only ebx needs to be kept. It can be that this is only a problem when the SSE registers aren't avilable - because only then the 32-bit registers are overwritten.
It's very likely that this problem occours because of bad / unclean code - I think in the assembly part. I also think that you don't conform to the C Calling Convention somewhere and that's the reason. Maybe I'll look at it when I have time.

 

[blight]

when SSE is not available and you still try to use it the CPU raises a #UD exception (invalid opcode) and the OS usually terminates the app

signal number 4 (which you can see in the output from mupen) is SIGILL

 

[ciruZ]

blight: The problem was compiling it without -msse .
That you can't use SSE on a non-SSE CPU is clear. And that the opcode is unknown there is also clear, I know how x86 works .

 

[blight]

-msse doesnt affect how the OS handles SSE.
If the CPU/OS combination support SSE, it is gonna work. If they don't you will get SIGILL. what -msse does is to enable builtin functions (look at http://gcc.gnu.org/onlinedocs/gcc-3...din-Functions.html#X86-Built_002din-Functions)
You can perfectly build things without -msse and use SSE instructions inside (of course you can only get them in through assembler then, not using the builtin functions since they are only available with -msse)
Trust me, I have built Mesa with SSE support without the -msse flag and it works perfectly well.

 

[ciruZ]

Where have I said something about how the OS handles SSE?
Where have I said that you can't compile inline assembly that uses SSE without -msse?

Nowhere!

The problem was that Mupen doesn't run when it's compiled without -msse. -msse says GCC that it should optimize the Code for SSE. This means that all those 64-bit variables are stored in SSE registers.
But if you now compile it without -msse, the base registers are used. So function calls that don't overwrite the base registers with SSE activated do so without SSE. And if you don't conform to the C Calling Convention and the GCC Convention, then it generates problems, because eax, ecx and edx needn't to be saved by the function - you have to save them by yourself. If you use SSE, it can be that nothing valuable is in the base registers. But now without SSE there are valuable informations in these registers! Always! But these registers are overwritten because somewhere code violates the C Calling Convention and/or GCC Convention. Do you understand know what I'm talking about? I was never talking about the OS because that's not the problem. The problem is somewhere in the code. Code, that is only thought for use with SSE - I think in the assembly part.

It seems so, since it compiles default with the -msse option and removing it breaks a lot of things I cannot figure out.

Have you tried it in interpreter mode? AFAIK the assembly part is only for the dynarec. And because I think that the bug is a violation against the C Calling Convention and/or GCC Convention it's very likely that it's in the assembly part. So try to use Mupen without that parts. AFAIK you do so if you don't use the dynarec.

blight: Because it seems that we don't understand very well in english I'll write it in german for you:
Ich rede nicht über das Problem, daß SSE Code nicht auf nicht-SSE fähigen Rechnern läuft. Das ist klar und weiß jeder, der ein bisschen Assembly kann. Das sollten sogar die meisten wissen, die kein Assembly können.
Das Problem ist vielmehr, daß der Assembly Code irgendwo die C Calling Convention verletzt oder die GCC Convention. Letztere besagt z.B., daß eax, ecx und edx einfach überschrieben werden dürfen, alle restlichen Register aber gesichert werden müssen.
So, nun verwenden wir _KEIN_ SSE. Also müssen wir die Base-Register nutzen. Aber diese werden vor unserem Call ziemlich sicher nicht gesichert - weil sie normalerweise nichts wichtiges enthalten, da die 64-bit Variablen normalerweise in den SSE Registern gespeichert werden. Nun werden sie aber im Stack (dort werden auch lokale Variablen abgelegt, lies am besten mal die C Calling Convention) und natürlich zum Bearbeiten auch in 2 Base-Registern pro Variable abgelegt. Da der Compiler aber optimiert, versucht er natürlich so lange wie möglich die Variablen in Registern zu halten. Diese werden jetzt aber nicht gesichert und daher beim nächsten call sehr wahrscheinlich überschrieben. Jetzt sollte Dir klar sein, warum es Probleme gibt, oder? Falls Dus immer noch nicht verstehst, erklär ichs Dir nochmal langsam.
Das mit dem SIGILL war was ganz anderes. Das war, als er es mit -msse compiliert hatte. Darum ging es aber gar nicht mehr, da das ein erledigtes Thema ist - dagegen kann er nix machen. Gegen die "Unsauberkeit" an einer oder mehrerer Stellen am Code schon, sodaß diese dann auch funktionieren, wenn der Rest ohne -msse compiliert ist.
Es geht hier die ganze Zeit eigentlich nur darum, wie der Rest compiliert ist. gas oder nasm oder was auch immer interessiert es kaum, ob ein -msse übergeben wird - ein Assembler generiert keinen Code, das macht der Compiler. Und eben dieser Code, der von diesem generiert wird, muss mit dem Assembly Code kompatibel sein. Und dafür gibt es eben die C Calling Convention und die GCC Convention.
Hoffe, Du hast es nun verstanden. Falls nicht, versuch ichs nochmal anders auszudrücken .

 

[Hacktarux]

afaik, ebx register is only required for PIC modules, so if you don't compile with the -fPIC flag it shouldn't be needed i guess. Anyway i've tried to avoid using this register when i ported the plugin (the core should work perfectly with or without -msse) but maybe i've missed something...

 

[ciruZ]

Hacktarux: The ebx register isn't the problem. The problem is that more base registers are used without -msse. So propably your assembly part overwrites one of the base registers - with SSE this is no problem, but without the base registers are more often used than with. I think that's the point why it crashes. Or gcc generates some code completely different with -msse so that it's not compatible with the assembly part.

 

[blight]

ciruz: no comment. you made clear that you dont want to listen and i still think you dont understand what the problem is (not)

 

[ciruZ]

blight: No, you don't listen. You have showed that you don't know anything about Mixing C and Assembly and that's the reason why you are always talking about things that have absolutely _NOTHING_ to do with the actual problem. The actual problem isn't that the processor doesn't support SSE, the problem is that it doesn't work if you compile it _WITHOUT_ (plz read correct now, WITHOUT, not with! You already showed that you can't read!) SSE. Then it doesn't run. If you want to know why, just scroll up.
And now STFU plz. You always say that SSE opcodes doesn't work on non-SSE processors. Do you really think we don't know that? _EVERYONE_ here knows that, so please stop trolling. You're posts are senseless, we're already on a different problem. I recommand that you reread the whole thread.
Sry for german: Falls Dus immer noch nicht verstehst, kannst Du entwerder echt nicht lesen, oder Du bist nur aufs trollen aus. Jeder weiß hier das auf non-SSE Prozessoren keine SSE Opcodes vorhanden sind und das ist auch gar nicht das Problem. Das Problem ist, daß Mupen den Dienst verweigert, wenn Du es ohne SSE Opcodes compilierst - was aber nicht sein sollte. Das hat hier bereits jeder erkannt, nur Du scheints noch nicht. Und ja, ich schreibs extra in Deutsch in der Hoffnung, daß Dus dann kapierst.

 

[blight]

Hmm...

What i meant was that SSE instructions can fault even on processors which support SSE... it happens of the OS doesnt support SSE (the OS has to tell the CPU that it supports it, only then it will enable SSE)
For what it's worth, I have just added SSE support to an OS... (requires inline asm fyi)

I only see people talking about SIGILL (i think tkf does not get SIGILL, he has not provided enough information about his problem) - and thats what i am talking about. So what could lead to SIGILL? Most likely when the app tries to use SSE if there is no support for it.

Of course it could happen when some of the GPRs are clobbered (like you say, with -msse and optimizations enabled GCC might use the SSE regs for 64 bit constants and whatever), but clobbering of a GPR would more likely lead to a general protection or page fault, not an invalid op fault.

So you think the problem is that GCC uses SSE regs with -msse, but GPRs without... please tell me how does GCC access memory in the C functions then? It will definitly use some of the GPRs even for the most simple function which does not void.

Here's the description for -msse:

These switches enable or disable the use of built-in functions that allow direct access to the MMX, SSE, SSE2, SSE3 and 3Dnow extensions of the instruction set.

See X86 Built-in Functions, for details of the functions enabled and disabled by these switches.

To have SSE/SSE2 instructions generated automatically from floating-point code, see -mfpmath=sse.

So at leats the GCC manual does not say that "-msse says GCC that it should optimize the Code for SSE" like you said.

If you could show that I am wrong and you are right it would be nice, but I doubt it and thats why I write they way I write.

 

[ciruZ]

Well, I understood it in a way that the problem with SIGILL only occours when it's compiled _WITH_ -msse, not without. I understood that without other problems occour.
Quote:

It seems so, since it compiles default with the -msse option and removing it breaks a lot of things I cannot figure out.

That's what I was referring to. This sounds for me that no SIGILL occours, but other problems. And I meant that the other problems can be caused by that with the GPRs.
The GPRs are always used, sure. But maybe not saved everywhere. Then Mupen's variables are overwritten with other values - for example return values of calls - and the N64 registers are broken. That's what I meant.

 

[blight]

yes, i must admit i haven't read carefully enough.

but still, like you just said (i hope i understood you right) GPRs are used everywhere - wether with or without -msse in both cases GCC is likely to use all of them because there are only so few (6, right?)
So if there is such a problem without -msse there should be the same with -msse too I think.

 

[ciruZ]

No, the GPRs are always used. But with -msse not for the 64 bit variables. So the 64 bit variables aren't overwritten.
And yes, there are 6 GPRs, but you can't use for example esp to store anything. It has to be the stack pointer.