SGI: Development

I might have posted on this board before about the CrystalSpace (CS) engine and also my Skyscraper simulator project, and now I'm working on getting the engine working on both IRIX and Solaris/SPARC. I'm not a member of the CrystalSpace team, but I submitted a few patches to them back in early 2007 to fix some build issues it was having on both operating systems. Currently I'm able to build CS 1.2 on Solaris, but am having strange issues with symbols missing in the static libraries (and so the plugin SO's don't link properly). CS 1.2 won't build at all on IRIX with any compiler, since it has a new threading model that has atomic operations support for only x86, PPC and SPARC - if someone here would know how to write a support file for MIPS, then it would build (seems to be fairly easy if you know a few raw cpu arch details, and the support files are small). CS 1.0.2 builds with GCC only, but I'm still trying to see if it runs (when I get home I'll test it, but currently it seems to just be segfaulting). It goes completely insane with MIPSpro.

The official site for it is http://www.crystalspace3d.org
My simulator app really only depends on CS and wxWidgets (my sim is here: http://www.skyscrapersim.com ).

So to build and tinker with it on IRIX, here's my current steps (done on 6.5.22 with Neko GCC 3.4):
1. Grab the tar.bz2 of CS 1.0.2 and extract: http://internap.dl.sourceforge.net/sour ... .2.tar.bz2
2. Install any dependencies from Nekoware (check out the configure script for info)
3. setenv CFLAGS -std=gnu99 (for tcsh) - this is so the configure script can currectly parse c99-only IRIX headers
4. edit the configure file and change /bin/sh to /usr/nekoware/bin/bash (or any other shell that makes the configure script actually work properly)
5. ./configure --enable-cpu-specific-optimizations=max --without-python --without-java (python support has always been problematic for me when building - also the cpu optimization flag is optional)
6. remove lines that contain gnu99 from Jamconfig (CS is written in C++, and so these aren't needed)
7. comment out line 85 of plugins/video/canvas/openglx/glx2d.cpp (due to "setenv" not being defined in any headers; on Linux it's in stdlib.h)
8. add -lpthread into any of Jamconfig's COMPILER.LFLAGS options (I changed COMPILER.LFLAGS += "-lnsl" to COMPILER.LFLAGS += "-lnsl -lpthread"; you could just add a line too)
9. gmake

to only build portions of the system, use commands like (these seem to work better on 1.2):
gmake libs (just build core static libraries)
gmake plugins (build engine and other plugins - this takes the longest since the majority of CS is made up of plugins)
gmake apps (build demo apps - requires libs to build but won't run without plugins)

after it's done you can run "gmake install", but what I normally do is just move and rename CS's entire directory as /usr/local/CS
You'll need to make sure the CRYSTAL environment variable points to wherever CS is, in order to run and build apps outside of the CS directory.


Here's a few pics of my simulator, so you can get a good idea of what I'm trying to get running on IRIX (the app was also greatly inspired by SGI's VR philosophy) - basically my app is a first-person virtual building simulator, which simulates skyscrapers as if you're actually inside them (working elevators, stairs, etc) with buildings being written in a custom scripting language (I might eventually switch to Lua for them):





The Glass Tower building from the movie The Towering Inferno:


Upper part of the Sears Tower:


In-development elevators:






In-development stairs:


The Elevator Editor component on Windows:


Enjoy

-eventhorizon

One more detail I forgot, about the MIPSpro issue:

CS 1.2 doesn't work due to it missing support for MIPS in the new threading model (include/csutil/threading - they have just x86, PPC and SPARC)
You'll get this error: "include/csutil/threading/atomicops.h: No atomic operations defined for your platform"

So really a definition entry needs to be made in the atomicops.h file, and a atomicops_mips.h file needs to be created.

-eventhorizon

I finally got the CS engine to run, except the render window flickers exactly like how it did on Solaris (with no visible 3D rendering). I rebuilt the app in debug mode, but the trick to getting it to actually run without segfaulting is to turn off the built-in ptmalloc memory allocator:

./configure --enable-debug --disable-ptmalloc --without-python --without-java

So now it's actually running - I'm assuming that the flicker problem is related to the GL drivers.

Screenshots (in these I'm running the demo program "simple1"):







-eventhorizon

I can implement atomic operations in assembly if absolutely needed, but it really is just easier to use MIPSpro intrinsics. I can show you examples of both if you need.

Patrick Baggett
Figgle Software, Inc.

That would be great - I know that MIPSpro would be far easier, but after tinkering around with MIPSpro 7.4.4 and the CS source, it looks like it would be a huge amount of work to actually get CS building at all with it (I could be wrong though). I also don't know enough about how the CS engine works to easily fix things here and there.

But as for atomic ops, here's the main sparc class from the file include/csutil/threading/atomicops_sparc.h:



-eventhorizon

I just noticed that the system appears to be running with a 15-bit color depth, and CS mainly needs at least 24-bit. I changed the X color depth on my Linux laptop to 15, and it had a similar flickering, but still rendered some stuff (except extremely slowly). I tried changing the IRIX depth according to the guide at http://software.majix.org/irix/desktop-depth.shtml , but it didn't seem to work (CS still reports a 15-bit depth), even though xdpyinfo shows that the system now supports 24-bit. CS must be choosing a wrong color map or something

Also the problems could be related to missing GL extensions that the engine needs; there a file called data/config/gldrivers.xml which contains overrides for certain graphics cards. I'm attaching the runtime messages from using the "-verbose" flag in the file cs_irix.txt.

-eventhorizon

Ok, here is a quick hack for you. I haven't compiled this under GCC, but it looks right. Try it out and see if it works.

It uses IRIX's <mutex.h> library, but I couldn't find a compare and swap function, so I had to resort to inline assembly (bleh). It uses GCC's inline asm style, so may not work for MIPSpro.

Anyways, try it out, tell me how it works.

Patrick Baggett
Figgle Software, Inc.

Thanks - I'll try doing a build with it later today. Now I just need to figure out how to fix the GL issues (seems to be a bug in how CS detects renderer info; it reports that the system's running at 15bpp even though it's running at 32, among other problems) - fixing that would theoretically make it all work.

-eventhorizon

Man, if I had a week (or two) and CrystalSpace ported, I'd try to port PlanesShift or something. An MMORPG on IRIX.

Actually, I want to be the first to create an MMORPG for IRIX.

Patrick Baggett
Figgle Software, Inc.

I'm trying it with GCC, and there's some type conversion problems:

./include/csutil/threading/atomicops_mips.h:21: error: invalid conversion from `int32*' to `__uint32_t*'
./include/csutil/threading/atomicops_mips.h:32: error: invalid conversion from `volatile long unsigned int*' to `long unsigned int*'
(those 2 types defined in your file are different than the IRIX mutex.h file)

I also added the namespace info to the file, for integration into the CS atomicops system (and everything seems fine except for those 2 errors). I'm tempted to just cast the outputs of those to the compatible formats, but wanted to report it first

-eventhorizon

The simple casts are fine really.
Glad it compiles!

Patrick Baggett
Figgle Software, Inc.

I tried it out last night, and the engine ran (obviously with the same glx issues as before - mainly the flickering render window) - so it seems like you're code's working - I'm going to submit it to the CS developers in a combined patch:

http://ryan.tliquest.net/cs_patches/atomic_mips.diff

Also here's the output from running the simple1 test app in verbose mode:
http://ryan.tliquest.net/cs_patches/cs_1.2_irix_output.txt

I also have all other stuff (including my previous patches that they merged into the CS trunk, screenshots, etc) on my site:
http://ryan.tliquest.net/cs_patches/

-eventhorizon

Submitted:
http://trac.crystalspace3d.org/trac/CS/ticket/475

-eventhorizon

I notice the SPARC version has memory barriers. I am not familar with how these atomic ops are used within the rest of the codebase, but it suggests that the MIPS versions should also do memory ordering if you want to make sure it runs correctly on all MIPS implementations regardless of memory ordering model in use. The MIPS equivalent to 'membar' is 'sync'. Perhaps the intrinsics already do this?

I read that LL/SC pair performed an implicit SYNC, but reading the R10000 processor manual states quite clearly:

"Load Linked and Store Conditional instructions (LL, LLD, SC, and SCD) do not implicitly perform SYNC operations in the R10000 processor."

So I guess it is need for multiprocessor systems with R10000 and variants thereof (R12000, R14000, R16000). Don't know about R8000 or R5000. R5000 is probably the same, R8000 is so weird, who knows what it does...

Patrick Baggett
Figgle Software, Inc.