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

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.

I know about the target flag, but you completely dismissed my point about OpenGL calls. I'm not sure why you like to assume everything is related to GCC, no one has even bothered looking at this GL backend which is running on hardware that is probably completely different than what the designers of the backend were expecting (Windows 95/98 with OpenGL I think). There's no reason to assume this code which was (by my own admission) hacked together to run on IRIX would have good performance over the compiler itself being able to optimize it.

It would be one thing if graphics specific optimizations were applied that way, in that case I'm genuinely curious how that works, but aren't those things already compiled and linked into libGL on the CPU side? It's not like there are shader compilers for SGI hardware either so, I'm not really sure how that would factor in.

[Raion]

I know about the target flag, but you completely dismissed my point about OpenGL calls. I'm not sure why you like to assume everything is related to GCC, no one has even bothered looking at this GL backend which is running on hardware that is probably completely different than what the designers of the backend were expecting (Windows 95/98 with OpenGL I think). There's no reason to assume this code which was (by my own admission) hacked together to run on IRIX would have good performance over the compiler itself being able to optimize it.

It would be one thing if graphics specific optimizations were applied that way, in that case I'm genuinely curious how that works, but aren't those things already compiled and linked into libGL on the CPU side? It's not like there are shader compilers for SGI hardware either so, I'm not really sure how that would factor in.

I did NOT dismiss your point. I am not very skilled with OpenGL, but I did write:

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

So the issue is still open. I only spoke on things I understood and have some level of authority on. One thing to note, these systems do not have SIMD - instead their graphics cards were designed to perform some additional operations such as matrix operations. Even the IMPACT series has these. Either way, I'm not certain what the platform= flag does. The proc flag does make a considerable difference for MIPSPro compilation. The theory I would have, if the platform flag has any operations for that, is that it can offload those calls to the graphics hardware through machine code for that graphics ASIC. However, that's just a guess.

Some other notes, based on my understandings of SDL:

SDL knows, generally, what IRIX can and cannot do, so if OpenGL calls are being used from SDL then it should be able to identify if your hardware is unable to support OpenGL calls.

However, you used SDL 1.2, which AFAIK doesn't have 3D OpenGL support, while SDL 2 does. The SDL2 port Axatax did has an SGI-native dmedia backend, and supports all of the OpenGL stuff that is supported for the VPro, O2 UMA system etc. That's why I was suggesting you try that.

[partitionpenguin]

I know about the target flag, but you completely dismissed my point about OpenGL calls. I'm not sure why you like to assume everything is related to GCC, no one has even bothered looking at this GL backend which is running on hardware that is probably completely different than what the designers of the backend were expecting (Windows 95/98 with OpenGL I think). There's no reason to assume this code which was (by my own admission) hacked together to run on IRIX would have good performance over the compiler itself being able to optimize it.

It would be one thing if graphics specific optimizations were applied that way, in that case I'm genuinely curious how that works, but aren't those things already compiled and linked into libGL on the CPU side? It's not like there are shader compilers for SGI hardware either so, I'm not really sure how that would factor in.

I did NOT dismiss your point. I am not very skilled with OpenGL, but I did write:

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

So the issue is still open. I only spoke on things I understood and have some level of authority on. One thing to note, these systems do not have SIMD - instead their graphics cards were designed to perform some additional operations such as matrix operations. Even the IMPACT series has these. Either way, I'm not certain what the platform= flag does. The proc flag does make a considerable difference for MIPSPro compilation. The theory I would have, if the platform flag has any operations for that, is that it can offload those calls to the graphics hardware through machine code for that graphics ASIC. However, that's just a guess.

Some other notes, based on my understandings of SDL:

SDL knows, generally, what IRIX can and cannot do, so if OpenGL calls are being used from SDL then it should be able to identify if your hardware is unable to support OpenGL calls.

However, you used SDL 1.2, which AFAIK doesn't have 3D OpenGL support, while SDL 2 does. The SDL2 port Axatax did has an SGI-native dmedia backend, and supports all of the OpenGL stuff that is supported for the VPro, O2 UMA system etc. That's why I was suggesting you try that.

My bad, I see that you did acknowledge the point - sorry I was very tired yesterday lmao. I still think the issue lies in the code but I'll try SDL2 as well, assuming it links against an RSE environment. 

I also wasn't aware of SGI GPUs having programmable microcode, machine code, or any programmable pipeline, which is why it seemed odd to me.

[Raion]

I don't think they have microcode, but I know they can perform those operations. I don't remember who said it, but it was discussed at one point on nekochan.

Gitea has SDL2 but it will probably need to be adapted to RSE, it will not build out of the box for that environment. I am not developing for RSE, and neither is anyone who is exclusively here on Irixnet. You should probably ask them to add SDL1 and 2 to their packages.

[soviet]

panther_ thanks for the binary and amazing work there ! .
Worked on the first shot, tested it on an octane (dual R10000 250mhz 1.6g ram MXI video)
And runs smoothly, cpu usage is quite low also. The sound works fine theres some stuttering during the starting intro but later works fine:
Here is a video running:
https://youtu.be/vDwxXnHmuqc

They are some wired glitches like the trees are split in half and wooden dicks are on the top of each tree.
The shadows look wrong and mario face during gameplay is a little glitchy.
console output:




Here is running on an O2 (300mhz R500 1GB ram 1024x768 mode)
https://youtu.be/vJ-9ALbw7AU

[jpstewart]

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.

Do you have any info about how -TARG:proc=r10000 in MIPSPro differs from GCC's -march=r10000 option?

[Raion]

I only have MIPSPro documentation, but I wasn't aware of GCC's -march options for MIPS since I've barely used GCC by comparison. The mipspro flags are documented in places like: http://fy.chalmers.se/UNICC/perf_tuning/...roc=r10000

I also have some info on the mipspro wiki article: https://wiki.irixnet.org/MIPSPro

Considering how esoteric GCC documentation is by comparison. I'd have to really have someone whose more familiar with GCC and can actually sit and find all of the flag equivalents that MIPSPro has to GCC, then maybe more scientific tests can be performed regarding codegen for the two. But I don't really have the motivation to sit and dig through a compiler's documentation that much for something I'm not that passionate about. We have a long history of showing that MIPSPro can in many circumstances produce better results. I think that anything beyond that is semantical.

[partitionpenguin]

panther_ thanks for the binary and amazing work there ! .
Worked on the first shot, tested it on an octane (dual R10000 250mhz 1.6g ram MXI video)
And runs smoothly, cpu usage is quite low also. The sound works fine theres some stuttering during the starting intro but later works fine:
Here is a video running:
https://youtu.be/vDwxXnHmuqc

They are some wired glitches like the trees are split in half and wooden dicks are on the top of each tree.
The shadows look wrong and mario face during gameplay is a little glitchy.
console output:




Here is running on an O2 (300mhz R500 1GB ram 1024x768 mode)
https://youtu.be/vJ-9ALbw7AU

Nice, yeah I think the outdoor area is generally pretty playable but I noticed things start to lag more when you load a level like Whomp's. Glad to see you got it working though

[soviet]

@partitionpenguin have you try compiling having audio disabled ?.

on the dos version the config have an option DISABLE_AUDIO=1 doing this increase the speed of the game massively at least on dos.

[soviet]

Hi someone knows if this "project' have any new fixes or releases ?.