Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Silicon Graphics

Beta for IRIS Performer 62

A couple months ago, SGI announced that they would be porting IRIS Performer to Linux. Thanks to Allan Schaffer for pointing us over to the first beta version that's ready for the public.
This discussion has been archived. No new comments can be posted.

Beta for IRIS Performer

Comments Filter:
  • The "Using gettimeofday() clock" message is normal. The segfault is not. The next thing Performer tries to do is determine if any GLX extensions are present via glXQueryExtensionsString(). If you're using a hardware accelerated driver and if your GLX module isn't loaded into your Xserver, glXQueryExtensionsString() may dump core (depends on your driver). Check to see if it is loaded: xdpyinfo | grep GLX
    If that is not the root of your problem, or you're using an unaccelerated version of Mesa, I recommend submitting the problem along with a stack trace to mongoose-feedback@corp.sgi.com thanks
  • Agreed. This software would abosolutley SCREAM on Alphas but there's that 32 --> 64 bit issue. Again if it was open sourced in some way simlilar to the license mozilla uses (for example , I'm not a lawyer). Then gentelmen like myself would eagerly go to work on it.
  • "Mongoose"? That would explain that guy posting as Rikkitikki... :)

  • "'Linux' is not a hardware specific term". Agreed. We will try to be more specific about what processor type we release products for in the future. If you have a request for a processor type other then x86, I recommend sending the request to mongoose-feedback@corp.sgi.com
    thanks
  • That crap new SGI logo has to GO.

  • perfly tux.pfb
    perfly tux_sit.pfb
    perfly tux.perfly
  • Hardly evil. The formerly flightless penguin is getting a boost from our favorite scene graph API :) If you have a good eye, you might spot him flying around town :)
  • I can't find any info anywhere about the future price of the release version for Linux. Will it too be free? Note, I don't feel everything for Linux should be free (and really don't expect it to be free), I am just curious.

    BTW, I think it is great that someone from SGI is actively following this discussion and commenting when necessary. While I don't agree with SGI's recent business decisions in general, I do appreciate their stance and activity on Linux.

    Derry Bryson
  • Pricing for the 1.0 release of Performer on Linux has not been decided yet. Therefore you will have a hard time finding pricing info on it :). The scheduled release date is November 22nd. We will definately have an answer to this question before then :).
  • by Allan_Schaffer ( 69923 ) on Monday September 20, 1999 @08:04AM (#1671384) Homepage
    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.
  • Unfortunately it locks up the X server here with the GLX module loaded for my G200 card (http://glx.on.openprojects.net/ [openprojects.net]). Any have better luck? perfly is trying to draw in the root window. -adnans
  • Um, but it is of interest to SGI people.

    In the past, SGI has treated GL and products based on it like the Crown Jewels. The fact that, not only do they talk the talk, but they walk the walk in supporting Linux for such strategic products speaks volumes about SGI's strategy and its intent to follow through on that strategy.

  • heh. im probably biased since i work on an O2 cluster all day long and have access to a 192 processor O2000. good job guys.
  • by heroine ( 1220 ) on Monday September 20, 1999 @08:54AM (#1671388) Homepage
    Notice how companies like SGI, Real, and Microsoft give out betas of their software to test the Linux waters but never release a final version. The problem with using betas to test the waters is that no-one wants to download a beta when they're expecting a final version to come out later. The company sees no interest and either drops the project after the first beta or renames the beta as the final version and then drops it. It happened with RealPlayer, Netshow, and IE4.
  • It actually runs quite well. I have a dual Pentium II 350, and a G200 with GLX running. Unfortunately it seems to run on only one processor at the moment, but still does pretty well, even in the town scene, which is a fairly large landscape. Things get a little jerky in the center of town when I have textures turned on, but around the country side, it performs as well as it did when I ran it on an SGI about a year and a half ago (I'm not sure what that system was, probably an Indigo2 or Indy). Way to go SGI! I can't wait to see later versions with better optimization, and hopefully dual processor support.
  • I've had much better luck with it on the G200 with GLX. It runs fairly well, though occassionally lags a little. Also, the textures aren't absolutely perfect, but it's real good for an early beta. See my earlier post [slashdot.org].
  • by Anonymous Coward
    It also used for location based entertainment (like Disney Quest). Yes, it's suitable for games.
  • by Allan_Schaffer ( 69923 ) on Monday September 20, 1999 @09:01AM (#1671398) Homepage
    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.
  • by Dr. Tom ( 23206 ) <tomh@nih.gov> on Monday September 20, 1999 @11:50AM (#1671400) Homepage
    Is it just me, or do other people find it highly annoying that something released for "Linux" is only available for x86 systems? "Linux" is not a hardware specific term. In my opinion, if you say it "runs under Linux" then it should be 1) source code (which SGI's thing is not) or 2) available for ALL architectures that Linux supports (e.g. Alpha, PPC, etc.).

  • Okay, it looks like a local GLX problem. Someone from SGI has emailed me requesting more info, mucho cool! It now starts up but crashes as soon as I turn on textures. Hacking on it some more now...thx

    Go SGI!

  • The web site says this thing requires 65k colors.
    Does anyone know if this rules out using acceleration under a Voodoo 3 ?

  • im getting a segfault as well and ran
    perfly with the pfnfylevel at 7.

    what does:
    Linux: Noport windows not supported
    mean?

    thanx.
  • Well, I am using a self-compiled Mesa 3.1 with
    glide support. But there's no GLX for that yet. Is it possible to just put this fullscreen?
  • Anyone getting this problem? No such prob at work, both there and here rh6.0...

    goshen.hall(4)> perfly
    PF Warning(2): Using gettimeofday() clock
    Segmentation fault (core dumped)
    goshen.hall(5)>
  • Re: Noport windows not supported

    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 :-)

  • Re: Voodoo3

    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.

  • Great, then I guess I'll wait till then to see if I want to look at it. Doesn't make much sense to waste time on it until then.
  • by Anonymous Coward
    I love the fact that SGI is porting software to Linux. That might not directly help them, but it should indirectly help their sales. Now, I can prototype under Performer, show it to the boss, and if he likes it, then buy a nice SGI machine to make the prototype run faster. Just asking for $$$ to buy an SGI machine doesn't work in most companies. Demonstrating an application, and then explaining how it will run faster or better with an SGI just might.
  • Would Performer be suitable for a game engine? I'm developing Free Trek (freetrek.linuxgames.com) using OpenGL.

    Can someone comment on the similarities between Performer and OpenGL? How difficult would a conversion be? How are 3D accelerators supported? Thanks.
  • Funny, I thought it was a program, not a SDK.

    My bad.
  • by Pilchie ( 869 ) on Monday September 20, 1999 @06:18AM (#1671420) Homepage
    A year or so ago I had a chance to work with Performer on an SGI Onyx II, while working on a simulator for a co-op placement. It is a really nice class library, and simplifies OpenGL to a level where even a novice can write (good) code for it. I am really happy to hear that it is moving out to Linux. That should make Linux boxes even more possible as simulation engines. Anyway good news! (First?)
    >~~~~~~~~~~~~~~~~
  • Give Alien a try: http://kitenet.net/programs/alien/ It failed on two of the three RPMs when I tried it. If you get it to work on all three, lemme know.
  • by Pascal Q. Porcupine ( 4467 ) on Monday September 20, 1999 @07:18AM (#1671422) Homepage
    Performer is a high-level interface on top of OpenGL. It's like the difference between using the C++ STL vector template and hand-realloc()ing your data as needed. It has its own set of problems and frustrations and its own additional bunch of overhead, but in general it's easier to get something working decently and almost as fast as rolling it yourself.

    Performer would, in fact, be great for a game engine; in fact, it's used for realtime military simulations all the time, and that's about as close to a game as you can get in the SGI-based professional graphics world. :)
    ---
    "'Is not a quine' is not a quine" is a quine.

  • So far, I'd been disappointed by 3D graphics libraries available for Linux. What was out there was generally PHIGS-like-a-looks or incomplete clones of Inventor.

    I'm no big fan of Performer, but this shows promise - Linux may yet be the platform that makes 3D user interfaces wide-spread.

  • by Allan_Schaffer ( 69923 ) on Monday September 20, 1999 @07:24AM (#1671424) Homepage
    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.
  • Look at how SGI has transform our cute little penguin into:

    http://reality.sgi.com/performer/images/rocket_t ux.jpg
  • Performer literally CRAWLS on my p2-333 box. Man..its *really* sloow. The animations show up ok, but after that it doesnt take mouse clicks..it just sits there and after 10 mins or so it will show a click..note that im not running accelerated. BTW, the install was painless (RPMS for redhat 6..no problem), the animations look great (i tried espirit and rocket tux..very cool).It sucks unless you have an accelerated card..dont even try for anything less than a TNT2...its just not usable.
  • I've heard of two people running it on their G200. (one in Orlando and one in England i believe) Can you specify more info than, "it just locks up"? Also, I would recommend forwarding on the problem to mongoose-feedback@corp.sgi.com thanks
  • 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

  • So the TNT2 is a fully *hardware* implemented OpenGL right? Has anyone messed w\ the performance gains of using this card in comparision to either Mesa or a garden variety SGI?

    As an aside, I was (replaying) some of my old games in parallel on the DOS/Windows side, particularly doom and x-mame. Doom's responsiveness doesn't seem so bad but the performance loss of x-mame in comparision to the DOS version is really horrendous. Enough so that I thought about comparing the two versions and seeing if the windows version (it is much slicker, supports MMX accel and much other cool stuff like menus for games etc) could be ported back to linux (using qt widget set). So my question is, is the problem X (i.e. if i had a card that implemented X 'properly' as I assume the windows driver is properly optimized) or the software (X-Mame)? Incidentally, I am running a SiS6326 Card which until recently had a kind of buggy X server, but am running X-3.3.4. (all on a amd-k2 350/64 megs ram)

  • You must mean that new GForce 256 Nvidia, or whatever it is called. TNT2 is just a faster version of the TNT I have in my system. The 256 does lighting and transformations on its own hardware. This is what $2000+ graphics cards do. They probably do it a lot better, or do more to cast that much.

    NOTE: I know dick about professional 3D, and a little more on home stuff.
  • 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.

  • "Mongooses are famous for their snake-fighting ability, and are almost always victorious because of their speed, agility, and timing and also because of their thick coat."
  • Re: fill performance meter

    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.

To be is to program.

Working...