[Raion]

I've used the GNU ld that danielhams worked on, it does work for compiling GCC at least and the few test programs I did with it. The initial ones they were working with had weird bugs, but the latest patches he pushed out seem to have ironed out the bugs.

[jpstewart]

Good to know. Thanks for the info, Raion!

[Raion]

So I read over what Daniel Hams wrote on the other copy of the thread and it does moreorless confirm the issue lies with SGUG-RSE. I'm not sure why they're adding X11 client libs (presumably for an app that requires them? I don't see any documentation as to why) but that is potentially the cause breaking them.

PartitionPenguin, if you /really/ want to try this and use Nekoware only, I'll build you GCC5 for Nekoware. Let me know. It'll take me a bit, but I know I can get a decent GCC running moreorless.

[soviet]

It could be so awesome if you can get sm64 running on IRIX !.
Could be amazing to see the game running on an O2.
They have done even a DOS port now, have been playing it on a 180 K6-2 having a basic pci voodoo 3 and works in 1024x768 smoothly.

[Raion]

You'd think it'd run great; but no. Unfortunately I suspect the code they're using for wrapping all of the GL calls is not optimized for IRIX, and the fact that it isn't fully optimized for IRIX in general leaves the perfomance with a lot to be desired. A native OpenGL MIPSPro build would be nice.

[chulofiasco]

they've made some progress -- it's running on irix.  --> CHECK IT OUT

[soviet]

Cool i never heard about that other SGI forum.
Anyway i see they got the game working that is amazing, hope the kind smooth out the issues.
So i can get my hands on the binary's  and test it

[soviet]

partitionpenguin Do you happen to already have some binary so i can try your mario 64 build

[partitionpenguin]

Sure, here is a tarball of the source, it includes the binary in it, but i've also attached it alone to the post. I'm not sure if it will work on its own really, but I guess it's worth a shot.

https://drive.google.com/file/d/1mnCq0fT...sp=sharing

Raion, I don't think it's so much of an IRIX or MIPSPro optimization issue, I'd trust that GCC is doing decent optimization actually, but I bet it's more that the code is not optimized for the graphics hardware. Perhaps it uses certain GL calls that are slower on SGI hardware but negligible on other systems, something like that - there's also graphical glitches with it that can be resolved. Drmadison said he was looking at it but he hasn't responded to the forum post yet. I'd like to keep it on RSE ideally for the moment because that would mean it could get packaged as an RPM and I think that would be a nice solution. But maybe MipsPro is worth a shot too.

[Raion]

Sure, here is a tarball of the source, it includes the binary in it, but i've also attached it alone to the post. I'm not sure if it will work on its own really, but I guess it's worth a shot.

https://drive.google.com/file/d/1mnCq0fT...sp=sharing

Raion, I don't think it's so much of an IRIX or MIPSPro optimization issue, I'd trust that GCC is doing decent optimization actually, but I bet it's more that the code is not optimized for the graphics hardware. Perhaps it uses certain GL calls that are slower on SGI hardware but negligible on other systems, something like that - there's also graphical glitches with it that can be resolved. Drmadison said he was looking at it but he hasn't responded to the forum post yet. I'd like to keep it on RSE ideally for the moment because that would mean it could get packaged as an RPM and I think that would be a nice solution. But maybe MipsPro is worth a shot too.

I'm going to avoid turning this into a debate over optimization, but let me explain my methods:


MIPSPro has features GCC does not. In particular, the -TARG function. You can specify a processor or platform (IP board) to specifically compile against. I'm not 100% clear on platform, and that appears to have a far less prominent effect, but basically:

By default, even if you crank -O3, MIPSPro omits some processor-specific opts. So if I specify TARG:proc=r10000 it will enable R10000 specific features 

GCC does NOT have this flag. So you're basically betting generic optimizations against CPU-specific opts. Someone with more experience can tell me if platform= would enable graphics-specific opts. 

Another benefit - MIPSPro's optimizer does have some bugs, but there's a workaround (all optimizers can sometimes break things, that's why they tell you to avoid -Ofast because that breaks float) the -OPT flag can set a procedure size, above which it will leave alone. -OPT:limit=n is the function there. There's other things too. GCC probably has something like this, but GCC documentation is a rat's nest. 

I'm not sitting on my ass being a MIPSPro zealot, despite how people idiotically tend to portray me. I'm simply pointing out facts. If you think a few nonscientific metrics, from me, or from someone else, can conclusively prove it, that's untrue. These are all personal attestations. 

As for the code not being optimized for the graphics hardware, that's still entirely possible. As others pointed out, that star flipping issue is an example of GL calls that don't exist on IRIX. 

But, for games in particular, and Gijoe77 can attest:

He ported dgen-sdl a while ago. The MIPSPro C/C++ build did FAR better than the one with GCC 4.7. And in my completely unscientific tests, GCC 4.7 and GCC 8.2 on IRIX for C code does virtually identical for things like pixz, pigz, bash etc. 

Other code, it just depends. Some things GCC does about the same or a little better, but games is not one of them. I have a visualboyadvance build around here that did better, as did gnuboy or cingb, I forget which.