Re: Multiple op's on a simgle rm machin

New Message Reply Date view Thread view Subject view Author view

Allan Schaffer (aschaffe++at++shark.paris.sgi.com)
Thu, 2 Mar 1995 19:54:36 +0100

On Mar 2, 5:53pm, Richard Gallery wrote:
>
> I have a VTX (1 rm) Onyx, with 4 R4400's. I am using an MCO
> to display multiple (4) views. My question is, should I have
> a single pipe, and render each channel through the same pipe,
> or should I have, say 2 pipes (software) and render half
> through one and half through the other. The reason I am
> asking is, I realise that having two software pipes on a
> single hardware pipe machine is in-efficient, but, as I have
> spare cpu's, I could have two draw and two cull processes (if
> I configured it as, say two pipes). Has anyone else tried this?
> I could experiment myself but I am sure someone already knows what
> would be best here.

Even though some CPUs may be sitting idle I suggest that you should
choose the 1-pipe multiple-channels option.

In short -- real-time performance can only be guaranteed if you have
one window rendering per pipe.

(much) Longer..

Each pfPipe corresponds to a GL window, which internally contain a
lot of state information that is tracked by the graphics hardware.
Things like the matrix stack, current texture, lighting model, and so
on.

If you were to have more than 1 pfPipe rendering to the same hardware
pipeline, the (hardware) graphics pipe would have to switch back &
forth between each GL window's context several hundred times per
second. This is horribly inefficient, AND more importantly there's
no way to guarantee real-time performance when this activity is going
on.

This is why the Performer FAQ recommends that it is necessary to kill
or block any other graphics processes while you are running your
performer application. If they wake up and draw something, the
graphics pipe will tell your program to block while all the necessary
context switching occurs & the other program is taken care of.

Note this happens even if your application is locked down to a
particular processor -- the graphics pipeline is the ultimate
arbiter, so to speak.

Allan

-- 
Allan Schaffer
Silicon Graphics
aschaffe++at++sgi.com
http://reality.sgi.com/employees/aschaffe

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:51:02 PDT

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