Re: [info-performer] Multipipe Initialization

Date view	Thread view	Subject view	Author view

From: Christopher D. Johnson (cubicwts++at++excite.com)
Date: 10/06/2005 06:24:07

Next message: Jason Daly: "Re: [info-performer] Multipipe Initialization"
Previous message: Jason Daly: "Re: [info-performer] Multipipe Initialization"
Maybe in reply to: Christopher D. Johnson: "[info-performer] Multipipe Initialization"
Next in thread: Jason Daly: "Re: [info-performer] Multipipe Initialization"
Reply: Jason Daly: "Re: [info-performer] Multipipe Initialization"

Rick-

Excellent info. I have run "echo $DISPLAY" on my Fedore Core 3 system and what I get is ":0.0". In my program, I am running "system("export DISPLAY=:0.0;/usr/X11R6/bin/xhost + ");" before I do anyth ing else. If I r un "system("export DISPLAY=:0.1;/usr/X11R6/bin/xhost + ");" instead, things show up on the "upper" LCD. Seems to me this indicates that my system is running a single X-Server that "sees" the two screens and would explain why when I run the following:

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

and then call pfFrame() I can see the windows (black) being created on each LCD. Then my calls to grab the display and capture x-events are what fails. Great information. I feel like I am learning something, just not sure how to apply it to get the results (i.e. get my program not to hang during initialization) I need.

Is it al least safe for me to assume, given what I said above, that I am running on one X-Server managing 2 screens?

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

--- On Thu 10/06, Rick van Haasen < rick.van.haasen++at++philips.com > wrote:
From: Rick van Haasen [mailto: rick.van.haasen++at++philips.com]
To: cubicwts++at++excite.com
Cc: info-performer++at++sgi.com
Date: Thu, 6 Oct 2005 12:00:36 +0200
Subject: 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 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 -----------------------------------------------------------------------

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

Next message: Jason Daly: "Re: [info-performer] Multipipe Initialization"
Previous message: Jason Daly: "Re: [info-performer] Multipipe Initialization"
Maybe in reply to: Christopher D. Johnson: "[info-performer] Multipipe Initialization"
Next in thread: Jason Daly: "Re: [info-performer] Multipipe Initialization"
Reply: Jason Daly: "Re: [info-performer] Multipipe Initialization"

Date view	Thread view	Subject view	Author view

This archive was generated by hypermail 2b29 : Thu Oct 06 2005 - 06:24:24 PDT