Re: >Remote .vs Local IRIS P

New Message Reply Date view Thread view Subject view Author view

Marcus (Marcus++at++multigenuunet.uu.net)
Fri, 29 Apr 1994 11:23:10 PST


        Reply to: RE>>Remote .vs Local IRIS Pe
Hi Michael,

Michael Jones wrote:

>Lew sent the following note and then asked me to send it out
>to the info-performer mailing list. How common is this type
>of situation? Comments?
>
>On Apr 29, 7:45am, Lew Hitchner wrote:
>> Subject: Re: Remote .vs Local IRIS Performer graphics

<stuff deleted>

>:In environments where there's one
>:"big" machine (e.g., 4 or 8 CPU Onyx) and many networked "small"
>:machines (e.g., Indigos), developers usually develop and test on the
>:small machines (single CPU) on their desktop. But, you also need to
>:check out your latest development on the "big machine" with its OS,
>:multi-CPU, and graphics hardware environment. But, in large
>:organizations the console of "big machine" may not always be available
>:on demand for every developer whenever he or she wants to test their
>:latest "enhancement".

This is similar to my development environment at MultiGen Inc.. I do alot
of the OpenFlight loader development and initial testing on an Indigo. Our
ONYX RE and Crimson RE machines are typically reserved for customer training
and in-house demos. For features, such as detail textures, that require a
Reality Engine, I schedule development time on one of these machines.
During this time, I "move to another seat". Remote display would be
convenient for many things, but this brings up a question. I would want
the remote ONYX to display detail textures (or other RE features) on my
local Indigo display. How would this be done? Perhaps OpenGL would support
this? There are situations when you have to be testing Performer software
solely on the target platform.

Regards,
Mark Barnes
Member Technical Staff
multigen!marcus++at++uunet.UU.NET
MultiGen Inc.
(408) 247 4326


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:15 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.