Dave Pape (pape++at++evl.uic.edu)
Mon, 9 Mar 1998 16:55:27 -0600 (CST)
> Are you forking your draw processes?
>
> You need to.
>
> Also you should make sure you genlock the pipes.
Yes, there are multiple draw processes; I included pid's with my
timestamps to verify this, and each pipe was different. And, yes, we
always genlock the pipes, because we're running stereo and need them all
in synch.
I just ran another test, with a different X configuration, and believe
I've figured out roughly what's going on. If I'm right, it's a definite
(and annoying) bug in Performer.
My test this time was in a two-keyboard mode - the IRs were configured
as :0.0, :0.1, :1.0, and :1.1. The drawing timestamps show that the
processing of a single frame runs something like this:
:0.0 (process id 3012) and :0.1 (pid 3016) start in parallel
as soon as :0.1 finishes, :1.1 (pid 3018) starts
as soon as :0.0 finishes, :1.0 (pid 3014) starts
The order isn't always the same, but what _is_ consistent is that the
processes for :0.0 and :1.0 are serialized, and those for :0.1 and :1.1
are serialized.
So, my theory is that Performer is trying to serialize different pfPipes
which use the same graphics pipe; perfectly reasonable, to avoid lots of
context switching. *But*, it's deciding whether they share a graphics
pipe based solely on the screen number, rather than looking at the whole
display information. If this really is the case, then is there anything
we can do to get around it, or will we have to wait for a patch?
-Dave
---------------------------------------------------------------------------
Dave Pape Electronic Visualization Laboratory, UIC
pape++at++evl.uic.edu http://www.evl.uic.edu/pape/
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:00 PDT