I would have to disagree with most of what you have said.
SGI going to IA32/IA64 is an obvious choice.
The MIPS is falling behind in mhz.
SGI shops feel comfortable staying with the SGI name but they will leave them if the price/performance ratio drops too much.
I agree that the SGI web servers are a joke... they are manufactured by VA, I believe, so why not buy a VA box?
I also agree with the switch to NT. But I also know that the people I work with that want the SGI NT boxes will not give them up for Octanes.
Obviously you haven't been paying attention to SGI press releases... The Origin line has gone from the 200 to the 2000 to the 3000 series, all in the last year or two. Each of them still being sold and produced. They are expanding the line.
By IA64 compatability in the 3000 line, they are allowing themselves to take advantage of a largely distributed CPU that will continue to be developed and improved.
Also... most programs that run under Linux are also ported for Irix. And... even if the Origins do run Linux on the MIPS, the code still needs to be ported for the chip, so that argument is moot.
Maya is still being developed for the SGI, so people are still developing for it. Maya is a killer app. It is why we have 50+ SGI boxes in house. I know other studios are the same.
As I have said, people buy SGI for the name. The name implies a level of quality and support. Big places spend money for products they trust.
In upcoming games that composite 20+ layers of textures, the cost of a blit is down in the noise.
Do you really see the game market using so many textures? Are you expecting these to be images or generated textures (generated from a series of functions)?
If this is the case, systems are going to need much wider and/or faster buses and more T-Ram on the video card. Also, I see where people are going to have to start watching texture sizes and color depths.
In my job, where we worry about texture sizes for rendering, this is always a place where we butt heads. I would love small, simple textures and the modelers want large, beautiful textures. I typicaly give in more than they do, because a sharp looking video is a sharp looking video, and the buyer doesn't care that the images took an extra 20% or so to render.
In the gaming world, though, the user wants real time... so they might not be as happy with the 20% performance hit.
Page flipping doesn't apply to windowed rendering unless you butcher the X server to render all 2D to multiple buffers and clip all 3D operations. I consider that a bad thing. Making the full screen rendering more distant from windowed rendering is also a bad thing.
This reminds me of the old hack for Mesa and the Voodoo chips. Is this the same thing? Where the full screen renders were fast but the windowed renders sucked because they were copying bits from one buffer to the other?
Most of the coments I see are gamers pondering if it is worth it yet to game on the Linux platform, even with the better benchmarks. Some seem to think that because the mAcro$oft becnhmarks are still a tad better that they should stick with the gamers OS of choice.
I come from the other end of the spectrum. I am anxiously awaiting these near similar benchmarks. Linux graphics machines are going to be a reality soon. The A|W port of Maya is going to be ready next year, the SGI Linux boxes exist, and now, the drivers seem like they will be ready for the release.
This is great news. All SGI shops now have an alternative to NT. I know that many are evaluating the choice of SGI vs. NT with the increased NT performance and the lower prices. With Linux in the mix, good things can happen.
If you look at what SGI has been doing in the last couple of months, they have been setting themselves up for this switch.
1) SGI has ported Linux to work on the Origin series of machines.
2) SGI has designed the next series of Origins to run on either IA64 or mips (with Linux support)
3) SGI has produced Linux graphics workstations with more standard hardware than the NT only boxes of a few years ago.
4) SGI has worked closely with NVidia for graphics hardware solutions
5) SGI has signed a deal with Intergraph (one of the leaders in NT graphics boxes) to sell Intergraph boxes
The first four point to Linux in the graphics world. The last one seems to either be a failsafe or.. as I see it, a chance to sell more boxes that could be dual boot graphics stations with some research.
The next year will be interesting for all places that are SGI shops.
I was just thinking. I read a SIGGRAPH paper about adaptive voxels for real time fly-overs.
The idea was to swap voxels for when the objects get nearer to the camera.
A system could be used like this where voxels are used on all objects that need little detail far away and polygonal objects are swaped in when the object is near.
What it boils down to is an easy way to store a curved data set. The display part is trickier... and that is where the acceleration would be nice.
If you had a curved object, you could break it into poly's and have all the triangle points stored in memory or you can have the control points (and the weights if used) stored in memory.
Obviously the math for the poly's are faster but the display isn't as smooth (Such as Quake 2). With bezier patches, the display takes more math but is smoother because you are representing curves and not lines.
When it is all said and done, the math isn't too bad, it is just additional math that needs to be done at 30+ fps.
I don't think the moderator caught what I was saying...
People will continue to use the X86 arch because the cost of software migration is huge. Think of all the apps that are on your office machine and the servers.
Most of these are licensed and in some cases are platform specific.
For Intel to move to the next arch, it has to be backwards compatible, which tends to slow it down (or at least make it slower than a native chip at this speed).
Extending the life of the X86 is a double edged sword. It is delaying the transfer cost but it is possibly slowing down the potential of the desktop.
I for one would love to have the next arch out and running, but I would hate to have two machines... one for all of my legacy software and one for all of my new stuff.
Hmmm... takes me back to my Senior year in Surfaces and Modeling.
I think that accelerated Nurbs would be more benificial. At least nurbs are the choice of Maya... I can't remember what the other packages like.
But... accelerated Bezier patches is a step towards faster nurbs.
Not always...
With RAM being cheap and cache on chip, disk speed will only give certain gains.
The work that I do (software rendering) is as much or more CPU bound than it is I/O bound and it is all over the network from a new RAID system.
Boosts in CPU speed is big news. Compare 42 dual 600's vs 42 dual 1,400's... the difference is worth being excited about.
Also... space efficency. More power in a chip, the less boxes (in theory... we all know projects expand to use what you have) needed.
Hmm... we could stop using the X86 Arch...
Like we could all use DEC Alpha's... those are prety darn fast.
Wait... the apps aren't ported... and those that are cost money for new licenses? Whoa... maybe not such a good idea.
We are going to be stuck on the X86 as long as it is cheaper to make them run faster than it is for all of corperate america to make the binary switch to the new platform.
I have seen where some satalite companies offer such a service and the rates seem to be decent... not much more than to use a cable modem or dsl...
And the down stream rate is supposed to be good as well.
I wonder if one was using Linux and the floating point emulation if they could best the onboard FPU of the chip.
Maybe this chip is a reason for people to still be making math co-processors...
Why is this question a "Is there better support than company A?" instead of "What good forms of support are there?"
Mentioning companies is bad form.
By your post, those that have never used company A now will think worse about them. You could of had an isolated incident. A new person working support. Who knows...
With that being said, I have had good experiences with VA. Parts always arrive. We did have problems getting the right rails for one of the boxes but everything else was handeled well.
Our local support has spent many hours helping install and configure software. I now have my VA render farm to where all I do is add a machine, throw in a CD and 20 minutes later, I have a new render node.
They have been more than I could have hoped for.
I, for one, love the ability to use a good gui to config a system. I am jumping between Linux, Irix and Solaris and I sometime have a mental lapse as to where things are... like... um... what config file has the services in it?;)
Not all of them are that easy.
I use linuxconf to do a quick config of my system.
NIS info changed? Click, click... type type... restart... all better
I know what I want done. I know the theory behind it. I don't want to have to wory about a little file.
Also... mentioning NIS and DNS and all of that... it is so hard remembering about SGI's new all in one daemon. Going between that and Linux daily is enough to drive a person crazy...
I HUP'ED the ypbind... why is it not taking it...
Oh... yeah... that other daemon... nsd... yeah... HUP that mug.
I agree with the remark about most places do slow frames in a massively parallel system. We made the same choice. 40 dual 600mhz Linux boxes.
But... we also had lighting tests and renders for marketing that needed to done quicker than a nightly turn arround. That is when we used the O2000. We turned this machine into our file server, so now we can only dream of when we could render single frames faster.
In a perfect world, both systems would exist. A bunch of Linux boxes for 24x7 renders, a massively parallel box for large or quick turn arround single frames that could be used for "normal" renders 24x7.
Beowulf is not good for rendering. Each job can have up to 500-700 megs of memory being used. Share this over a 100bT or Fibre or some other network protocol. It won't work.
We use other approaches for rendering. We spread the shot over a machine, not the frame. We eat the overhead of starting the renderer and reading the file. If possible, for those users who need one frame done fast, we threw it on our 4 proc O2000. That machine was taken from me, so now they just have to wait 4x's longer.
Beowulf has its uses. Production rendering is not really one of them.
I mostly agree with all of your above points. I hesitate only because Linux has a away to go to match Irix (or some other *nix OS) in some instances. SGI boxes are hanging arround as servers for a reason.
I would love to have one server OS and tune the platform to the job. But... it will be a few years before places are doing this. This port is a step in the right direction.
This is a great machine for rendering or any other application that is both CPU and memory bound.
Some jobs do not parrallel well, such as individual frame rendering. With 24 boxes, the 5 + minute overhead of loading the scene file plus the memory spent on loading the textures and the geometry would be done on each machine, costing you 24x's the overhead of doing it on one machine. Trying to do this with a "quasi" shared memory system would kill the network. But would remove that hidious overhead.
Doing this on a NUMA box fixes all of those problems. The memory is shared. The procs all look like one machine. The system runs smooth and well.
This is why SGI is still in the large graphics server environment. People want individual frames done fast.
The benifit of this being a linux box and not Irix....
I, a huge linux vs. irix advocate, strugle to see why this would be good. Most of the apps that I would use are built for Irix first and then Linux (like Maya's renderer). I can see where others might have custom apps to use this, but the code would probably port to Irix just as easily as it would to Linux on the MIPS.
It is a step in the right direction, IA64 NUMA boxes running linux. The ultimate in render farm machines.
Numa is not even close to how beowulf works. NUMA allows the procs to actualy work together with shared memory instead of a near shared memory that beowulf provides.
Trust me, the cray link is much more efficient than what a fiber connection bewteen beowulf boxes would be, even if you went all out and did some sort of cube configuration.
If beowulf was better, people wouldn't be shelling the money for the SGI boxes when they need the horse power, they would have some "wulf" farm working on the problem.
There is software that does this on the DB side. The company that sells it could probably suggest a good way to store it as well.
We have looked at doing a similar thing because we produce 200 GB of images and movies every few months. Our web group and marketing group wants to get at this data later but doesn't know exatly what they want till they see it.
We are still looking at different solutions for this. Some suggestions have been SAN's (server area networks?) or other such things. These support terabytes of data and as long as the filesystem is in an order that makes sense, jumping to projects can be automated with shell scripts.
For databases, I know that Informix has Media360. I think that Oracle might have the same. I also know that there are 3rd party apps out there, but I can't think of the name.
It looks like CNET was on target. Somebody *is* looking at the possibility. The only problem I see is the lack of seperation between the MozOffice group (person?) and Mozilla.org. But... the information and the links clear that up. People need to read the article and should look at the coments that the person submiting makes. He was off base, the title is off base and now, the/. community is freaking out.
Get the facts, report the facts and leave speculation alone.
I know that the average UI engineer is afraid to try things that are different for fear of ailienating the user. I have seen where the interface between comptetitors software were different and users customized the UI to look like the package A after moving to package B. It is so much easier to know what to expect. BUT... I have also seen where the UI is the same, but an optional 'advanced' UI exists, such as with A|W's Maya. Yeah, they have menu bars and drop boxes, but they also have hot-menus. The ability to hold down the space bar and chose with the mouse anything under the title bar menus is nice.
I think that for a new UI to be good it needs to be backwards compatible or be so easy to understand that it becomes second nature in 10 minutes. People drop programs, sometimes, not because of lack of features, but not being able to get to the features easily.
Slashdot Mirror
Yahoo given a rundown on this allready. Much more info than some (possibly made up) screen shot.
Story is here.
Looks like Gamera works on RH 6.1 and is built from the Gecko technology.
I would have to disagree with most of what you have said.
SGI going to IA32/IA64 is an obvious choice.
The MIPS is falling behind in mhz.
SGI shops feel comfortable staying with the SGI name but they will leave them if the price/performance ratio drops too much.
I agree that the SGI web servers are a joke... they are manufactured by VA, I believe, so why not buy a VA box?
I also agree with the switch to NT. But I also know that the people I work with that want the SGI NT boxes will not give them up for Octanes.
Obviously you haven't been paying attention to SGI press releases... The Origin line has gone from the 200 to the 2000 to the 3000 series, all in the last year or two. Each of them still being sold and produced. They are expanding the line.
By IA64 compatability in the 3000 line, they are allowing themselves to take advantage of a largely distributed CPU that will continue to be developed and improved.
Also... most programs that run under Linux are also ported for Irix. And... even if the Origins do run Linux on the MIPS, the code still needs to be ported for the chip, so that argument is moot.
Maya is still being developed for the SGI, so people are still developing for it. Maya is a killer app. It is why we have 50+ SGI boxes in house. I know other studios are the same.
As I have said, people buy SGI for the name. The name implies a level of quality and support. Big places spend money for products they trust.
Don't go counting out SGI yet.
In upcoming games that composite 20+ layers of textures, the cost of a blit is down in the noise.
Do you really see the game market using so many textures? Are you expecting these to be images or generated textures (generated from a series of functions)?
If this is the case, systems are going to need much wider and/or faster buses and more T-Ram on the video card. Also, I see where people are going to have to start watching texture sizes and color depths.
In my job, where we worry about texture sizes for rendering, this is always a place where we butt heads. I would love small, simple textures and the modelers want large, beautiful textures. I typicaly give in more than they do, because a sharp looking video is a sharp looking video, and the buyer doesn't care that the images took an extra 20% or so to render.
In the gaming world, though, the user wants real time... so they might not be as happy with the 20% performance hit.
Page flipping doesn't apply to windowed rendering unless you butcher the X server to render all 2D to multiple buffers and clip all 3D operations. I consider that a bad thing. Making the full screen rendering more distant from windowed rendering is also a bad thing.
This reminds me of the old hack for Mesa and the Voodoo chips. Is this the same thing? Where the full screen renders were fast but the windowed renders sucked because they were copying bits from one buffer to the other?
Most of the coments I see are gamers pondering if it is worth it yet to game on the Linux platform, even with the better benchmarks. Some seem to think that because the mAcro$oft becnhmarks are still a tad better that they should stick with the gamers OS of choice.
I come from the other end of the spectrum. I am anxiously awaiting these near similar benchmarks. Linux graphics machines are going to be a reality soon. The A|W port of Maya is going to be ready next year, the SGI Linux boxes exist, and now, the drivers seem like they will be ready for the release.
This is great news. All SGI shops now have an alternative to NT. I know that many are evaluating the choice of SGI vs. NT with the increased NT performance and the lower prices. With Linux in the mix, good things can happen.
If you look at what SGI has been doing in the last couple of months, they have been setting themselves up for this switch.
1) SGI has ported Linux to work on the Origin series of machines.
2) SGI has designed the next series of Origins to run on either IA64 or mips (with Linux support)
3) SGI has produced Linux graphics workstations with more standard hardware than the NT only boxes of a few years ago.
4) SGI has worked closely with NVidia for graphics hardware solutions
5) SGI has signed a deal with Intergraph (one of the leaders in NT graphics boxes) to sell Intergraph boxes
The first four point to Linux in the graphics world. The last one seems to either be a failsafe or.. as I see it, a chance to sell more boxes that could be dual boot graphics stations with some research.
The next year will be interesting for all places that are SGI shops.
No... no...
you got it wrong...
the first story was the "news for nerds"...
this is the "stuff that matters"
I was just thinking. I read a SIGGRAPH paper about adaptive voxels for real time fly-overs.
The idea was to swap voxels for when the objects get nearer to the camera.
A system could be used like this where voxels are used on all objects that need little detail far away and polygonal objects are swaped in when the object is near.
Just another idea from a sleep deprived soul...
Instead of knocking out the cobwebs, I will give you the links that I learned from.
bezier patches
Bezier curves
Nurbs
What it boils down to is an easy way to store a curved data set. The display part is trickier... and that is where the acceleration would be nice.
If you had a curved object, you could break it into poly's and have all the triangle points stored in memory or you can have the control points (and the weights if used) stored in memory.
Obviously the math for the poly's are faster but the display isn't as smooth (Such as Quake 2). With bezier patches, the display takes more math but is smoother because you are representing curves and not lines.
When it is all said and done, the math isn't too bad, it is just additional math that needs to be done at 30+ fps.
I don't think the moderator caught what I was saying...
People will continue to use the X86 arch because the cost of software migration is huge. Think of all the apps that are on your office machine and the servers.
Most of these are licensed and in some cases are platform specific.
For Intel to move to the next arch, it has to be backwards compatible, which tends to slow it down (or at least make it slower than a native chip at this speed).
Extending the life of the X86 is a double edged sword. It is delaying the transfer cost but it is possibly slowing down the potential of the desktop.
I for one would love to have the next arch out and running, but I would hate to have two machines... one for all of my legacy software and one for all of my new stuff.
Hmmm... takes me back to my Senior year in Surfaces and Modeling.
I think that accelerated Nurbs would be more benificial. At least nurbs are the choice of Maya... I can't remember what the other packages like.
But... accelerated Bezier patches is a step towards faster nurbs.
Not always...
With RAM being cheap and cache on chip, disk speed will only give certain gains.
The work that I do (software rendering) is as much or more CPU bound than it is I/O bound and it is all over the network from a new RAID system.
Boosts in CPU speed is big news. Compare 42 dual 600's vs 42 dual 1,400's... the difference is worth being excited about.
Also... space efficency. More power in a chip, the less boxes (in theory... we all know projects expand to use what you have) needed.
Hmm... we could stop using the X86 Arch...
Like we could all use DEC Alpha's... those are prety darn fast.
Wait... the apps aren't ported... and those that are cost money for new licenses? Whoa... maybe not such a good idea.
We are going to be stuck on the X86 as long as it is cheaper to make them run faster than it is for all of corperate america to make the binary switch to the new platform.
I have seen where some satalite companies offer such a service and the rates seem to be decent... not much more than to use a cable modem or dsl...
And the down stream rate is supposed to be good as well.
Consider this:
You are at work.
Server crashes.
Southpark is on in an hour.
A) Miss the show and save the server
B) Screw the server and catch the show
C) Save the server, record the show and watch during your comped time off
It seems that this would be usefull, just keep those script kiddies away.
I wonder if one was using Linux and the floating point emulation if they could best the onboard FPU of the chip.
Maybe this chip is a reason for people to still be making math co-processors...
Why is this question a "Is there better support than company A?" instead of "What good forms of support are there?"
Mentioning companies is bad form.
By your post, those that have never used company A now will think worse about them. You could of had an isolated incident. A new person working support. Who knows...
With that being said, I have had good experiences with VA. Parts always arrive. We did have problems getting the right rails for one of the boxes but everything else was handeled well.
Our local support has spent many hours helping install and configure software. I now have my VA render farm to where all I do is add a machine, throw in a CD and 20 minutes later, I have a new render node.
They have been more than I could have hoped for.
I, for one, love the ability to use a good gui to config a system. I am jumping between Linux, Irix and Solaris and I sometime have a mental lapse as to where things are... like... um... what config file has the services in it? ;)
Not all of them are that easy.
I use linuxconf to do a quick config of my system.
NIS info changed? Click, click... type type... restart... all better
I know what I want done. I know the theory behind it. I don't want to have to wory about a little file.
Also... mentioning NIS and DNS and all of that... it is so hard remembering about SGI's new all in one daemon. Going between that and Linux daily is enough to drive a person crazy...
I HUP'ED the ypbind... why is it not taking it...
Oh... yeah... that other daemon... nsd... yeah... HUP that mug.
I agree with the remark about most places do slow frames in a massively parallel system. We made the same choice. 40 dual 600mhz Linux boxes.
But... we also had lighting tests and renders for marketing that needed to done quicker than a nightly turn arround. That is when we used the O2000. We turned this machine into our file server, so now we can only dream of when we could render single frames faster.
In a perfect world, both systems would exist. A bunch of Linux boxes for 24x7 renders, a massively parallel box for large or quick turn arround single frames that could be used for "normal" renders 24x7.
I don't completely agree with that.
Beowulf is not good for rendering. Each job can have up to 500-700 megs of memory being used. Share this over a 100bT or Fibre or some other network protocol. It won't work.
We use other approaches for rendering. We spread the shot over a machine, not the frame. We eat the overhead of starting the renderer and reading the file. If possible, for those users who need one frame done fast, we threw it on our 4 proc O2000. That machine was taken from me, so now they just have to wait 4x's longer.
Beowulf has its uses. Production rendering is not really one of them.
I mostly agree with all of your above points. I hesitate only because Linux has a away to go to match Irix (or some other *nix OS) in some instances. SGI boxes are hanging arround as servers for a reason.
I would love to have one server OS and tune the platform to the job. But... it will be a few years before places are doing this. This port is a step in the right direction.
This is a great machine for rendering or any other application that is both CPU and memory bound.
Some jobs do not parrallel well, such as individual frame rendering. With 24 boxes, the 5 + minute overhead of loading the scene file plus the memory spent on loading the textures and the geometry would be done on each machine, costing you 24x's the overhead of doing it on one machine. Trying to do this with a "quasi" shared memory system would kill the network. But would remove that hidious overhead.
Doing this on a NUMA box fixes all of those problems. The memory is shared. The procs all look like one machine. The system runs smooth and well.
This is why SGI is still in the large graphics server environment. People want individual frames done fast.
The benifit of this being a linux box and not Irix....
I, a huge linux vs. irix advocate, strugle to see why this would be good. Most of the apps that I would use are built for Irix first and then Linux (like Maya's renderer). I can see where others might have custom apps to use this, but the code would probably port to Irix just as easily as it would to Linux on the MIPS.
It is a step in the right direction, IA64 NUMA boxes running linux. The ultimate in render farm machines.
NUMA != Beowulf
Numa is not even close to how beowulf works. NUMA allows the procs to actualy work together with shared memory instead of a near shared memory that beowulf provides.
Trust me, the cray link is much more efficient than what a fiber connection bewteen beowulf boxes would be, even if you went all out and did some sort of cube configuration.
If beowulf was better, people wouldn't be shelling the money for the SGI boxes when they need the horse power, they would have some "wulf" farm working on the problem.
There is software that does this on the DB side. The company that sells it could probably suggest a good way to store it as well.
We have looked at doing a similar thing because we produce 200 GB of images and movies every few months. Our web group and marketing group wants to get at this data later but doesn't know exatly what they want till they see it.
We are still looking at different solutions for this. Some suggestions have been SAN's (server area networks?) or other such things. These support terabytes of data and as long as the filesystem is in an order that makes sense, jumping to projects can be automated with shell scripts.
For databases, I know that Informix has Media360. I think that Oracle might have the same. I also know that there are 3rd party apps out there, but I can't think of the name.
It looks like CNET was on target. /. community is freaking out.
/.
Somebody *is* looking at the possibility.
The only problem I see is the lack of seperation between the MozOffice group (person?) and Mozilla.org.
But... the information and the links clear that up.
People need to read the article and should look at the coments that the person submiting makes. He was off base, the title is off base and now, the
Get the facts, report the facts and leave speculation alone.
In this case CNET did a *better* job than
I know that the average UI engineer is afraid to try things that are different for fear of ailienating the user. I have seen where the interface between comptetitors software were different and users customized the UI to look like the package A after moving to package B.
It is so much easier to know what to expect.
BUT...
I have also seen where the UI is the same, but an optional 'advanced' UI exists, such as with A|W's Maya.
Yeah, they have menu bars and drop boxes, but they also have hot-menus. The ability to hold down the space bar and chose with the mouse anything under the title bar menus is nice.
I think that for a new UI to be good it needs to be backwards compatible or be so easy to understand that it becomes second nature in 10 minutes. People drop programs, sometimes, not because of lack of features, but not being able to get to the features easily.
I know it sounds ugly, but I believe that you can use Javascript to set up some sort of searching in pages.
Maybe even having a flatfile with keywords to index the search...