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]

Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.

This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.

 

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

 

[onre]

I feel like taking another stab at all of this. We'll see how it goes this time.

Because of $reasons I sold the Octanes, but a year or two ago a friend of mine gave me an O2+ after losing interest. Last night I finally got around to powering it up and using it to make a backup of the contents of the hard drive of what used to be my primary SGI box. So, now I've got 60 gigabytes worth of WTF to go through and figure out what I actually want to do - if anything. We'll see.

 

[onre]

As usual, I ended up learning things. I'll document it here so I don't forget.

For some unknown-to-me reason the usual "Install system software" option did not want to cooperate. It did load /dist/sa from the boot server, but produced an exception message on the console immediately afterwards. After a couple of tries I decided to figure out how to do this by hand.

This is how you copy the miniroot manually to the swap partition and boot from there. Adjust sash and unix to match your hardware.

### erikoistietokone, "special computer", is my boot server. by default, the
### NetBSD bootpd replies to requests that match the host name of the server.
### thus, no DNS setup of any sort was needed for this to work. one might
### argue that IP addresses are shorter and easier to type than names like
### this one. naturally, people are entitled to have opinions on things.
###
### let's start sashARCS from within the standalone environment. the file
### /dist/sa is on the first disc of the 6.5.30 set, (sashARCS) specifies
### loading a file by that name from within the standalone environment.

> bootp()erikoistietokone:/dist/sa(sashARCS)   
Obtaining /dist/sa(sashARCS) from server erikoistietokone
136992+22896+3248+341792+49584d+4620+6880 entry: 0x8ffa5e50
Standalone Shell SGI Version 6.5 ARCS   Jul 20, 2006 (32 Bit)

### hello, sash. what we do now is copy the file "mr" from within the standalone
### environment to the swap partition. I had partitioned the disk like fx does
### by default, so partition 0 is root, partition 1 is swap. -b 32k adjusts the
### copy buffer size, making it complete faster.

sash: cp -b 32k bootp()erikoistietokone:/dist/sa(mr) disk(1)partition(1)
Obtaining /dist/sa(mr) from server erikoistietokone
................................................................   
................................................................   
................................................................   
................................................................   
................................................................   
................................................................   
................................................................   
................................................................   
................................................................   
..................   
19456000 (0x128e000) bytes copied

### let's do a "ls" to ensure that the miniroot is on the partition.

sash: ls disk(1)partition(1)
disk(1)partition(1):
.  ..  .cshrc  .login  .profile  bin  dev  etc  hw  lib  lib32  sbin  usr  var

### I'm not sure whether this was necessary, but did it anyway.

sash: setenv root dks0d1s1 

### okay, so, let's boot the kernel, passing it the "install" argument so it
### does not try mounting the root filesystem specified in the PROM environment.
### without the argument booting would fail as root couldn't be mounted, because
### I had not made a filesystem on the partition. however, if there were a fs on
### the device, this should boot from the device using the kernel loaded from
### the network. potentially handy, if you've got a disk installed for, say,
### an Octane, and want to boot it on an Indy. 

sash: bootp()erikoistietokone:/dist/miniroot/unix.IP32 install         
Obtaining /dist/miniroot/unix.IP32 from server erikoistietokone
4408008+493288 entry: 0x80012310
IRIX Release 6.5 IP32 Version 07202013 System V
Copyright 1987-2006 Silicon Graphics, Inc.
All Rights Reserved.

root on /hw/node/io/pci/1/scsi_ctlr/0/target/1/lun/0/disk/partition/1/block ; dumpdev on /dev/swap ; boot swap file on /dev/swap swplo 81000
WARNING: Cannot load runtime symbol table from bootp'ed kernel.
         Loadable modules will not be registered or loaded.
Creating miniroot devices, please wait...

Current system date is Wed Dec 31 16:06:49 PST 1969

Mounting file systems:

/dev/dsk/realroot: Invalid argument
No valid file system found on: /dev/dsk/realroot
This is your system disk: without it we have nothing
on which to install software.



### yayyyyyyyyyy

Make new file system on /dev/dsk/realroot [yes/no/sh/help]:

 

[onre]

Got binutils 2.44 to produce working binaries.

Added functionality equivalent to the SGUG-RSE binutils2_23.sgifixes.… · onre/binutils-gdb@4b55be5

…patch

github.com

 

[onre]

xterm-398 compiles just fine against the system X11 libraries with Mipspro.

However, the linking phase would like to use mktemp, so I had to roll my own.

/*
 * mktemp.c
 * 
 * cc -o mktemp mktemp.c
 *
 * MIT license
 *
 */
 
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
 
static const char default_template[] = "/tmp/mktemp.XXXXXX";
 
static void usage(void) {
        fprintf(stderr, "mktemp: usage: mktemp [TEMPLATE]\n");
        exit(1);
}
 
int main(int argc, char **argv) {
        struct stat *buf;
        char *path;
        int fd;
 
        if (argc > 2) 
                usage();
 
        buf = (struct stat *) malloc(sizeof(struct stat));
 
        if (!buf) {
                fprintf(stderr, "can't allocate memory\n");
                return 1;
        }
 
        if (!(path = strdup((argc == 2) ? argv[1] : default_template))) {
                fprintf(stderr, "can't allocate memory\n");
                return 1;
        }
 
        if ((fd = mkstemp(path)) == -1) {
                perror("mktemp: mkstemp");
                return 1;
        }
 
        printf("%s\n", path);
 
        close(fd);
 
        return 0;
}

 

[onre]

Felt like figuring out how fast or slow the hard disk in the O2+ is, so I pulled some diskperf parameters out of a hat.

# /usr/local/bin/scsimon 
/dev/scsi/sc0d1l0: [IBM-ESXSMAT3073NC     FNB414]       32C/89F [65C/149F]
# diskperf -W -D -c4g -n "trying it out" testfile
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : trying it out
# Test date     : Mon Apr 21 04:53:09 2025
# Test machine  : IRIX multimedia 6.5 07202013 IP32
# Test type     : XFS data subvolume
# Test path     : testfile
# Request sizes : min=4096 max=4194304
# Parameters    : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 4294967296 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
       4096    0.68   13.29    0.69    8.62    0.76    0.81
       8192    1.35   18.07    1.39   11.34    1.51    1.60
      16384    2.66   22.11    2.83   13.82    2.98    3.03
      32768    5.16   24.90    5.84   15.84    5.60    5.45
      65536    9.75   26.50   12.55   15.72   10.41    9.20
     131072   17.53   26.76   12.58   12.57   16.59   13.63
     262144   21.26   27.55   21.71   17.63   21.67   17.85
     524288   29.05   27.67   29.12   22.05   26.03   22.05
    1048576   29.24   30.14   29.48   27.85   29.66   26.07
    2097152   31.98   31.18   32.20   29.46   32.08   29.16
    4194304   33.45   31.63   33.64   30.77   33.26   30.76

I... guess that's a result? Given the age of the system it doesn't look bad at all.