doelz@urz.unibas.ch (08/20/90)
In article <1990Aug17.232808.9319@odin.corp.sgi.com>, kurt@cashew.asd.sgi.com (Kurt Akeley) writes: > In article <9008020229.AA22321@chem.chem.ucsd.edu>, sdempsey@UCSD.EDU > (Steve Dempsey) writes: > |> system: 4D/340VGX > |> OS: IRIX 3.3 ours is a 4D/120 GTX running 3.3 > |> > |> 1. Will this bug be fixed in the real 3.3 (3.3.1) IRIX release that's > |> supposed to arrive any day now? > > Yes! This bug is corrected in the 3.3.1 release. > > |> > |> 2. Is it known when it's 'safe' to call setmonitor on VGX machines? > > While running 3.3.0 it is safe only when no other program is actually doing > graphics. Since this is hard to insure, it really is never safe. > Our SGI people here try to make stereoView run on a 120 running 3.3. Does this posting mean that StereoView doesn't run on 3.3 ? Rgds Reinhard
bam@sgi.com (Brian McClendon) (08/20/90)
In article <1990Aug19.191628.906@urz.unibas.ch> doelz@urz.unibas.ch writes: > > >Our SGI people here try to make stereoView run on a 120[GTX] running 3.3. >Does this posting mean that StereoView doesn't run on 3.3 ? > >Rgds >Reinhard The only _known_ problem with setmonitor(3g)/setmon(1) is the previously discussed problem on the VGX. There should be no problems with 3.3 in general or on 120GTX's in particular. BTW, the VGX problem was discovered in the last day(s?) of the 3.3 cycle. It was thought to be a rare occurence with a relatively simple work-around. Basically the part of the pipe responsible for configuring video would spend 3-5 seconds downloading the video format into the hardware _and_ writing it to EEPROM (the actual time-consumer). If other GL programs tried to access the video hardware (ie: swapuffers(), mapcolor()...) they would block the pipe and it would timeout after ~2.5 seconds. The solution is obvious and will be in 3.3.1. Finally, I would like to point out that there _should_ be no sequence of GL calls that crashes the pipe and takes down the news_server. This is SGI policy. If you know of such a sequence please report it to the Hotline. The best we can do is fix it ASAP and get it out in the next maintenance release; the worst would be for us to find it to be unfixable (without impacting performance) and include it prominently in the release notes and/or man pages. Either way should save the rest of us from chasing the same bug again. -- ---------------------------------------------------------------------------- Brian McClendon bam@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110 -----------------------------------------------------------------------------