Hi all,
I haven't posted much in the last while, and indeed for a while I didn't do much with my machines. However, I've recently restarted work on the problem that stopped development on D1, my web rendering/application offloading card for the O2 (discussed here), in mid-2018. Some people seem to believe that the D1 was never finished because the hardware was never completed - this is only partially true.
There was indeed a working prototype bench setup using the final SOM and software, which worked well, and one proper prototype board, which mostly worked and lived in my main O2 for several years. I also built up a stockpile of the key component - the TNETE100APCM Ethernet chip, which I managed to buy a new-old-stock tray of. The reason there was never a second D1 prototype board, which I'm quite confident would have worked, was that I was never able to get the software working adequately on the bench setup.
When working on the D1 hardware, I essentially assumed the software was trivial (and that for most purposes X forwarding would be fine). However, when I actually went to try to use anything nontrivial on it, I found that there was essentially no fast way to remote display to an IRIX machine. I tried simple X forwarding, all manner of VNC/TightVNC configurations, rdesktop, and I think even managed to build Xpra. None were fast enough to make web browsing actually enjoyable. Having seemingly tried everything, I essentially decided it wasn't fast enough, D1 wasn't going to work well enough to be useful, and stopped working on the hardware.
In late 2020, knowing a bit more about OpenGL and figuring there might be a better solution, I experimented with, and wrote a half-working proof-of-concept for, an OpenGL-accelerated client for the Browservice remote web rendering server. Browservice was designed to be accessed over HTTP from a simple browser, and provided images as JPEGs, which made things a little more complex and not the most efficient, but this did give me the opportunity to benchmark the relevant parts of the system and conclude that with fast, OpenGL-based display, remote display on IRIX could actually be very smooth.
Finally, in the last week or two, I've gotten my Tezro up and running again (though I've learned its snaphat battery has started to die - it currently thinks it's the year 1909), and decided to actually sit down and put together a proper fast remote display system, which I have called DFRD - Dodoid Fast Remote Display. It's uses its own server and protocol, and is not a client for VNC or another existing protocol, or for Browservice. It is written in C, has no external dependencies other than libs IRIX includes, can be compiled with MIPSpro and 100% stock IRIX 6.5 libraries, and uses OpenGL (specifically glDrawPixels as opposed to Glowser's approach of texturing quads - thanks to drmadison for that suggestion, it should allow use on no-TRAM/low-TRAM machines) to quickly display frames - this was the major bottleneck for many other remote display clients. The server runs on another system, and captures from a real X display (currently testing with Xvfb) using XShm - this should allow for the server's graphics hardware, if equipped, to be used if desired.
This is a demo of it running, streaming a Firefox instance running on the server (my laptop), at a resolution of 1024x512, 16 bpp. Resolution and framerate could both be configured higher - benchmarking suggests around 90-100 fps would work here, and there's lots of room for optimization - but it uses a set "target FPS" and that's set to 30 for this. It's smooth and low-latency, enough for smooth scrolling and video playback, and noticeably better even than VNC to localhost on my laptop of the same Xvfb.
Since most of our SGIs do not have gigabit networking, lossless image compression is used, specifically the SLIC codec, a variant of the currently-trendy QOI. SLIC is simple (basically only four "operations"), efficient (nearly as good as PNG in my test cases), exceptionally fast (compresses frames in milliseconds on my relatively old laptop, decompresses in milliseconds on my Tezro), and has native support for more color spaces than QOI, including 16-bit RGB565, which I have chosen to use for performance reasons in this case. However, its reference implementation (the only implementation I am aware of) cannot handle big-endian platforms, and is somewhat complex for this use case. As such, I chose to reimplement its decoder entirely, as
It's definitely not complete right now - most glaringly, it is currently strictly remote display - there is no forwarding of user input back to the server (the browser in the demo video is being controlled by a VNC connection to the same Xserver, the VNC server has nothing to do with DFRD though), though that shouldn't be too hard to add with XTest, and lacks audio support entirely. There are also currently no provisions for security or authentication (frames are sent unencrypted and the server will accept any client), and the code could use a lot of cleanup and optimization. Additionally, there's TONS of room for optimization - the code is currently single-threaded on both ends and there is virtually no "pipelining" - the most obvious thing to improve performance next would be to have the server queue the next available frame such that the client doesn't need to wait for it to be compressed before retrieving it. However, it works, and it's the fastest and best-looking I've ever seen remote display to an SGI machine be.
With this working, the main thing that prevented the D1 from being worth completing is now quite clearly solvable, and I would be able to work on a D2, with much more modern hardware, if there was still interest in such a thing. In particular, I think if I did this today, I would not try to force the stream through an ancient unobtainium Ethernet controller that was not cutting edge even at the time and only ever had drivers on IP32. SGI machines have usually quite decent Ethernet onboard already, and it's easy to see a revived D2 simply using the slot for power and mounting, connecting to the Ethernet port on the motherboard and providing another port on the card for your LAN. This would let the card work in far more machines, and take advantage of gigabit Ethernet where available (like on the Tezro). Having the SGI connect to your LAN through the D2 by default also makes things like letting the card provide WiFi connectivity to the machine simple. Running the card in an external enclosure, or running the software on another computer entirely, would also be possible, though putting it on a card mounted in and powered by the SGI itself still seems the neatest solution in many cases, especially if you want to use it for "connectivity" things like WiFi or making USB storage devices accessible to IRIX.
I hope to release the source for this as soon as I'm able to get it to a vaguely usable state - this showed its first frames mere hours ago and like I said, there's still a lot missing. However, it works, and in the mean time, I'd love to hear any comments about DFRD or, if people are still interested, a potential D2.
(also posted to IRIX Network (link))
I haven't posted much in the last while, and indeed for a while I didn't do much with my machines. However, I've recently restarted work on the problem that stopped development on D1, my web rendering/application offloading card for the O2 (discussed here), in mid-2018. Some people seem to believe that the D1 was never finished because the hardware was never completed - this is only partially true.
There was indeed a working prototype bench setup using the final SOM and software, which worked well, and one proper prototype board, which mostly worked and lived in my main O2 for several years. I also built up a stockpile of the key component - the TNETE100APCM Ethernet chip, which I managed to buy a new-old-stock tray of. The reason there was never a second D1 prototype board, which I'm quite confident would have worked, was that I was never able to get the software working adequately on the bench setup.
When working on the D1 hardware, I essentially assumed the software was trivial (and that for most purposes X forwarding would be fine). However, when I actually went to try to use anything nontrivial on it, I found that there was essentially no fast way to remote display to an IRIX machine. I tried simple X forwarding, all manner of VNC/TightVNC configurations, rdesktop, and I think even managed to build Xpra. None were fast enough to make web browsing actually enjoyable. Having seemingly tried everything, I essentially decided it wasn't fast enough, D1 wasn't going to work well enough to be useful, and stopped working on the hardware.
In late 2020, knowing a bit more about OpenGL and figuring there might be a better solution, I experimented with, and wrote a half-working proof-of-concept for, an OpenGL-accelerated client for the Browservice remote web rendering server. Browservice was designed to be accessed over HTTP from a simple browser, and provided images as JPEGs, which made things a little more complex and not the most efficient, but this did give me the opportunity to benchmark the relevant parts of the system and conclude that with fast, OpenGL-based display, remote display on IRIX could actually be very smooth.
Finally, in the last week or two, I've gotten my Tezro up and running again (though I've learned its snaphat battery has started to die - it currently thinks it's the year 1909), and decided to actually sit down and put together a proper fast remote display system, which I have called DFRD - Dodoid Fast Remote Display. It's uses its own server and protocol, and is not a client for VNC or another existing protocol, or for Browservice. It is written in C, has no external dependencies other than libs IRIX includes, can be compiled with MIPSpro and 100% stock IRIX 6.5 libraries, and uses OpenGL (specifically glDrawPixels as opposed to Glowser's approach of texturing quads - thanks to drmadison for that suggestion, it should allow use on no-TRAM/low-TRAM machines) to quickly display frames - this was the major bottleneck for many other remote display clients. The server runs on another system, and captures from a real X display (currently testing with Xvfb) using XShm - this should allow for the server's graphics hardware, if equipped, to be used if desired.
This is a demo of it running, streaming a Firefox instance running on the server (my laptop), at a resolution of 1024x512, 16 bpp. Resolution and framerate could both be configured higher - benchmarking suggests around 90-100 fps would work here, and there's lots of room for optimization - but it uses a set "target FPS" and that's set to 30 for this. It's smooth and low-latency, enough for smooth scrolling and video playback, and noticeably better even than VNC to localhost on my laptop of the same Xvfb.
Since most of our SGIs do not have gigabit networking, lossless image compression is used, specifically the SLIC codec, a variant of the currently-trendy QOI. SLIC is simple (basically only four "operations"), efficient (nearly as good as PNG in my test cases), exceptionally fast (compresses frames in milliseconds on my relatively old laptop, decompresses in milliseconds on my Tezro), and has native support for more color spaces than QOI, including 16-bit RGB565, which I have chosen to use for performance reasons in this case. However, its reference implementation (the only implementation I am aware of) cannot handle big-endian platforms, and is somewhat complex for this use case. As such, I chose to reimplement its decoder entirely, as
uslic
, a decode-only, currently-RGB565-only, endianness-independent implementation which also appears to perform equally or marginally better in my testing.It's definitely not complete right now - most glaringly, it is currently strictly remote display - there is no forwarding of user input back to the server (the browser in the demo video is being controlled by a VNC connection to the same Xserver, the VNC server has nothing to do with DFRD though), though that shouldn't be too hard to add with XTest, and lacks audio support entirely. There are also currently no provisions for security or authentication (frames are sent unencrypted and the server will accept any client), and the code could use a lot of cleanup and optimization. Additionally, there's TONS of room for optimization - the code is currently single-threaded on both ends and there is virtually no "pipelining" - the most obvious thing to improve performance next would be to have the server queue the next available frame such that the client doesn't need to wait for it to be compressed before retrieving it. However, it works, and it's the fastest and best-looking I've ever seen remote display to an SGI machine be.
With this working, the main thing that prevented the D1 from being worth completing is now quite clearly solvable, and I would be able to work on a D2, with much more modern hardware, if there was still interest in such a thing. In particular, I think if I did this today, I would not try to force the stream through an ancient unobtainium Ethernet controller that was not cutting edge even at the time and only ever had drivers on IP32. SGI machines have usually quite decent Ethernet onboard already, and it's easy to see a revived D2 simply using the slot for power and mounting, connecting to the Ethernet port on the motherboard and providing another port on the card for your LAN. This would let the card work in far more machines, and take advantage of gigabit Ethernet where available (like on the Tezro). Having the SGI connect to your LAN through the D2 by default also makes things like letting the card provide WiFi connectivity to the machine simple. Running the card in an external enclosure, or running the software on another computer entirely, would also be possible, though putting it on a card mounted in and powered by the SGI itself still seems the neatest solution in many cases, especially if you want to use it for "connectivity" things like WiFi or making USB storage devices accessible to IRIX.
I hope to release the source for this as soon as I'm able to get it to a vaguely usable state - this showed its first frames mere hours ago and like I said, there's still a lot missing. However, it works, and in the mean time, I'd love to hear any comments about DFRD or, if people are still interested, a potential D2.
(also posted to IRIX Network (link))