[khral]

Few days ago, I have some free times to do stuff, so I decided to try compile Blender 2.49b with sgug-rse.

This would be good starting point in case anyone want to port newer Blender to IRIX, like Blender 2.76b
(the last version to support OpenGL 1.x) or Blender 2.79b by patch it to use OpenGL 1.x.

It took me sometimes with a lots of trial and errors as there aren't any documentations about compiling Blender on IRIX anywhere I have search.

The result is it compile and link without error and the binary works too! \OwO/

Here is the step I took to compile Blender 2.49b with sgug-rse, the compile step I based from blender249 AUR

I assume you know a bit on how to compile stuff from source.
Sorry for the picture isn't screen capture, as it a trouble to transfer screenshot with secondary SCSI HDD to/from my PC.
I didn't get my Tezro on network yet.

Note that I didn't include OpenEXR support due to v2.5.6 give compile error with sgug-rse.
There seems to be OpenEXR package in wip branch of sgug-rse tho but I have no time to look into the wip branch yet. :<

Install sgug-rse
----------------

Install sgug-rse-0.0.7beta on your SGI using given instructions from https://github.com/sgidevnet/sgug-rse

on the step 8 "install packages", choose "Install everything" step or just install what you need.

After finished install, remove xorg-x11-proto-devel package to prevent errors during linking.

Code:

sudo tdnf remove xorg-x11-proto-devel

To use sgug-rse, run this command in the terminal

Code:

/usr/sgug/bin/sgugshell

Compile and install libSDL
--------------------------

I'm using SDL 1.2.15 from https://github.com/libsdl-org/SDL-1.2/

Code:

cd SDL-1.2.15
./autogen.sh
./configure
make && make install

Compile and install OpenAL
--------------------------

I'm using source code from Nekoware since it was already avaliable on my Tezro

Code:

cd openal-1.1/linux
./autogen.sh
./configure
make && make install

Prepairing Blender 2.49b source code
---------------------

Download and extract Blender 2.49b source code from https://download.blender.org/source/blen...49b.tar.gz

Download blender249py27_gcc9_all.patch from https://aur.archlinux.org/cgit/aur.git/t...blender249

and put the patch into extracted blender-2.49b directory.

Download blender-2.49b-15.fc15.src.rpm from https://archives.fedoraproject.org/pub/a...15.src.rpm

and extract the rpm file using this command

Code:

bsdtar -xvf blender-2.49b-15.fc15.src.rpm

put blender-2.49b-uid.patch and blender-2.49b-cve.patch into extracted blender-2.49b directory.

Code:

cd blender-2.49b

# patch blender 2.49b for newer gcc and python
dos2unix extern/bullet2/src/BulletSoftBody/btSoftBodyInternals.h
dos2unix source/gameengine/Ketsji/KX_PolygonMaterial.cpp
patch -Np1 -i blender249py27_gcc9_all.patch
patch -Np1 -i blender-2.49b-uid.patch
patch -Np1 -i blender-2.49b-cve.patch

Edit blender-2.49b/intern/elbeem/intern/utilities.cpp at line 51, change

Code:

return (getElbeemState>=0);

to

Code:

return (getElbeemState()>=0);

This will finish preparing the source code, or alternately, use the already patched code from my github repo https://github.com/kytulendu/blender-2.49b

Compile Blender 2.49b
---------------------

Code:

cd blender-2.49b

mkdir build && cd build

# change to -march=mips3 or -march=mips4 to match your machine
cmake \
    -DCMAKE_EXE_LINKER_FLAGS:STRING="-lmoviefile -lmovieplay -ldmedia -lGL -lGLcore -lX11 -ldl -lpthread -Wl,--allow-shlib-undefined" \
    -DCMAKE_CXX_FLAGS:STRING="-O2 -march=mips4 -fcommon -fpermissive" \
    -DCMAKE_C_FLAGS:STRING="-O2 -march=mips4 -fcommon" \
    -DPYTHON_EXECUTABLE:PATH=/usr/sgug/bin/python2 \
    -DPYTHON_LIBRARY:PATH=/usr/sgug/lib32/libpython2.7.so \
    -DPYTHON_INCLUDE_DIR:PATH=/usr/sgug/include/python2.7 \
    -DFREETYPE_INC:PATH=/usr/sgug/include/freetype2 \
    -DFREETYPE_LIB:PATH=/usr/sgug/lib32/libfreetype.so.6 \
    -DOpenGL_GL_PREFERENCE:STRING="LEGACY" \
    -DWITH_OPENMP:BOOL=ON \
    -DWITH_OPENJPEG:BOOL=ON \
    -DWITH_OPENEXR:BOOL=OFF \
    -DWITH_PLAYER:BOOL=ON \
    ../

# use "make -j 2" to use 2 cpus to compile blender
# use "ninja" if you add "-GNinja" flag to cmake
make

no errors yay!!

   

Code:

# build plugins
cp -r ../release/plugins ./bin
mkdir -p ./bin/plugins/include
cp ../source/blender/blenpluginapi/*.h ./bin/plugins/include
chmod +x ./bin/plugins/bmake

# edit ./bin/plugins/bmake
# copy CC, CFLAGS, LD, LDFLAGS from Linux portion to IRIX64
make -C ./bin/plugins

And run blender.

Code:

# run blender
cd bin
./blender

Success!!!!

   

Benchmark
Using test.blend from http://www.sgidepot.co.uk/blender.html on SGI Tezro R16000 800Mhz X4 4MB L2 Cache, 3GB RAM, IRIX 6.5.22

1 render threads
- official Blender 2.49a 06:22.55
- self build Blender 2.49b (-O2 -march=mips3) 06:34.49
- self build Blender 2.49b (-O2 -march=mips4) 06:21.90

4 render threads
- official Blender 2.49a 01:54.97
- self build Blender 2.49b (-O2 -march=mips3) 01:58.50
- self build Blender 2.49b (-O2 -march=mips4) 01:53.03

8 render threads
- official Blender 2.49a 01:56.86
- self build Blender 2.49b (-O2 -march=mips3) 01:51.57
- self build Blender 2.49b (-O2 -march=mips4) 01:48.75

[Raion]

Here, I moved this to the RSE subforum since its guide is very specific to it.

FYI with -march=r16000 -- the r12000 and up just really has process shrinks and clock boosts, so I don't know if that actually does anything specific on GCC beyond that.

I doubt that getting mesa working on IRIX is worthwhile. I know that a lot of SGUG is going for experimental "shoot for the moon" but anything beyond the original system capabilities is really not, in my personal view, viable nor practical. Can you force GTK3 or dbus or other modern stuff to run on IRIX? Yes, but why would you do that? Your system is going to be bogged down trying to run all that stuff, and even a 1GHz Tezro is far slower than an HP C8000 on many benchmarks (we're held back by no SIMD, and primitive issues with the MIPS ISA).

Rather, if someone wants to get later blenders on IRIX, backporting OpenGL 1.x to later versions is the better method.

[stormy]

Raion I do agree with some of your outlook but sometimes it isn't as bad as you think. For instance GTK3 actually runs quite quickly (I don't honestly notice much difference between GTK1/3 apps on my Octane) I mean, if it runs at a reasonable speed I think it is acceptable, especially if it allows porting of more modern apps. Also - even if the outcome is slow, there isn't any detriment to the community, nobody *has* to install GTK3 for instance.

I think you are definitely 100% right about back-porting though, that definitely is the very best idea.

[Raion]

It runs fast? Call me a doubter. Maybe simple applications run but the problem is everything beyond GTK1 is computationally expensive because of text shaping. GTK1 little more than a wrapper around things like Xlib and was designed as a free version of motif. GTK2 and beyond uses its own client-side font rendering. Because there's no SIMD on our systems, and because there's no optimized OpenGL routines for this, what's basically happening is GTK2 is making calls to Cairo and XRender to calculate font rendering on the CPU. Hence it may run pretty decently on a octane or something that has decent amount of computing power but as soon as you start going down into the lower end systems that don't have as much to spare it's going to be slower and our systems are always going to be slower running these toolkits than systems which have better support.

I would be far less pessimistic when it comes to this but for the fact that it's going to it adversely impact us the longer that we ignore this. Without distracting from the original topic here I wanted to basically make the point that my personal opinion is going to remain that we should avoid working on things that are lost causes. It's good that you are happy with your setup and everything. I just think that trying to Port Mesa and all this stuff is a little bit of a weird direction to take things into when we should be focusing on first and foremost getting ourselves things that aren't creature comforts that are only going to benefit the people with the fastest computers.

[khral]

@Raion
I have checked GCC code (from https://github.com/gcc-mirror/gcc/blob/m...ips/mips.h at #define MIPS_ISA_LEVEL_SPEC). Like you have said, it seems the flag -march=r8000, -march=rm7000, -march=r10000, -march=r12000, -march=r14000 and -march=r16000 is equal to -mips4 or -march=mips4 flag, so it doesn't do anything extra. I'll update the tutorial according to that.

Also, no SIMD would greathly impact the performance of mesa's OpenGL software rasterizer, even with faster PC (Core2 Duo) Blender's viewport is in single digit on minimal scene. With slower CPU and no SIMD and no llvm support, the viewport fps would be below single digit fps and make it useless for actual work... It better to port Blender 2.79b viewport to OpenGL 1.x with SGI's extensions it seems.
But the Blender 2.79b port is a *maybe* and in far future, with my not much free times and many projects to do.

[Raion]

I support such a thing. Wouldn't mind throwing a few hundred to someone looking to get us an optimized, updated Blender port.