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