SGI: Discussion

Hi everyone, i have a coming project that deal with fingerprint authentication and i was wondering maybe our SGI has experience with this task? Has anyone tried to do it under IRIX? If yes can you share me some info how to do it and any advantage over PC? I know PC these days will just eat this up but i was thinking because SGI is more about image processing, maybe i can utilize it for this project

as far as my research, if speed is needed, i should go with match-on-device.. but DSP and SoC is a bit expensice i guess so i would try match-on-host, so i want to try if SGI is capable and can utilize the SGI's image processing power for this task. O2's ICE will be ideal right? but hmm i cannot imagine two sensors scanning at the same time..

SGIs are general purpose computers, so they'd be capable
... but ...

the graphics hardware is definitely not a GPGPU. If I recall, ICE was able to be accessed by some software (cf the Photoshop accelerator), but I don't think SGI ever publicly released the docs on how to do this. Seems there is/was an effort to get some support in Linux ( http://www.linux-mips.org/~glaurung/ ), but I'm not sure where it is now.

On the other machines the graphics are pretty much one-way devices - shovel data in one way and get a display signal out the other. If you really work at it you might be able to get the Command Processor in InfiniteReality to do some stuff for you, but then you're just using a ARM slave processor, which isn't too special. I don't think the computer end can access the GEs directly in any of the big SGI graphics.

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

Image processing and image generation are not necessarily the same thing.

SGI made some of the graphics HW available for image processing tasks (i.e. read back processed data from the graphics pipeline) via the Image Vision library (I believe that's the name). I have seen it bundled with some of the SGI mips development packs.

But I assume this is one of those mental masturbation exercises, as there seems to be no point to this project, honestly. It is a dead platform, it is very outdated, and frankly you can get better performance/support for image processing tasks with some of the newer OpenCL/Cuda hw/sw stacks you can have now a days for peanuts. Life is short, waste your time wisely.

morning guys! thanks for the inputs


i see.. hehe thanks SAQ, actullay i already plan to do this on match-on-device or match-on-card.. is just try to ask maybe somehow i can utilize my O2 to show them my SGI still is usefull in this area if possible


hi Shades! actually yeah, past months ago i was interested about ICE esp when reading from Ian's site.. digging around until i got some notes from the developer of Pegamento.. really interesting ok2 i will try again where i left.. as soon as i get my new HD from Ian, ill get back on this

oh! i just have a PVO on my Octane, is this covered? by loading code, do you mean if we can access it through IRIX and let it process something? this is cool indeed!! but hmmm i think i only have PVO.. my next project in mind for my two SGI is to have decent video chat with todays PC

hi r10k! i see.. hahaha yes2 its a mme or something as ive mentioned, my main game plan is either match-on-device or match-on-card.. currently i got 1 chip solution from OKI, another is using TI DSP, then worst case is SoC.. but for match-on-card, any MCU with decent speed is enough.. hehe ok2 heed your advice on life.. time is gold indeed

Similar to owning a Porsche ?

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

hi shades!


hehe ok here it is, but i think you alraedy read this before, its just some tips on how to code so that it will be forced to be processed by the ICE instead on the CPU

ah i see hehe if ever you get back into this and find something, can you also please let me know? how about we both dissect this insect and share notes? would be fun! hehe

oh!! hehe so i guess i need to pass on this one, its ok shades no need to goggle image, ill just stick my nose with ICE for a while, so whats the game plan doc?

hmm sounds deep and interesting.. ok so both of these undocumented chips are mostly for image processing right hmm if once we uncover how to use them, whats the next game plan?

waaah but here in my location, this number is good for them esp the nomber eight!! hehe

Six is "go smoothly" , eight is "money." So if we combine the west's sign of the devil with the east's smooth path, Shade better make a couple more posts quick

hahaha just put one post for me and one post for ham, then it will be 668

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

nop got this from ian's site. oh! thats great then and hmm may i know how you disassmble these libraries? are you reading binaries? or API documentation? would love to follow your foot steps on this coz i think i can have some spare time for this

hehe i see, thats ok shades ill just PM you soon then lets discuss our game plan

hmm if you say disassmble, do you mean you use a debugger to do step by step on the assembly program? or are you decodin raw binaries? oh! i think i download that code but it was for linux?

hmm ok2 noted, its a great plan btw, IIRC i read from Ian site that DMBuffer is used by ICE for input and output while dmIC is the API, does this helps?

hmm ok2 this indeed sounds interesting, will look fwd to this then

hmm if you mean RAM on it does it mean its like a SOC? or you mean registers? coz i thought its an ASIC and ASIC is not capable to have RAM inside? or do you mean the cache memory? sorry for my ignorance hope you can enlight me i also thought that all datas that will pass to ICE is only via DMBuffer in which i assume is only on the main memory right? maybe it just need a pointer? anyway your statement is motivating hehe its still doable but just need to be optimized for ICE right? ok2 then! lets do this oh just notice, you meantioned decoding JPEGS.. but i thought ICE was indeed built for JPEGs, do you mean some other format of JPEG?

oh!!! that then thats more interesting then! but yeah if thats the price, hehe i still need my arms and legs hehe but if the same luck will happen to me again, will see (my luck: paid for PVO, arrived is PVO+MXE)

ah i see hehe and yeah its indeed an interesting card.. let me check local taobao then


oh? you mean the card alone? or the card still inside Octane? that indeed is cool to try!! hehe but how about an OS that doesnt need MMU? Minix maybe? or RISCOS? not sure hehe or an RTOS maybe? i love RTOS coz thats where i work everyday

oh!! ok2 noted then but hmm its already confirmd it doesnt do floating point as stated at ians notes.. anyway still this ICE needs to be melted hehe

haha then expect a smooth money this coming CNY

btw shades, one question for ICE.. when we use the Analog Video in, is ICE utilized to handle the window size? i mean it can resize the video resolution to a higher without degrading the image quality?

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.