Re: "The Special tweaks nonsense is indeed a lie":
No it's not, in fact, there are a great many "special tweaks" both in the hardware itself, and in the OpenGL software driver. For example the Linux OpenGL driver uses a (much) faster GL dispatch technique is used than available elsewhere, and many other improvements.
I like SGI. I hate the cost. If I don't serioiuse number crunching, nor do seriouse 3-D graphics, then why should I go to SGI?
The straight answer to this is that SGI makes its living by offering differentiated solutions for particular targeted markets. You seem most interested in the desktop systems so I'll defer discussion of the high-end boxes (Onyx2, etc) for now. In our desktop MIPS-based IRIX systems our differentiation primarily comes from the graphics feature set and performance, the digital media features & capabilities included with the system, the overall architecture (UMA on the O2, for example) making certain Very High Bandwidth operations possible, and from the features and bundled software set of IRIX itself.
I bear no illusions that each & every user out there has a requirement for these capabilities; but there are a significant amount who do, especially in the technical computing, MCAD/MCAE, visualization, medical imaging, post production, animation, and broadcast markets. There are many other markets served by our low-end IRIX boxes of course:-), these are just the common ones that came to mind.
A quick note about costs for development, as of IRIX 6.2 we've restructured what used to be called the "IRIS Development Option" (IDO). In a nutshell what's happened is that much of the development software that used to be available only at extra cost -- like the Inventor libraries, Motif/X/Xt libraries, Digital Media & Audio libraries, etc., are now bundled free with the OS. More specifically, all the header files & development libraries that used to be on the IDO, and a few more that were separate, are now (as of IRIX 6.2) available for free and/or bundled with IRIX; and the only extra-cost item left from IDO are the compilers themselves. But, if you don't want to buy SGI's compiler you can just use gcc.
This is now bearing towards off-topic technical details though so if you're curious feel free to contact me privately. Or hop over to another forum like comp.sys.sgi.misc
Ah I see some of the source of confusion. IRIS Performer is targeted to the real-time first-person "out-the-window" type of visualization, a common use being that of flight/mission simulation or training. These sorts of programs make full use of the SGI hardware, from I/O to CPU to the graphics subsystems, and tend to have requirements in the following order:
High Frame Rate.
Deterministic Frame Rate.
Image Quality.
Price.
Avid and SoftImage are wildly different beasts in a completely different market space -- they are used to render animations "off-line", with image quality being paramount and frame rate an absolute non-issue. They're also more geared towards the user interface (for the animator) than towards the run-time visuals (for the pilot). The finished animations go into movie F/X and TV commercials.
This is all a long-winded way of saying, whatever is going on with animation packages like Avid & Maya & SoftImage & etc. is occuring in an area totally unrelated to IRIS Performer & the Modelling, Simulation, and Imaging (MS&I) industry.
It's not a world that's had much exposure in Linux yet though (before today!:-) but with IRIS Performer being released for Linux now, other MS&I kits like MPI's Vega just having been announced as coming soon, and SGI's general impetus towards bringing its graphics firepower into the Linux space, I think we'll see a lot more in this area in the times to come.
Regarding "a shift from visualization workstations to internet servers": this isn't the case, there's been no such shift. Many of the same capabilities of our systems that make graphics work well (bandwidth, I/O, and the myriad features in IRIX) are also very well suited for servers & the internet, so we're nailing all three birds here with the same basic R&D stones.
More specifically, SGI is focusing its efforts on three business areas, which you're free to abbreviate as S, G, and I...:-)
High Performance Systems: (aka: SERVERS) Scalable, high-performance servers for HPC, technical computing, and Business Intelligence Applications.
Visual Computing Solutions (aka: GRAPHICS) Solutions for collaboration, visualization of complex data and media-rich content creation. This is where IRIS Performer and our high-end graphics systems fit in.
Broadband Systems (aka: INTERNET) Internet infrastructure products with "appliance-like" features for broadband content, applications, and services.
You're welcome to read more about this (informally) in the Friends of Performer Meeting Summary that I posted after SIGGRAPH last August. There's also quite a lot of official information about our strategy linked off the front page of www.sgi.com.
I'll have to wait until we're back in CA next week to test on a voodoo2 @ 800x600 to see what's up. But in the meantime if you're using perfly you can specify the window size on the command line -- "perfly -W800,600 file.ext"
(No idea about the mouse problem -- worked fine in our testing; it's all regular X input stuff)
As it sometimes turns out when trying to make documentation simple (and so that it ALWAYS works) some "clever exceptions" are left out figuring people who know about such things will just go do them....
So more specifically Performer doesn't actually REQUIRE Mesa, it just requires something called libGL.so.3 and libGLU.so.3 in your LD path that implements an API reasonably similar to that of OpenGL. If you have a libGL.voodoo.foo sitting around somewhere that implements an accelerated OpenGL binding for Voodoo, by all means just create some symbolic links (from libGL.so.3) to it, and force the install. That, in a similar nutshell, is how we get the accelerated TNT2 libs to work along with it too..
As to the slowness first: you're probably running your performer app with libGL.so.3 being the one from MESA, instead of using an accelerated libGL.so from your board vendor. The performer docs are pretty centered around getting up & running with Mesa (since it's available to everyone) and there isn't too much there about making use of accelerated drivers (for boards that have them) since they're all different. I truly look forward to some standardization in this area! But in the meantime if you're using a TNT2 check our FAQ as there are some instructions there. You should get around 30Hz (textured) in the Town with a TNT2.
As for demos & the magic bus.. I am posting this from the I/ITSEC tradeshow in Orlando, FL this week (a military & industry show for training & simulation systems) and not to be too shy the demos we're showing here are friggin' AWESOME. But these aren't the sort of things you can typically see on the Magic Bus -- SGI doesn't make most of the demos we show (we make the boxes they come in!) and for the grand majority of the very cool ones, we only have permission to "show" them at particular tradeshows and/or in the presence of their owners.
The "old" (and now familiar) demos that you saw were from an era when SGI did many of its own demos, so we were allowed to distribute them. Another issue now is the size of the datasets -- I'd say 90% of our "modern" demos are interesting primarily because of the size (and therefore the detail) of their datasets. As an example IRIS Performer 2.2 (on IRIX) ships with a "Yosemite Demo" on a separate CD, roughly 1GB of data if extracted. This is (obviously) far too much to distribute in a web-based package, and to make it smaller would make it unimpressive -- "what, that's the edge of the dataset?". That 1GB is texture & terrain for only a 16 sq. km area.
Those of you who went to SIGGRAPH this year might have seen a demo of an F-117 stealth bomber flying around the Tonopah Test range in Nevada -- this demo is indicative of the capabilities today and is (honestly) far beyond the sort of fruity VRML & arcade-quality nonsense that gets shown in the Magic Bus. In this particular one the data from a 400x400 kilometer region in nevada -- that's 160,000 square kilometers -- in taken from satellite data & with texture sampled at varying resolutions, down to 0.5 meters per texel in the area right around the firing/target range. The simulation dynamics of the stealth bomber are recorded from actual missions. The texture, terrain, and cultural features (fancy term for trees & buildings) are paged into memory in real time by IRIS Performer, hundreds of megabytes per second flowing around in the system; the whole thing runs at a rock-solid 60Hz, which means you're golden in the world of vis-sim.
Here at I/ITSEC this week we're showing a few similar demos (but here the dataset spans ALL OF SPAIN) and a bunch of show-specific stuff like the DART. So I guess the best answer available for those of you seeking incredible demos is to come see us at a show, or visit one of the SGI RealityCenter facilities -- it's too hard to lug these big disk arrays around otherwise.:-)
I recognize that you're just venting but the implication is far off from the mark. SGI has quite a number of new workstations, new servers, new CPUs, and new graphics in the works and not very far off at all, with IRIX driving the MIPS-based systems and Linux for the future Intel-based systems. IRIS Performer is a big part of that, a segment of our strategy is to focus on the "hot spots" in the marketplace where SGI commands an advantage, and SGI & IRIS Performer are the undisputed kings of vis-sim with far more revenue & marketshare than any other vendor. SGI has had a lot of problems recently but vis-sim has always been home turf, and one that we have no problem defending competitively.
I can only agree that the term "databases" is an overloaded one. In the context of IRIS Performer it refers to the data structure (in memory, a file, whatever) containing the geometry and visual state [texture, material, lighting, etc] of the scene to be viewed. In many cases the "database" refers to the in-a-file version of that data, and the "scene graph" refers to the in-memory representation. Most data of this type is created using sophisticated 3D modelling tools such as MultiGen, Maya, etc., or is gathered from sensors and/or satellites. IRIS Performer's job is to render it all REALLY FAST. Sorry that the 'screenshots' area is sooooo out of date, most of those images date back from the first versions of Performer circa 1992. There's some much better stuff now:-) for example see one of our partners http://www.aechelon.com
The 2.2 vs 2.3 naming decision was one of simple convenience -- we needed to be able to split our Linux development off from the "baseline" 2.2 versions so as to avoid the approval processes required (since changes to the 2.2.x versions go directly into IRIX, with certain deadlines & procedures). By creating a new development tree ("2.3") we were able to go willy-nilly on the code. Rest assured, changes we make to 2.2.x are (automatically) brought into 2.3 as well. We considered just naming the Linux version "2.2" also but that would have confused _us_.:-) Glad that you found the various documentation & requirements pages useful. If you have any suggestions for improvement feel free to contact me.
Please give it a shot and let us know (mongoose-feedback@corp.sgi.com). I don't recall from our internal testing whether anyone had a Voodoo3. You should be OK with fewer colors.
The message itself is harmless, all apps running with this beta will see it.
What it is: During initialization, Performer queries the GL to determine what kind of system it's running on, what GL version it's using, etc. This data (along with the list of OpenGL & GLX extensions, which are also queried) is used to enable/disable certain modes by default. For example on an SGI Onyx2 InfiniteReality system, anti-aliasing is enabled by default, texture (and certain advanced texture modes) is enabled by default, etc. On Linux systems the modes available are more limited but the same idea holds.
The mechanics of doing this are by opening a "no-port" (windowless) window for the query stuff, doing the queries, then dumping the no-port window and opening a real window for the rest of the program. Well, we discovered that Linux systems (or at least Mesa, and a few other OpenGL implementations) don't handle no-port windows well -- they freak out and dump core. So we changed the technique used, in Linux we open a real window for the queries and keep that window open for the lifetime of the app. This isn't clean, so we left the debug warning in there to remind us to go do something more clever later:-)
Yep, we (ok, I) broke this just before the final images were built while fixing a different problem and didn't want to risk an untested but more comprehensive combined fix so close to our Beta deadline. [It's noted in the bug list]
This is a problem that will be resolved for our next Beta. Thanks for checking it out.
The gettimeofday() warning itself is harmless (happens for all apps with this Beta), it it printed and then the program continues onward, most likely the segmentation fault is happening when the window is being opened. The best thing to do is:
% setenv PFNFYLEVEL 7 % perfly rocket_tux.pfb
And then send us the output at mongoose-feedback@corp.sgi.com
I think the simplest way to see that SGI isn't just "testing the waters" is to just look around at all the various Linux-related activities happening with SGI. It's plain as day, we've already jumped into the pool. I don't have any fear about Performer for Linux not being finalized into a finished product, and certainly don't think you can lump SGI's committment to Linux in with the likes of Microsoft, of all things! We named this project 'Mongoose' for a reason you know.
SGI has a vested interest in seeing Linux grow (we'd like to grow along with it) and we will continue to create and contribute things we think the community will find valuable to help make it into the premier UNIX-like OS. That, along with SGI's long heritage in high-end graphics, is going to bring many good things to the Linux world.
IRIS Performer has been enjoyed tremendous success for many years as an IRIX-only product and this port (and the long roadmap of combined IRIX/Linux releases) helps to bring SGI graphics API expertise to the wider audiences here. This beta release is just what it seems: a beta; to get the bugs fixed in time for the final release.
Not that you act like the kind of customer we'd like to have, but...
If you look at our download page you'll see that we ship both.rpm files (intended for Red Hat 6.0, which is what we use) and also plain old '.tgz' (gzip'd tar) files for Linuxes which don't support rpm's. Sounds like the best support for all worlds to me.
Allright, our first 'it sucks', surprised it took so long. Apparently you overlooked the list of known bugs. Mouse/keybd input is not tuned for linux yet, so such input suffers from very high latency. This is something that will be fixed in the next Beta.
We've found performance to be very reasonable. Of course on SGI systems it screams:-).. On systems without linux-ready hardware accelerated OpenGL, Mesa is used as the low-level OpenGL-like rendering layer. The Performer Town database (the most typical Performer demo) runs untextured at about 5-10Hz depending on the CPU. On systems with Linux-based hardware accelerated OpenGL drivers we see 20-30Hz in the town, WITH texture. This is a BETA version also, it's not even compiled optimized or fully tuned, so we expect to see some pretty excellent performance by the time the final release is ready.
Slashdot Mirror
No it's not, in fact, there are a great many "special tweaks" both in the hardware itself, and in the OpenGL software driver. For example the Linux OpenGL driver uses a (much) faster GL dispatch technique is used than available elsewhere, and many other improvements.
The hardware is enhanced as well.
I bear no illusions that each & every user out there has a requirement for these capabilities; but there are a significant amount who do, especially in the technical computing, MCAD/MCAE, visualization, medical imaging, post production, animation, and broadcast markets. There are many other markets served by our low-end IRIX boxes of course :-), these are just the common ones that came to mind.
A quick note about costs for development, as of IRIX 6.2 we've restructured what used to be called the "IRIS Development Option" (IDO). In a nutshell what's happened is that much of the development software that used to be available only at extra cost -- like the Inventor libraries, Motif/X/Xt libraries, Digital Media & Audio libraries, etc., are now bundled free with the OS. More specifically, all the header files & development libraries that used to be on the IDO, and a few more that were separate, are now (as of IRIX 6.2) available for free and/or bundled with IRIX; and the only extra-cost item left from IDO are the compilers themselves. But, if you don't want to buy SGI's compiler you can just use gcc.
This is now bearing towards off-topic technical details though so if you're curious feel free to contact me privately. Or hop over to another forum like comp.sys.sgi.misc
Avid and SoftImage are wildly different beasts in a completely different market space -- they are used to render animations "off-line", with image quality being paramount and frame rate an absolute non-issue. They're also more geared towards the user interface (for the animator) than towards the run-time visuals (for the pilot). The finished animations go into movie F/X and TV commercials.
This is all a long-winded way of saying, whatever is going on with animation packages like Avid & Maya & SoftImage & etc. is occuring in an area totally unrelated to IRIS Performer & the Modelling, Simulation, and Imaging (MS&I) industry.
It's not a world that's had much exposure in Linux yet though (before today! :-) but with IRIS Performer being released for Linux now, other MS&I kits like MPI's Vega just having been announced as coming soon, and SGI's general impetus towards bringing its graphics firepower into the Linux space, I think we'll see a lot more in this area in the times to come.
Regarding "a shift from visualization workstations to internet servers": this isn't the case, there's been no such shift. Many of the same capabilities of our systems that make graphics work well (bandwidth, I/O, and the myriad features in IRIX) are also very well suited for servers & the internet, so we're nailing all three birds here with the same basic R&D stones.
More specifically, SGI is focusing its efforts on three business areas, which you're free to abbreviate as S, G, and I ... :-)
- High Performance Systems: (aka: SERVERS)
- Visual Computing Solutions (aka: GRAPHICS)
- Broadband Systems (aka: INTERNET)
You're welcome to read more about this (informally) in the Friends of Performer Meeting Summary that I posted after SIGGRAPH last August. There's also quite a lot of official information about our strategy linked off the front page of www.sgi.com.Scalable, high-performance servers for HPC, technical computing, and Business Intelligence Applications.
Solutions for collaboration, visualization of complex data and media-rich content creation. This is where IRIS Performer and our high-end graphics systems fit in.
Internet infrastructure products with "appliance-like" features for broadband content, applications, and services.
(No idea about the mouse problem -- worked fine in our testing; it's all regular X input stuff)
As it sometimes turns out when trying to make documentation simple (and so that it ALWAYS works) some "clever exceptions" are left out figuring people who know about such things will just go do them....
So more specifically Performer doesn't actually REQUIRE Mesa, it just requires something called libGL.so.3 and libGLU.so.3 in your LD path that implements an API reasonably similar to that of OpenGL. If you have a libGL.voodoo.foo sitting around somewhere that implements an accelerated OpenGL binding for Voodoo, by all means just create some symbolic links (from libGL.so.3) to it, and force the install. That, in a similar nutshell, is how we get the accelerated TNT2 libs to work along with it too..
Far as I know 800x600 should be fine, I'll correct that. What we should _really_ say there is that we require at least 16-bit color depth.
As for demos & the magic bus.. I am posting this from the I/ITSEC tradeshow in Orlando, FL this week (a military & industry show for training & simulation systems) and not to be too shy the demos we're showing here are friggin' AWESOME. But these aren't the sort of things you can typically see on the Magic Bus -- SGI doesn't make most of the demos we show (we make the boxes they come in!) and for the grand majority of the very cool ones, we only have permission to "show" them at particular tradeshows and/or in the presence of their owners.
The "old" (and now familiar) demos that you saw were from an era when SGI did many of its own demos, so we were allowed to distribute them. Another issue now is the size of the datasets -- I'd say 90% of our "modern" demos are interesting primarily because of the size (and therefore the detail) of their datasets. As an example IRIS Performer 2.2 (on IRIX) ships with a "Yosemite Demo" on a separate CD, roughly 1GB of data if extracted. This is (obviously) far too much to distribute in a web-based package, and to make it smaller would make it unimpressive -- "what, that's the edge of the dataset?". That 1GB is texture & terrain for only a 16 sq. km area.
Those of you who went to SIGGRAPH this year might have seen a demo of an F-117 stealth bomber flying around the Tonopah Test range in Nevada -- this demo is indicative of the capabilities today and is (honestly) far beyond the sort of fruity VRML & arcade-quality nonsense that gets shown in the Magic Bus. In this particular one the data from a 400x400 kilometer region in nevada -- that's 160,000 square kilometers -- in taken from satellite data & with texture sampled at varying resolutions, down to 0.5 meters per texel in the area right around the firing/target range. The simulation dynamics of the stealth bomber are recorded from actual missions. The texture, terrain, and cultural features (fancy term for trees & buildings) are paged into memory in real time by IRIS Performer, hundreds of megabytes per second flowing around in the system; the whole thing runs at a rock-solid 60Hz, which means you're golden in the world of vis-sim.
Here at I/ITSEC this week we're showing a few similar demos (but here the dataset spans ALL OF SPAIN) and a bunch of show-specific stuff like the DART. So I guess the best answer available for those of you seeking incredible demos is to come see us at a show, or visit one of the SGI RealityCenter facilities -- it's too hard to lug these big disk arrays around otherwise. :-)
I recognize that you're just venting but the implication is far off from the mark. SGI has quite a number of new workstations, new servers, new CPUs, and new graphics in the works and not very far off at all, with IRIX driving the MIPS-based systems and Linux for the future Intel-based systems. IRIS Performer is a big part of that, a segment of our strategy is to focus on the "hot spots" in the marketplace where SGI commands an advantage, and SGI & IRIS Performer are the undisputed kings of vis-sim with far more revenue & marketshare than any other vendor. SGI has had a lot of problems recently but vis-sim has always been home turf, and one that we have no problem defending competitively.
I can only agree that the term "databases" is an overloaded one. In the context of IRIS Performer it refers to the data structure (in memory, a file, whatever) containing the geometry and visual state [texture, material, lighting, etc] of the scene to be viewed. In many cases the "database" refers to the in-a-file version of that data, and the "scene graph" refers to the in-memory representation. Most data of this type is created using sophisticated 3D modelling tools such as MultiGen, Maya, etc., or is gathered from sensors and/or satellites. IRIS Performer's job is to render it all REALLY FAST. Sorry that the 'screenshots' area is sooooo out of date, most of those images date back from the first versions of Performer circa 1992. There's some much better stuff now :-) for example see one of our partners http://www.aechelon.com
The 2.2 vs 2.3 naming decision was one of simple convenience -- we needed to be able to split our Linux development off from the "baseline" 2.2 versions so as to avoid the approval processes required (since changes to the 2.2.x versions go directly into IRIX, with certain deadlines & procedures). By creating a new development tree ("2.3") we were able to go willy-nilly on the code. Rest assured, changes we make to 2.2.x are (automatically) brought into 2.3 as well. We considered just naming the Linux version "2.2" also but that would have confused _us_. :-) Glad that you found the various documentation & requirements pages useful. If you have any suggestions for improvement feel free to contact me.
Please give it a shot and let us know (mongoose-feedback@corp.sgi.com). I don't recall from our internal testing whether anyone had a Voodoo3. You should be OK with fewer colors.
The message itself is harmless, all apps running with this beta will see it.
What it is: During initialization, Performer queries the GL to determine what kind of system it's running on, what GL version it's using, etc. This data (along with the list of OpenGL & GLX extensions, which are also queried) is used to enable/disable certain modes by default. For example on an SGI Onyx2 InfiniteReality system, anti-aliasing is enabled by default, texture (and certain advanced texture modes) is enabled by default, etc. On Linux systems the modes available are more limited but the same idea holds.
The mechanics of doing this are by opening a "no-port" (windowless) window for the query stuff, doing the queries, then dumping the no-port window and opening a real window for the rest of the program. Well, we discovered that Linux systems (or at least Mesa, and a few other OpenGL implementations) don't handle no-port windows well -- they freak out and dump core. So we changed the technique used, in Linux we open a real window for the queries and keep that window open for the lifetime of the app. This isn't clean, so we left the debug warning in there to remind us to go do something more clever later :-)
Yep, we (ok, I) broke this just before the final images were built while fixing a different problem and didn't want to risk an untested but more comprehensive combined fix so close to our Beta deadline. [It's noted in the bug list]
This is a problem that will be resolved for our next Beta. Thanks for checking it out.
% setenv PFNFYLEVEL 7
% perfly rocket_tux.pfb
And then send us the output at mongoose-feedback@corp.sgi.com
SGI has a vested interest in seeing Linux grow (we'd like to grow along with it) and we will continue to create and contribute things we think the community will find valuable to help make it into the premier UNIX-like OS. That, along with SGI's long heritage in high-end graphics, is going to bring many good things to the Linux world.
IRIS Performer has been enjoyed tremendous success for many years as an IRIX-only product and this port (and the long roadmap of combined IRIX/Linux releases) helps to bring SGI graphics API expertise to the wider audiences here. This beta release is just what it seems: a beta; to get the bugs fixed in time for the final release.
Not that you act like the kind of customer
.rpm files (intended for
we'd like to have, but...
If you look at our download page you'll see
that we ship both
Red Hat 6.0, which is what we use) and also
plain old '.tgz' (gzip'd tar) files for Linuxes
which don't support rpm's. Sounds like the
best support for all worlds to me.
Allright, our first 'it sucks', surprised it took so long. Apparently you overlooked the list of known bugs. Mouse/keybd input is not tuned for linux yet, so such input suffers from very high latency. This is something that will be fixed in the next Beta.
We've found performance to be very reasonable. Of course on SGI systems it screams :-) .. On systems without linux-ready hardware accelerated OpenGL, Mesa is used as the low-level OpenGL-like rendering layer. The Performer Town database (the most typical Performer demo) runs untextured at about 5-10Hz depending on the CPU. On systems with Linux-based hardware accelerated OpenGL drivers we see 20-30Hz in the town, WITH texture. This is a BETA version also, it's not even compiled optimized or fully tuned, so we expect to see some pretty excellent performance by the time the final release is ready.