The collected works of ShadeOfBlue - Page 4

This is not strictly true, you can read framebuffer contents back (and this operation is much faster than on modern hardware). Some programs took advantage of this and did e.g. compositing using the graphics hardware, then read back the result.

geo, if you're interested in ICE, disassemble the O2 OpenGL library, it contains functions for loading code into the ICE coprocessor and implementations for a few OpenGL functions using that.
The ICE coprocessor is also a MIPS core, but supports a few extra SIMD instructions. I'm not sure if the IRIX assembler can generate code for it, but the Linux project SAQ linked in his post has patches for the GNU assembler, so you can use that.

Another fun thing to check out would be some video I/O XIO cards for the Octane and Origin. The DIVO (I think) cards had two R4x00 processors on them for doing colorspace conversion and alpha compositing. If you can figure out how to load code onto them, it would be awesome

Just to clarify, I only helped port this program to IRIX

I've noticed that the instructions inside say to change "gcc" into "cc" after the Makefile is generated, but there's no need for that, you can change only one line in I makefile before you run xmkmf.

Here are my original instructions I sent to hamei in a PM (I'm including them here in case someone is browsing this via google cache or the web archive and can't access the zip file):

• change line 66 in Imakefile to "CC= c99" (Imakefile is the template used for generating the Makefile)
• comment out line 92 in mkflist.c (XFreeFontNames...)
• xmkmf (this generates the Makefile from Imakefile)
• make

It probably won't help, but you should try reseating the processor module as well (these things can get a bit loose during shipping).

If those notes include any info on how to write code for the ICE, I'd be interested in them too
I wanted to play around with ICE, but never found the time to finish disassembling the OpenGL libraries and that Photoshop plugin. It's such a shame that SGI made this interesting chip, but released no documentation on how to use it


The PVO probably doesn't have those CPUs ... On the DIVO, they are located next to the compression connector, one is on the left side, the other on the right. I tried to find a good top-down image of the DIVO, but there's nothing on google images.


Yes. I think the current drivers load the colorspace conversion code on demand, but I don't have the DIVO card to check that. It should be possible to run any signal processing code there. Those CPUs have a small amout of SDRAM as well (a few MB, IIRC).

EDIT: Yay, this is my 666th post

This is why I think it's the processor module, or rather a poor connection between the PM and the motherboard:

The SysAD bus connects the CPU to the memory controller and the L2 cache.

A poor connection between the processor module and the motherboard can also cause such errors (e.g. if the pins that carry power don't make a good contact, it can cause such problems during heavy load), so reseat the module even if it currently works. Make sure you don't touch any of the chips or the connector or the pads on the motherboard, and use an ESD wrist strap (or hold the chassis with your other hand while you touch any components inside). Don't place any components on the carpet. (Sorry if this seems obvious to you, but some people do that and it decreases the lifespan of the parts, so it's worth repeating )

If you're lucky, it is just a bad connection to the motherboard and everything will be OK once you reseat the processor module. If you're not, one of the L2 cache chips is malfunctioning and you will need a new processor module.

Another possibility is a broken fan or high ambient temperature. You can look at the output of "l1cmd env" (run this as root) during heavy load. If any of the fans report 0 RPM, you have a problem (but this is easily fixed by replacing the fan ).
Normally, the system would shut down in such cases, but due to a bad batch of DS1780 monitoring chips, this option is disabled by most users with systems that have the defective monitoring chip.


I once wrote a simple program for testing memory (it simply allocated as much RAM as it could get, then filled it with various patterns and verified the contents), but I'd have to dig it up from backups and I won't have the time to do that until next week.
The best option is probably to render a complex scene in Blender. There were some benchmark scenes posted for it here on the forum (or was that for Maya...).
Other than that, try to abuse it a bit Run something else while Blender is rendering, e.g. some demos.

Oh, you could also run the "confidence tests" (located somewhere in the toolchest menus) to test the hardware (I'm not sure if it does any memory tests, but it's worth a shot).

Thanks, geo! I haven't seen this before. It matches my findings from disassembling the O2 OpenGL libraries, though -- there are functions for accelerating glColorMatrix on ICE and such, however, this document is much nicer than looking at assembly


That would be great, but I'm currently swamped with other work, so it'll be a while until I can get back to this.


My plan was to disassemble the Photoshop plugin and figure out how it loads and executes code on the ICE coprocessor. IIRC, there is a library (libvice) which does most of that, so we'd only need to figure out the API.

Next up is generating code for the ICE. We'd need to check if the IRIX assembler has an option for outputting code for it, and if it supports the SIMD instructions used in ICE. If it doesn't, the GNU assembler with the appropriate patches from that Linux project can be used instead.

After that, it's mostly just down to writing algorithms to run on the ICE. The OpenGL libraries already contain a few optimizations in this way, so disassembling those might be educational.

From what I remember, the ICE doesn't have much RAM on it, so it would be more suited to, say, various video decompression tasks (e.g. DCT, deblocking, arithmetic decoder for the video stream, colorspace conversion, etc.). It would be a lot of work to optimize a H.264 decoder to use it, but it should be doable (don't expect 1080p H.264 decoding, though ).
Decoding JPEGs and other image formats should also be possible.

The two R4x00 CPUs on the DIVO card would be more flexible, since they're just bog standard ones (no SIMD) and have lots more RAM as well. Too bad that card costs an arm and a leg
I was looking for an image of the DIVO because I can't remember which CPUs were on it and how much RAM was on the board ... I remember the CPUs are from IDT, but don't know if they're R4600 or R4700 (they could also be R4300).
I find it amusing that you could run a proper UNIXish OS on them if they have an MMU


They could be used to speed up video decoding or something similar, but they are pretty much general purpose, so you could run anything on them. If they have an FPU, you could use them for rendering/raytracing (would be about as fast as an Indy, but hey ).



Aaaand, done

You're welcome!

I've noticed speedups on some of my numerical code as well (up to 40% against MIPSpro), but I wanted to tweak the MIPSpro optimizations (to give it a better chance) before reporting anything

It really shows that they added proper schedulers for R10k and newer CPUs (if you haven't tried it yet, add "-march=r10k" to the compile options), and the additional optimizations enabled by the PPL/CLooG libraries help a lot too (try adding "-ftree-vectorize -ftree-loop-linear -ftree-loop-im -fivopts" to test these).


I remember seeing a patch for this on Supportfolio ... If it's freely available, you can try installing it and the error should go away.

However, there might be more header changes, so it's probably better to figure out how to run the fix-includes script on an existing installation.

First run "nm" on the binary, then pick an interesting function from its output and run "dis -F function_name" on the binary. This will disassemble the chosen function.

The O2 OpenGL libraries have a few functions ending with "_vice" or "_ICE" or something similar (I forgot ), these are the ICE-optimized versions and probably the best place to start.


I was just disassembling the binaries with "dis", as mentioned above

Using a debugger would be an overkill, since none of the code is really obfuscated and nobody stripped the symbols, so it's quite readable.


Yes, the project SAQ linked before is for Linux, but some parts of it can still be used on IRIX, e.g. the patches for binutils.


That API is too high-level to be of any use in loading code onto the ICE. You should focus on libvice (the IRIX version, not the Linux one) and how that Photoshop plugin or the OpenGL libraries use it.


Sure you can have RAM in ASICs, it just takes up lots of space, so it's usually reserved for cache and buffers which need to be fast


The ICE actually uses its cache for this, yes


Yes, the ICE can do DMA to main memory, but not for the code it executes (only for the data it works on), so you need to fit the algorithm you want to run on the ICE inside its on-chip memory.

Also, doing DMA from the ICE chip competes with the main CPU (they're on the same bus), so if the algorithm does lots of memory accesses, it's usually better to run it on the main CPU.


The ICE is just a MIPS core with a SIMD unit, it doesn't know anything about image formats.

The SIMD unit has some generic instructions present in encoding/decoding JPEGs (e.g. multiply-accumulate), but those are generic and can be used in any other algorithms as well.





Inside an Octane. There would be no advantage to running an OS on those processors on the DIVO, though, I just find it interesting, that's all


I meant the CPUs on the DIVO board
The ICE can only do integer ops and SIMD on integer vectors, yes.


No, scaling things is memory-bound and memory-bound tasks are not good for running on such a coprocessor (there's too much copying involved and that slows things down).

The O2's MACE chip handles resizing video coming from the A/V card.

I'm also a fan of these drives
They can be bought quite cheaply on eBay as well (a while ago I got two used 15K.3 drives for £20 shipped).

This one is 68pin, you need an 80pin drive for an O2. There's not enough room on the O2 drive sled for a 68->80 pin adapter.

I haven't had this happen to me (*knock on wood*), although sometimes the root drive made the case resonate (really annoying sound), but that went away after I moved it to another slot

Try:

These options make some numerical code run 40% faster than MIPSpro's "-Ofast=ip35 -TARG:processor=r12000 -OPT:IEEE_arithmetic=3 -OPT:alias=typed". YMMV.

Also note that you shouldn't use "-Ofast" on gcc, since it enables "-ffast-math", which enables "-ffinite-math-only", which will break your code if it uses Inf and NaN (the Javascript interpreter probably uses them).

You can also try adding:

to the above options. Then you can try adjusting "--param l1-cache-size", "--param l1-cache-line-size", and "--param l2-cache-size" for better performance. You can also try other Graphite-based optimizations, but they're still a bit experimental and can break the compiler

If the code doesn't use C++ exceptions, add:

(if it does, the compiler will warn you).

If the code doesn't use C++ RTTI, add:

(as above, if the code uses this, the compiler will warn you).

Also, link everything statically (this also improves program startup time).

On Firefox, no, it would probably make things slower

Autoparallelization works great on certain number-crunching algorithms, but rendering webpages and executing javascript aren't something that could benefit from this.

Another thing you could try are profile-guided optimizations (in addition to the optimizations from my previous post). From experience, this combination should give the biggest speed boost, but requires a bit more complicated build environment.
Firefox should already support building with PGO, unless version 3 is too old to have that.

32 bytes for the L1 cache and 128 bytes for the L2 cache, it's the same for R10k and R5k as well, IIRC

You're welcome!

This list is the result of many years of tweaking gcc options to convince it to produce the best code it can
It gives great results on other architectures as well.

diegel, I forgot to thank you for the Firefox tardist in that other thread, so thanks!

Thanks, I didn't know about the L2 line size on the O2. GCC only seems to be interested in the data cache, so an L1 line size of 32 bytes should be good enough for all systems

This reminds me of a place which was throwing away managed 24-port ethernet switches every couple of months because a single capacitor overheated and died

It worries me that people today would rather waste $300 on a new switch than spend five minutes to desolder a capacitor and solder in a $0.15 replacement.

It's actually just a passive converter (two connectors and a PCB), so there's no reason not to use one

I have a cheap $2 one from China in my Fuel and it works great.

Thanks

I couldn't believe it at first too

I think the biggest difference was made by the R10k/R12k instruction scheduler that somebody wrote for GCC somewhere around the 4.6 release (if that person is reading this: thank you for writing it!). The generic optimizations have also advanced significantly, since GCC now has to compete with LLVM/clang

However, IRIX is marked as obsolete and support for it will be removed in GCC 4.8
If anybody has a quad Origin 300 or something similar, please make it available remotely to the developers of GCC, so that they can continue supporting IRIX -- they've obsoleted it because they don't have any SGI machines which could build gcc in a decent time frame.
There was a thread about this a while ago .

In a few years, C++11 code will be much more common. MIPSpro cannot compile it and will never be able to, since it's not developed anymore. So it is not only about generating faster code, but also about having a compiler, which can actually compile new software.
Therefore, it is essential that we help the GCC developers maintain the IRIX port.

I just checked and mine has a pull-up resistor too, you got ripped off


You can actually turn that off if you have a PC that can run the Seagate tools (or whatever that software is called nowadays). The firmware is the same on all drives, there are just special user-settable flags, which tell it which mode to work in.

It should be possible to change those flags from IRIX as well, but you'll have to mess around with some low-level tools and spend some time reading the drive documentation to find which bits you have to change (I love it how SCSI drive manufacturers put _everything_ in the manual).

IRIX has some tools which can convert various formats to OBJ. Try IvToObj (VRML files are a subset of the Inventor format, IIRC).

You might also be interested in pngcrush (already in Nekoware). It doesn't do anything fancy like pngnqs9, but you can use it to make smaller PNGs in a mostly lossless way:

This will remove various unnecessary parts (e.g. comments and colorspace profiles left by image editors) from the PNG and recompress it using over 100 different methods and keep the one which results in the smallest file size.

It also has options for removing the alpha channel ("-c 2") and reducing color depth ("-bit_depth 8", but it can't go lower than that).

I use it on screenshots and such, works well enough

First, remove everything Java-related, since it's of little use anyways and takes up lots of space

Then remove the following subsystems: *.books (they're on techpubs), manual pages, release notes, and any source or patch subsystems from Nekoware packages.
If you don't need PPP support, uninstall those packages.

Remove demos, pcp_eoe, open{ldap,ssh,ssl} (use nekoware packages instead), performer_demo, Teleffect, appletalk, cosmoplayer, cosmocreate, gateway, outbox, sgi_apache, websetup, Register, dynaweb, macromedia, netscape*, netwr_client, sgimeeting, snmpd, mozilla*, dvdr, eoe.sw.xvm, eoe.sw.xlv, eoe.sw.xlvplex (probably useless on an Indy ), eoe.sw.spell, eoe.sw.optinput, eoe.sw.ipv6, eoe.sw.xfsrt, dmedia_eoe.sw.synth, dmedia_eoe.data.synth, dmedia_eoe.data.prosonus.
These are all safe to remove on an Indy.

If you're desperate, you can also remove NFS support.

I once made a very minimal install of IRIX for an Indy and it was about 150-200MB, but I don't have that list of packages anymore. The standard install has some things most people won't need

Also, some system binaries aren't stripped, so you can safely do that.

Do you have the optional IRIX fonts installed (x_eoe.sw.{Xoptfonts,Xopttype1,Xunicodefonts})?

PNGs load faster and can sometimes be smaller than JPEGs (e.g. on icons, pixel art, black&white drawings, anything with lots of sharp lines ...), also, if you need transparency, PNG is the best option (in theory, JPEG actually supports transparency, but in practice almost nobody implements that, so you're much better off with PNGs if you need an alpha channel).

But for photos, JPEG is better, as you found out

The reason for this is that it uses different algorithms for compression. The one used by PNG is lossless (it's basically the same as used by ZIP, except it does pre-filtering to improve compression rate), while JPEG uses lossy compression (it throws away color information, splits the image into blocks and performs fancy math which then enables the compressor to throw away information which the human eye won't detect, finally, it compresses the resulting data in a similar way to PNG).

So, pngnqs9 is actually lossy, since it throws away color information, but doesn't do any fancy math like JPEG does, which is why its image sizes are between standard PNG and JPEG

pngcrush, on the other hand, just tweaks the parameters of the lossless compression to produce smaller files.

If you're sending an intermediate image to somebody over email (or uploading it somewhere), it would make sense to recompress it with pngcrush ("pngcrush -rem text -brute in.png out.png"), but for final images, stick to JPEG.

This one is accessible at http://techpubs.sgi.com/library/tpl/cgi-bin/browse.cgi?coll=0650&db=bks&cmd=toc&pth=/SGI_Developer/MproCplrDbx_TG . It ends with -010, so I assume it's a newer revision of that document.
They probably forgot to update the links pointing to it in other documents, so there's a good chance the rest of the documents in that list are still accessible, but as newer revisions.

Ah! I see
IIRC, SGI included some of these books on IRIX CDs, so if you can find the appropriate IRIX version which existed when that document revision was released, it should be possible to extract the book from the installation CDs.

+1 vote for 1.28.4, works well here

Thanks!

+1 vote for current.

Thanks!

Not to ruin anyone's dreams, but... to make this program work on IRIX, it would probably have to be rewritten.

Let's take a look at how this actually works.

Inside the display, there's a tiny serial EEPROM, which is directly connected to the I2C pins on the VGA/DVI connector (you can read the EDID data even when the monitor is off).

To read that EEPROM while the monitor is connected to a computer you need:

• a graphics card, which has the I2C pins on the VGA/DVI port connected to its I2C bus
• a driver for accessing the I2C bus on the graphics card

Problem #1: apart from the newer VPro (and maybe O2) hardware, I doubt any other SGI graphics cards connect the I2C pins to anything, so they're simply inaccessible.

Problem #2: accessing the I2C bus within IRIX.

Let's ignore the first problem (surely everyone has a VPro system somewhere ), but the second one is a bit more difficult.

Xsgi probably has some way of accessing that I2C bus (gfxinfo sometimes reports the correct monitor name and that info is stored inside the EEPROM inside the monitor), but there's probably an undocumented API for doing that.

Disassembling gfxinfo would probably be a good start -- we could then see if it just reads the data Xsgi prepares for it or if it actually accesses the I2C bus on its own.
If it does the latter, then it would be very simple to use that code to dump the entire EEPROM into a file and get the timings and everything from that later.

If everything is done within Xsgi, then this project is probably dead
It would be possible to write a dummy driver for the I2C bus on the VPro using the work some open source people did on reverse engineering it, then kill Xsgi, load that driver, run a program to read the entire EEPROM, then unload the driver and restart Xsgi. But does anyone actually have time to implement this?

Regardless, if we could access the timing data from within IRIX, it would be possible to make a program which automatically generates video formats based on the data from the monitor. That would be very cool

Hi!



Try moving the DIMMs from slots 4,6,5,7 into slots 0,2,1,3.

Then if you can get into the PROM, type "enableall", followed by "update", and finally "reset".

That's a good idea.

Type "debug 0x10d" in the L1 console to do that. This will disable power-on diagnostics, enable verbose output, enable booting directly into POD mode, and most importantly: ignore disabled CPUs and memory.

Once in POD mode, type "go cac" and the commands jan-jaap suggested. Before you enter "reset" in POD mode, type "dbg 0" to disable the debug switches (you can also escape to the L1 prompt and type "debug 0" for the same effect).

After the system restarts, you might still need to do "enableall", "update", and "reset" within the PROM.

NFS is actually a separate subsystem in IRIX, so it's possible you just don't have it installed.
You can check that with "versions | fgrep nfs".

You can delete __attribute__ and everything from it to the semicolon. In this case, it's just a hint for GCC that the function behaves like printf.

Since it deals with filesystem access, it's possible that the code uses __attribute__((packed)) or something similar for various structures. You must convert these hints into their MIPSpro equivalents (IIRC "#pragma packed" in front of the struct should work fine)


IIRC, they are actually in the kernel (it would be too slow otherwise), but each FS has its own module, so it should be relatively easy to add new ones.

One of the things on my ever-growing todo list is to port FUSE to IRIX. Then we could use practically _any_ filesystem

I'm not very familiar with how OS/2's kernel worked, so it's possible they made this idea work fast enough, but on UNIXish systems, such an approach is much slower. If you look at the diagram on the wikipedia page on FUSE, you'll see that it needs to do 4 trips across the user/kernel boundary and those are relatively expensive. It's not a total deal breaker, but significant enough that you wouldn't want to have your root filesystem in userspace.


Oh, the VFS is entirely in-kernel

If you look inside the directories under /var/sysgen, you'll see the object files for various kernel modules that are linked together to make the final /unix kernel when you run autoconfig. Among those modules are also filesystems. By editing the accompanying files you can actually make an IRIX kernel without support for FAT or something

Oh


That's probably the best option, good luck

It looks like the filesystems were in-kernel, but there was also an option to use a FUSE-like arrangement, for easier development.


It should be fairly straightforward to implement a FAT16 filesystem module

You don't need the IRIX source code to make a new FS module, the required structures are in the publicly available headers and there should probably be some official documentation on how to do this.

It's similar to developing new device drivers for the kernel.


Interesting! It doesn't seem to be documented anywhere -- perhaps it wasn't finished?

I will disassemble the module when I get some free time.


You can also remove PPP support and some special locking implementation for Oracle databases and there's plenty more like that

I had fun commenting out stuff in that irix.sm file when making a minimal kernel for an Indy with a memory shortage. But be careful not to comment out too much, otherwise the system won't boot