What I've been up to

[onre]

@praetor sure! Just msg me on Discord or ask here - there's also a 2.59.0 on sgug-rse-wip that you can use. I'll update that to include the volume manager patch and add another one for 2.62.4 sometime this week.

Also, yesterday I ported some stuff that is known to divide opinions. Personally, I just want to get new stuff running so I really don't care about the semi-religious debate. Thus my Octane now has a messagebus user and a start-up script that starts... dbus

Why? Well of course because GTK+3. To get this one going, I had to compile some newer X11 libraries and chose Xorg's latest as my basis. I had some doubts whether things would work nicely against the Xsgi X server on the Octane, but turned out everything works fine. Stuff that's not supported like Xrender falls back as gracefully as it can - the transparency is just not rendered. If someone felt particularly adventurous, it would probably be possible to write a shim that'd implement the Xrender client library API and do the actual drawing with OpenGL.

Some other GTK+3 dependencies were... interesting. libepoxy did not find Python so it decided to try running Python scripts with Bourne shell. Because of that, I thought for a moment that it requires ImageMagick as it tried to run import

GTK+3 build consisted mostly of waiting. Also, there's a bug that made it dump core on startup. Apparently IRIX libc bsearch() can give a null pointer to the comparison function under certain circumstances. For now I just #if 0'd out the cache lookup to get it going. Fixing this is trivial, I'll do it today.

If you're worried about gr_osview CPU display, it's all maxed out because the Octane is linking the library while I run the demo.

 

[praetor]

So far I've been impressed with SGUG's toolchain build. It's managed to compile everything I've thrown at it. I'll look for the GTK build and build that. Then I can get started on netsurf.

 

[onre]

Fun to see there's interest in these weird projects!

GTK2 and GTK3 are both rather trivial builds once you have GLib. GTK3 has a ton of dependencies but it should be a pretty straightforward build really - more of a test of patience than skill. I built the Xorg stuff in a separate prefix that is not searched by default so I can use PKG_CONFIG_PATH when I'm building something that needs the later client libraries. One odd thing is this; there's no Xregion in SGI's X implementation. It's a small utility library that has been in X source tree since late '80s but for some reason not found in 6.5.30's X at least.

You'll need the small glib patch I mentioned above to make file choosers work. I'll try to get it online today. You can just comment out calls to _resolve_dev_root() in gio/gunixmounts.c to make it work.

Also, Python 3 is build requirement for both GTKs. You can either use the old tardist from ports.sgi.sh or build yourself a shiny new 3.8.1 from sgug-rse-wip. It won't pass all the tests but works enough to build the GTKs and run meson the build tool.

 

[onre]

GitHub - sgidevnet/ninja at irix

a small build system with a focus on speed. Contribute to sgidevnet/ninja development by creating an account on GitHub.

github.com

Here, have a Ninja. Builds on the rse with Python 3. Linking it against DICL is also a possibility - then we could use the latest subprocess-posix.cc.

 

[onre]

Here's a patch for glib 2.62.4. Should be easy enough to modify the volume manager part for older versions, too.

 

[onre]

One more - a multi-problematic patch for meson 0.53.1. Adjust the obvious bit to suit your machine if it's not an Octane.

TODO for this guy includes the following: detect all ip* archs as mipseb, detect which format we're building and set library dir accordingly. Amazing how much dubiosity one can put in less than ten lines of code.

 

[onre]

Last screenshot was missing the SVG vector icons as @HAL pointed out, fixed thanks to librsvg.

Other than that, i've been busy rebuilding things against the X.org client libs. I've also given a thought or two to writing a Jack backend for IRIX as that's in line with my original idea of what I wanted to run with my newly-acquired Octane - Ardour. i've got almost all of the dependencies in place now and at this rate will be soon seeing how slow it'll be on my Octane.

 

[onre]

So, in the end the GOT may have been a red herring, but stuff was learned which is always nice. Stay tuned.

So - now we've got another piece of software breaking in similar manner. This time it's Ardour. I did some testing tonight and came up with the following thoughts.

1. binutils multi-GOT mode produces weird GOTs, apparently with extraneous pieces of stuff in them if the GOT acts as both PLT and GOT, as is the case when both data and functions are referred through it. Need to confirm that. Interestingly enough the multi-GOT is just fine is it's only used as a PLT. This has been confirmed with generated code. However, these seem to work just fine even though they look ugly when inspected with IRIX tools. I did a test where I made sure rld had to move the shared library and all the functions returned expected values even after that, meaning that the relocations were correctly calculated for all 20 000 functions and variables.
2. Does the init code disassembly from the previous page actually show where things go wrong? We calculate a value in $sp just before the indexed jump, amirite? D'oh!
3. ???
4. I need more memory for the Octane.

I'll keep you posted once I get farther with this.

 

[onre]

COVID-19 has been doing its best to drown me in work.

However, I've slowly been working towards something I've wanted to do for a long time. As a bit of background, some SGI hobbyists make really wild claims about the MIPSpro compiler to the point where it's the ultimate deus ex machina, producing results of absolutely stellar quality in all circumstances. When I began messing around with SGIs in 2018, I compiled a bunch of then-current FOSS with MIPSpro. My practical experience with the compiler was very different from all the hype I had read about it - I had to back down on optimization flags to make software run properly because of optimizer bugs, write lengthy patches because it actually segfaulted on C99 static struct initializers etc.

So, in last couple of weeks I've been running benchmarks and doing tests to get some actual data instead of fantasies. So far it seems like almost all of these claims are simply unfounded. I'll write a lengthy report of my findings, complete with documentation of how I ran the tests so that anyone is free to repeat them and get the same results.

 

[Elf]

I know what you mean on the COVID thing, although it has been the opposite for me

I am sure you have noticed but I have not really been around the SGI world for the past two months...

Work-work has continued, but my days are jam packed with various things, ranging from our upcoming birth to preparing for the pandemic and the possibility of economic collapse. We have been trying to push our food inventory out to a year, vacuum packing and dehydrating, Sarah has been learning barbering to be able to cut my hair, I have been trying to source gas mask filters and other supplies, learning to fish, and so on. I need to get around to constructing garden boxes and planting soon too. Living rurally I felt we were always more self-sufficient than average, but there is still a big gap between that and actually being able to survive something like a Great Depression or the collapse in Argentina. With all that going on, the past two months have felt like half a year or more!

Anyways, I am curious to see what you come up with for GCC and MIPSpro! Without having to live with it like you guys have on the active porting team, I kind of understand the MIPSpro attraction. I did always sort of favor the non-GCC compilers: Watcom C and Borland Turbo C under DOS (vs. DJGPP), the Renesas C/C++ compiler (vs. RL78 GCC), the Texas Instruments MSP430 compiler (vs. GCC for MSP430) and so on. Particularly on small microcontroller platforms the trend seems to be GCC produces larger, somewhat slower code, and there is some documentation around that with it primarily being the reason the vendors charge so much for their own compilers, but that's counting cycles and kilobytes. But I was always creating code from scratch. I hear the active IRIX porters have run into a lot of code that is frustrating to compile if not using GCC.

 

[onre]

I broke my collarbone into four pieces in early May and haven't given this much thought. However, here are some results for now. I might get around to running more benchmarks in the future, if I feel like it. For me, this proves the point of "adequate performance" well enough.

TEST SETUP

All tests were ran on Ciao's Onyx 4. The current setup has eight CPUs,
of which four are 800 MHz and four are 700 MHz units. The runon
command was used to make sure all benchmarks are run on the same
CPU to avoid the obvious problem.

All tests were also built for both mips3 and mips4 to see if there is
a difference. The flag used for this for gcc was -march=mips[34] and
for MIPSpro respectively -mips[34].

The MIPSpro version used is 7.4.4m with all patches, the gcc used is
the 9.2.0 from sgug-rse 0.0.4.

All execution times were measured with /usr/bin/time -f%U <command>.

Results are seconds the process spent in userspace, unless stated
otherwise.

INTEGER PERFORMANCE

gmpbench

The GMPbench test suite uses the gmp library to do a bunch of integer
operations. The version of gmp library used is 6.1.2 and gmpbench is
0.2. The test suite was run ten times with each configuration to make
sure the results are consistent and repeatable.

MIPSpro could not produce a working gmp library with -Ofast so
optimization needed to be reduced to -O3 level.

The result of this benchmark is the GMPbench score instead of seconds.

Here's a link to the gcc results:

Index of /irix-benchmarks/gmpbench/gcc

MIPS3 average 279.27, min 278.32, max 279.46.


As we can see, the results are rather uniform, slowest and fastest
being less than 0.5 % apart from each other. For some reason, the
first run has the worst score.

Here are the MIPSpro results:

Index of /irix-benchmarks/gmpbench/mipspro

MIPS3 average 266.98, min 266.91, max 267.02.

These are even more uniform, within 0.04 % of each other.

We can conclude that in this particular benchmark the MIPSpro binaries
are about 4.4 % slower than those generated by gcc. MIPSpro might
perform better if we would've been able to use -Ofast, but we weren't.

FLOATING POINT PERFORMANCE

ffbench

FFBENCH: Fast Fourier Transform Benchmark

FFBENCH: Fast Fourier Transform Benchmark

www.fourmilab.ch

This is a classic floating point benchmark. To get meaningful results,
the amount of iterations was increased to 5000 and benchmark was run
50 times. Both compilers could do this one with -Ofast and the
benchmark checks results for validity - both compilers passed this
check.

gcc, mips3:

http://esp.iki.fi/irix-benchmarks/ffbench/mips3/gcc.times

Average 303.79, min 303.67, max 303.94.

mipspro, mips3:

http://esp.iki.fi/irix-benchmarks/ffbench/mips3/mipspro.times

Average 304.45, min 304.21, max 304.73.

Here the difference is very small. gcc binary is 0,2 % faster, but
there's 0,1 % deviation in run times. For all practical purposes the
result is a tie.

postcard raytracer

Deciphering the Postcard Sized PathTracer

This is a fun little programming exercise written in C++, included
mostly because it was the original catalyst for this whole
experiment. Both compilers could compile this with -Ofast, and both
binaries produce the desired image. The binary was run five times per
configuration.

Results:

Index of /irix-benchmarks/postcard-renderer

GCC mips3 average 1491.03, min 1491.03, max 1491.04.
MIPSpro mips3 average 1525.24, min 1525.23, max 1525.24.
GCC mips4 average 1416.17, min 1416.16, max 1416.18.
MIPSpro mips4 average 1466.96, min 1466.83, max 1467.12.

Here the execution times are very uniform, there is basically no
deviation. gcc binary is 2.2 % faster with mips3, 3.5 % faster with
mips4.

 

[onre]

Got another one of my Octanes working and set it up at the hacklab to have a remote access 24/7 SGI system at my disposal. However it only has 256 megabytes of RAM - need to find some cheap Octane RAM from somewhere.

I think once I have memory for that, I'll see if the third one works and if it does, I'll sell it.

 

[onre]

It's been a while, but here are some things I've gotten to run lately. RSE packages for these are underway thanks to @HAL.

The latter is over X11 forwarding on my G5 Mac.

Also my home studio has taken a huge step forward equipment-wise - I managed to find locally an Amek TAC Scorpion II. Stay tuned for a more thorough writeup on things.

 

[vvuk]

Hey, awesome work! Just found this thread as I've been contemplating poking at a Firefox port. Did you make any further progress there? And are any of your "in progress" experiment patches available somwhere?