Re: [info-performer] Multipipe Initialization

Date view	Thread view	Subject view	Author view

From: Rick van Haasen (rick.van.haasen++at++philips.com)
Date: 10/06/2005 03:00:36

Next message: jan p. springer: "Re: [info-performer] Multipipe Initialization"
Previous message: Christopher D. Johnson: "Re: [info-performer] Multipipe Initialization"

Concepts like pfPipe, pfPipeWindow, pfWindow and their relations can
indeed be confusing. After having read the chapters x times, i think to
know their meaning and relations. Maybe my short description can be of
help to others strugling with the concepts,
please correct me if you think the description is not correct.

what is a pfPipe?

a pfPipe represents a "software rendering pipeline". This software
pipeline represents the way the APP, CULL and DRAW stages are configured
(for example by specifying that all stages should be implemented on
separate CPU's or just on 1 CPU). When a pfPipe is created, It is NOT
associated with any specific "hardware pipeline" yet. That association has
to be done by "connecting" the pfPipe with a "screen".

What is a "screen" ?

a screen "represents a framebuffer and all its capabilities". The "screen"
has un unambiguous meaning, it represents "a screen as seen by the
x-server (on Unix-like systems)". The configuration of the screen (like
the "total" resolution and how the framebuffer is mapped to the available
video-outputs) can be done with system-specific tools. SGI uses
"ircombine". On Linux with nvidia graphics, these settings have to be done
through settings of the x11.config file, twinview is used to map the
screen onto 2 video-outputs. It also uses enviroment-variables (eg for
synchronisation of the vsync to the glSwap).

What is the relevance of the pfPipe <-> screen asociation?
The "screen" which the pfPipe will use must be determined somehow. There
are several situations:

1- Application is started from an x-connection on the server that manages
all screens that you want to use.

In this situation a function "pfGetNrScreens()" returnes all screens
available on the system.
For our hardware it means the 2 screens are available. As such, 2 pfPipes
can be created and associated with the 2 screens:

pfPipeScreen(pipe0,0);
pfPipeScreen(pipe1,1);

2- Application is started from an x-connection on the server that manages
NOT all screens:

This is the case when our system is configured with 2 x-servers (each
managing 1 screen). In this situation, pfGetNrScreens() will return 1.
This screen can now be asociated to 1 pfPipe.

How can you now use the other screen?

This is done by connecting the pfPipe explicitly to the screen of the
x-server by using the funtion
pfPipeWSConnectionName(pfPipe *pipe, const char *name) eg
pfPipeWSConnectionName(&pipe1, "mets-a:1.0")

3- Application is started from a remote x-connection:
Asuming the system is configured as 2 x-servers, the connection is done
as follows:

                  pfPipeWSConnectionName(&pipe1, "mets-a:0.0");
                  pfPipeWSConnectionName(&pipe2, "mets-a:1.0");

  When configured as 1 x-server:

                  pfPipeWSConnectionName(&pipe1, "mets-a:0.0");
                  pfPipeWSConnectionName(&pipe2, "mets-a:0.1");

(in the case of remote connection to a server that manages all screens,
it is probably easier to just set the DISPLAY environment variable to the
"first screen of interest", eg export DISPLAY=mets:0.0)

Windows?

The next step is defining "pfPipeWindows" from the pfPipes. A fullscreen
application, with a screen that "maps" to serveral video outputs can be
setup in several ways:
1 - 1 pfPipeWindow that covers the total area by specifying it as
"fullscreen"
2- a pfPipeWindow for "each video-output" by specifying the location and
size of each window within the "total screen area".

For fullscreen application i always use method 1. I think that each
pfPipeWindow has its own "graphic context" in the draw process. By using
more pfPipeWIndows, the resulting graphic context swapping is less
efficient than using 1. I think it can be generalised to state "for
fullscreen applications, only use 1 pfPipeWindow per screen".

A pfPipeWindow is implicitely associated with a pfWindow. The pfWindow is
the "pr" equavalent of the pfPipeWindow, and thus can only be used from
the draw process. They share many functions but not all. This has to do
with the fact that only the draw proces has the connection to the
x-server.
I guess that calls to a pfPipeWindow (from the application process)
"register" things to be actualy done by the associated pfWindow in the
draw process.

The "final step" that finishes the setup:

A pfChannel defines a "view from a scene". A pfChannel must be rendered
to a pfPipeWindow/pfWindow. You can specify wich area of the
pfPipeWindow/pfWindow should be used. In case of a screen with multiple
"video-ouputs", configured with 1 pfPipeWindow, each "video-output"
is associated with a channel that specifies its location&size within the
total screen.
(A great improvement of Performer 3.0 are the "pfvViewer" and related
classes, that enable configuration from an xml description file).

"Christopher D. Johnson" <cubicwts++at++excite.com>
Sent by:
owner-info-performer++at++performer.engr.sgi.com
2005-10-06 00:33
Please respond to
cubicwts++at++excite.com

To
stacep++at++sgi.com
cc
info-performer++at++sgi.com
Subject
Re: [info-performer] Multipipe Initialization
Classification

So when I create my single pfPipe (which I already have) and then create
my 2 seperate windows, what is the "best" way to have each of my windows
go to the proper display? I though something like the following calls
might work:

pfpwinscreen(pwinLOWER,0);
pfpwinscreen(pwinUPPER,1);

but the definition of pfpwinscreen states that it "will set the screen of
pwin and on the parent pfPipe." And from what I understand you can only
have one pipe per screen. BUt if what you say is true, and my system is
treating the 2 physical screens as one "screen", what calls would I make
to get the windows on the proper physical screen?

Before, when I made the calls:

pfPipeScreen(mttGlobal->gfxPipeLOWER,0);
pfPipeScreen(mttGlobal->gfxPipeUPPER,1);

I could see the windows on each screen being created when I called
pfFrame() the first time. Does the fact that these calls directed the
windows (and assigned the pipes) to the "screen" I expected mean I have to
treat the situation as two screens and have 2 pipes?

As an aside, I can move the mouse pointer from the lower screen to the
upper screen seemlessly. Is this a direct indication that the system sees
the 2 physical screens as one "screen"? I know this is long winded but I'm
trying to really get the heart of the concepts I'm learning here. Thanks.

Christopher D. Johnson
AV-8B Harrier II Simulators
ISEO Support Team
Cherry Point, NC
252-466-4542
252-466-4538

--- On Wed 10/05, Stace Peterson < stacep++at++sgi.com > wrote:
From: Stace Peterson [mailto: stacep++at++sgi.com]
To: cubicwts++at++excite.com
Cc: info-performer++at++sgi.com
Date: Wed, 05 Oct 2005 13:22:35 -0700
Subject: Re: [info-performer] Multipipe Initialization

Hi, Gordon's comment is probably correct. If the system has a
single graphics card, then you should only be creating one pfPipe. The
notice you reported is usually not a meaningful one, unless you are
directly calling pfChooseFBConfig in your application with constraints
which may not be achievable. For most multi-screen PC setups, the
single card treats the combined screen as a single desktop, and thus
you will want to use either 2 windows with 2 channels, or 1 window with
2 channels on a single pipe. Hope this helps, Stace
 "Christopher D. Johnson" wrote: > > Greetings all. I have a
simulation program running on a dual processor PC. There is an upper and a
lower LCD display, with the lower LCD being a touch screen. The lower
screen is "display 0" while the upper screen is "display 1". > >
What I am trying unsuccessfully to do is initialize performer so that I
have 2 pfPipes created (one for each display) and
each pfPipe has just a single pfPipeWindow attached to it. Everything
initializes seemingly fine until I call pfFrame() for the first time, at
which time I see my full screen windows created (blank) on the uper and
lower display, and then it bombs out (the screens disappear) and I get the
following notice: > > "PF Notice: pfChooseFBConfig: failed to make
configuration matching specified attributes" > > Below that I get a
"BadWindow" message as my X calls try to operate on the lower window
created. Simply going back to one pipe, one window runs fine. Here are the
functions I am using to initialize performer and initialize the pfPipes
and pfPipeWindows. I've looked in the Performer manual and tried to set
the pipes and windows up to work properly, but obviously I am missing
something. Any clues? > > static void > initPerformer(void) >
{ > void *arena = NULL; > pfSharedArenaSize(134217728); /* 128
* 1024 * 1024 = 128 Mb */ > //
pfSharedArenaSize(167772160); /* 160 * 1024 * 1024 = 128 Mb */ > //
pfSharedArenaSize(268435456); /* 256 * 1024 * 1024 = 256 Mb */ >
pfInit(); > arena = pfGetSharedArena(); > > /* Allocate
Global Variables */ > mttGlobal = pfMalloc(sizeof(global_t),
arena); > MttGfx = pfMalloc(sizeof( MTTGFX ),
arena); > c_ = pfMalloc(sizeof( struct ForCComm ),
arena); > ntReq = pfMalloc(sizeof(NTREQ), arena); >
 > Client = pfMalloc(sizeof( CLIENT ), arena); >
BBoxTerrain = pfMalloc(sizeof ( pfBox ), arena); > > /*
initialize global values */ > initGlobal(); > >
/*------------------------------------------------------ > *
Initialize main Gfx variables. >
*-----------------------------------------------------*/ >
initGfx(); > readConfigFile(); > > //
pfMultiprocess(PFMP_DEFAULT); >
pfMultiprocess(PFMP_FORK_DBASE | PFMP_FORK_LPOINT); >
pfMultipipe(2); > > // scb - uncommented Multithread(...) >
/* pfMultithread(0, PFPROC_CULL, 2); */ > >
pfdInitConverter("flt"); > pfConfig(); > pfFilePath(
"../data/"); > pfNotifyLevel(PFNFY_FATAL); > #ifdef
GFXAUTOSYNC > pfFrameRate(MttGfx->FrameRate); >
pfPhase(PFPHASE_LOCK); > #endif > } > > static void
OpenPipeWin(pfPipeWindow *pwin) > { > pfOpenPWin(pwin); >
} > > static void > initPipeWindow(void) > { > int
constraints[] = { > PFFB_DOUBLEBUFFER, > PFFB_RGBA, >
 PFFB_RED_SIZE, 5, > PFFB_GREEN_SIZE, 5, >
PFFB_BLUE_SIZE, 5, > > PFFB_ALPHA_SIZE, 1, >
PFFB_STENCIL_SIZE, 8, > PFFB_DEPTH_SIZE, 15, > (int)NULL >
 }; > /*------------------------------------------------------ >
* Configure graphics
pipeline. >
*-----------------------------------------------------*/ >
mttGlobal->gfxPipeLOWER = pfGetPipe(0); > if
(!(mttGlobal->gfxPipeLOWER)) { > fprintf(stderr, "ERROR: Unable
to initialize (pfPipe *) LOWER!\n"); > abort(); > } >
mttGlobal->gfxPipeUPPER = pfGetPipe(1); > if
(!(mttGlobal->gfxPipeUPPER)) { > fprintf(stderr, "ERROR: Unable
to initialize (pfPipe *) UPPER!\n"); > abort(); > } >
 > pfPipeScreen(mttGlobal->gfxPipeLOWER,0); >
pfPipeScreen(mttGlobal->gfxPipeUPPER,1); > > mttGlobal->pwinLOWER =
pfNewPWin(mttGlobal->gfxPipeLOWER); > if (!(mttGlobal->pwinLOWER))
{ > fprintf(stderr, "ERROR: Unable to initialize (pfWindow *)
LOWER!\n"); > abort(); > } > mttGlobal->pwinUPPER =
pfNewPWin(mttGlobal->gfxPipeUPPER); > if (!(mttGlobal->pwinUPPER))
{ > fprintf(stderr, "ERROR: Unable to initialize (pfWindow *)
UPPER!\n"); > abort(); > } > >
pfPWinName(mttGlobal->pwinLOWER,MttGfx->ScreenLOWER.Name); >
pfPWinType(mttGlobal->pwinLOWER, PFWIN_TYPE_X); > pfPWinMode(
mttGlobal->pwinLOWER, PFWIN_NOBORDER, 1); > pfPWinConfigFunc(
mttGlobal->pwinLOWER, OpenPipeWin); > pfChoosePWinFBConfig(
mttGlobal->pwinLOWER, constraints); > pfConfigPWin(
mttGlobal->pwinLOWER ); > pfPWinOriginSize(mttGlobal->pwinLOWER, 0,
0, > MttGfx->ScreenLOWER.SizeW, >
MttGfx->ScreenLOWER.SizeH); >
//pfPWinScreen(mttGlobal->pwinLOWER,0); >
pfOpenPWin(mttGlobal->pwinLOWER); > >
pfPWinName(mttGlobal->pwinUPPER,MttGfx->ScreenUPPER.Name); >
pfPWinType(mttGlobal->pwinUPPER, PFWIN_TYPE_X); > pfPWinMode(
mttGlobal->pwinUPPER, PFWIN_NOBORDER, 1); > pfPWinConfigFunc(
mttGlobal->pwinUPPER, OpenPipeWin); > pfChoosePWinFBConfig(
mttGlobal->pwinUPPER, constraints); > pfConfigPWin(
mttGlobal->pwinUPPER
); > pfPWinOriginSize(mttGlobal->pwinUPPER, 0, 0, >
MttGfx->ScreenUPPER.SizeW, > MttGfx->ScreenUPPER.SizeH); >
//pfPWinScreen(mttGlobal->pwinLOWER,1); >
pfOpenPWin(mttGlobal->pwinUPPER); > > /* set off the draw
process to open windows and call init callbacks */ > pfFrame(); >
 > sleep(3); > > pfPWinFullScreen( mttGlobal->pwinLOWER
); > pfPWinFullScreen( mttGlobal->pwinUPPER ); > >
mttGlobal->dspLOWER = pfGetCurWSConnection(); > > // Logic To
Set Up Catching Of X-Events on the lower touch screen >
mttGlobal->winLOWER = pfGetPWinWSWindow(mttGlobal->pwinLOWER); >
XSelectInput(mttGlobal->dspLOWER,mttGlobal->winLOWER,KeyPressMask |
ButtonPressMask ); >
XMapWindow(mttGlobal->dspLOWER,mttGlobal->winLOWER); >
XSync(mttGlobal->dspLOWER,FALSE); > >
/*------------------------------------------------------ > * Remove
cursor arrow. >
*-----------------------------------------------------*/ > #ifndef
TESTMTT > pfuLoadPWinCursor(mttGlobal->pwinLOWER,
PFU_CURSOR_OFF); > #endif > } > > Christopher D. Johnson >
AV-8B Harrier II Simulators > ISEO Support Team > Cherry Point,
NC > 252-466-4542 > 252-466-4538 > >
_______________________________________________ > Join Excite! -
http://www.excite.com>> The most personalized portal on the Web! >
 >
----------------------------------------------------------------------- >
 List Archives, Info, FAQ: http://www.sgi.com/software/performer/>>
Open Development Project: http://oss.sgi.com/projects/performer/>>
 Submissions: info-performer++at++sgi.com > Admin.
requests: info-performer-request++at++sgi.com >
----------------------------------------------------------------------- --
 ------------------------------------------------------------------ Stace
Peterson

 stacep++at++sgi.com Silicon Graphics, Inc.
 (650) 933-2323

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

-----------------------------------------------------------------------
   List Archives, Info, FAQ: http://www.sgi.com/software/performer/
   Open Development Project: http://oss.sgi.com/projects/performer/
                Submissions: info-performer++at++sgi.com
            Admin. requests: info-performer-request++at++sgi.com
-----------------------------------------------------------------------

Next message: jan p. springer: "Re: [info-performer] Multipipe Initialization"
Previous message: Christopher D. Johnson: "Re: [info-performer] Multipipe Initialization"

Date view	Thread view	Subject view	Author view

This archive was generated by hypermail 2b29 : Thu Oct 06 2005 - 03:02:51 PDT