Slashdot Mirror
Experiences When Transitioning to Low-End Workstations?
gerddie asks: "Lately, we have seen a lot of companies starting to move their graphics stuff from high end to low end linux workstations (e.g. Dreamworks).
Of course one reason to do such thing is cut costs, and therefore, at our institute we are going to replace or aging SGI O2s with Linux workstations. I wonder if you have experience with such a transition - especially regarding the usability of such machines for (scientific) visualization? What is working well, and where did you encounter pitfalls?"
SGI O2's run on a shared memeory idea. This format makes graphics on O2's quick because the common operation of sending data from what would be main memory to what would be texture / video memory on a PC extremely quick. Instead of having to travel through a latency timer and a PCI or AGP bus, the memory is just copied or a far jump send to the video controllers.
However... With as fast as linux boxes are now, and as old as O2's are, I think you'll see a performace increase on the Linux side. I suggest you run a non-free windowing system instead of XFree86 (you'll find there are some commercial X-es out there that benchmark dramatically faster than XFree), and do a little streamlining of your kernel before putting the boxes live.
Ta!
Our biggest problem has been that many of the cheap boxes were cheap, and at least one needs maintenence weekly.
Well, if you did what we did and transition your SGI 02 R10-12ks to 2+Ghz PCs w/ a good quality graphics card, you can expect to see 5-10x the rendering performance at 1/3rd of the price.
If you're used to SGI's extremely high quality "no bullshit" service department you might be in for a rude surprise, however. Even the very high end Dell service plans will only get you someone who goes on site for 30mins to change a component. They neither have the willingness nor the ability to diagnose symptoms, and none of them know ANYTHING about Linux.
This can cause you a lot of pain and suffering if you have difficult-to-localize hardware issues in a demanding environment. My advice would be to either keep your own inventory for severe support scenarios, or go with a system vendor that provides a much higher quality level of field service than Dell's "partners".
While Nvidia's OpenGL is pretty good, there are a few obscure corners used by our seismic applications that they don't seem to support. In particular, the facility to use colour indexed textures is not supported in their current driver. It was supported in the earlier drivers, but there's not support for the later cards and a bunch of other bugs to cope with as well. It just means 4 times the texture usage or using vertex programs for the same effect, but not all high end hardware appears to support the vertex stuff. From what we can tell ATI has their own set of problems. Sigh.
Metro-X and Xi are the two I've heard about.
Well , i am in the middle of the project right now, and it was a hard way. We had simulation packages tunning on SC nodes, and that have been converted to linux. The visualization and data extraction tools are currently being migrated to linux too(from AIX, SGI and and Solaris 8). We are using UNIRAS graphics librarybya avs.
:).
:) (that one was fun)..
/*Why is there a penguin on my desktop?!*/
Problems you are going to meet are:
1) Big/Little endian issue, and this is one of the worst problems u will meet in your life
2) There are minor code changes that you are going to do, concerning memory allocation.
3) Ofcorse you will have to take care of large file support.
Well, thats what i can remeber at the moment..
The lunatic is in my head
One of the best original uses for O2 was graphics with a lot of textures. As O2 uses a shared bank of ram for everything, a texture could be nearly any size. Some crazy people even wrote demos that would fly over 800MB+ texture maps. The downside of O2 is the rather limited geometry performance. This is why many of the "Killer Apps" for O2 are in the video industry... such as controlling the weather graphics for The Weather Channel and for local TV stations. Not much geometry there, it's mostly textures and makes good use of the O2's built in analog video ports (or optional digital video card).
Another downside of O2 is its CPU performance. The machine was originally designed for the R5000 processor and as such, the R10K and R12K processors were basiclly hacked in. They don't even use the IRIX64 kernel that an Octane does! Plus performance is much lower. We've seen cases where a CPU benchmark on a 300 MHz R12K O2 is less than 40% of the score on a similar Octane. So they are clearly totally different machines with totally different uses.
I think you'll find modern Linux PCs to much much faster than your O2s, especially for CPU performance. Graphics should be much faster too, unless you had been using some very specific O2 features, but even then you'd have to have been using some very large textures to see a difference.
Keep in mind that the SGI O2 was first sold in 1996. Yep, 7 years ago. You're more than due for an upgrade!
Absolutely, positively have multiple vendors come in with their graphics workstations and then proceed to evaluate how well your critical applications can run. Expect this process to take months.
Finally, I'm not sure how large and mature your present environment is, but if you're talking about more than a few seats and two or three apps, expect a transition that takes a long time. Let people run their O2's next to their Linux boxes. Eventually, if you give the Linux systems proper care and feeding, you'll see dust start to collect on the O2's. Then, and only then, have you successfully completed your transition.
While I agree that a modern PC will be much faster than any O2 (that machine is 7 years old, good grief!), I do have to point out a few things...
unless you were attached to those funny 4 bit visuals on the O2s
Do you mean 5-bit visuals? The two most common visuals on O2 were RGBA5551 (common for analog video work) and 8-bit visuals -- RGBA8888 (common for everything else, but slightly slower for realtime video).
Some OpenGL extensions are not available (think those funky SGI, SGIS, SGIX ones, and ARB_multitexture is just different than SGIS_multitexture)
Most of the funky SGI extensions from that era are now available in one form or another in OpenGL 1.3 and 1.4.
Even if you compare PCs to Octanes, Octane 2s or Fuels, the PCs wins
Fuel blows... while its faster for single CPU tasks than Octane/Octane2 due to its use of Origin3000 parts, it's limited to one CPU and its only XIO interface is used for graphics. Everything else hangs of a single 64/66 PCI bus. It's a good workstation if you need IRIX, but it's pretty much worthless for most tasks people use SGIs for in the first place!
Octane/Octane2 still has its uses. It no longer leads the performance or RAM capacity race, but it can still outperform most PCs for real-world information processing due to its architecture. Granted, your application has to be written for the platform. Common uses of the Octane are MRI scanner processing, front end to an Origin supercomputer, and realtime visual effects work on HD material (IFX Piranha, Jaleo, MuleHD, Discreet Flame and Smoke). This type of work often involves mutliple maxed out channels of fibrechannel, uncompressed HD video interfaces, and sometimes a GSN (HIPPI 6400) 800 Megabytes/sec connection to one or more larger SGIs. Octane makes for a pretty lousy 3D modeling box these days as cards such as the 3DLabsWildcat 7210 or VP990 atop a modern PC can simply outperfom any SGI config for that type of task and do so for a lower cost.
Other points:
The O2 was a 32-bit machine. Even with an R10K or R12K CPU shoehorned in, the O2 was limited to 32-bit addressing and pointers. It did, however, still use the full 64-bit IRIX OS with large filesystem and file support.
One area where you may find a problem in porting your software is texture usage. Because the O2 used system ram for everything, it could handle up to about 900 MB of textures without any sort of swapping or transfering. While there are a few apps that make use of this, most don't and you're unlikely to run into such a situation with your applications... but it is something to keep in mind. If you need a lot of textures, consider the 3DLabs V990 as it can handle about 400 MB worth.