Upload
others
View
11
Download
0
Embed Size (px)
Citation preview
1
Parallel Rendering using OpenGL Multipipe SDK (MPK)
Praveen BhaniramkaSGI
2
Talk OutlineOverviewApplication StructureConfiguration InterfaceParallel RenderingRelated Projects/ApproachesMore Information
3
OverviewDesign Objectives/Features• Provide an API for development of OpenGL-based Multipipe
applications• ‘Runtime portability’ from desktop to multi-pipe systems• ‘Runtime scalability’• Minimize invasiveness
Sort of like a multipipe GLUT
4
Runtime PortabilityFrom Single-pipe systems to Multi-pipe systems
Application is independent of system configuration
5
Runtime Scalability
Application scales as hardware resources areadded
6
Minimal InvasivenessCallback drivenBasic OpenGL FrameworkRelatively simple GLUT-like C APIChannel & Stereo Independent
7
Application Structure
OpenGL Rendering(Application code)
Multipipe Management(MPK)
Application Callbacks
System Configuration(MPK Config file)
Load at runtime
8
System ConfigurationMPKConfig• Hierarchical Description of System Configuration• Specifies the relationships between different components
MPKChannel• Basic, display device independent OpenGL rendering unit. • These are “framebuffer resources”
MPKConfig Hierarchy• A Config has one or more Pipes• A Pipe has one or more Windows*• A Window has one or more Channels
* Each window has a dedicated rendering thread
9
Application Flow Start application
Load Configuration from file
Set MPK Callbacks, Initialize shared data
Call mpkConfigInit()
Exit Application?
No
Update frame data
Call mpkConfigFrame()
Invoke Exit callbacks,
Free shared data
Call mpkConfigExit()
Stop
10
Application Flow
Render execution flow is controlled by ...mpkConfigFrame()
... which leads to execution of …the draw scene callback (per channel)
• Executes one frame of rendering• Window threads invoke update callbacks• Passed framedata is distributed latency-correct
11
Application#include <mpk/mpk.h>// main()mpkInit();MPKConfig* cfg = mpkConfigLoad(configFileName); //read configmpkConfigSetWindowInitCB(cfg,initWindowCB); // initialize window callbacksmpkConfigInit(cfg); // start: spawn one thread per window // rendering loopwhile ( notDone ) {
// do application work (spin the cow, make sharks // swim, etc)updateSharedData( &framedata );// sync window loop threads, etc.mpkConfigFrame( cfg, framedata );
}mpkConfigExit(cfg);
12
Application// updateChannel()user callback: invoked by // mpkConfigFrame() => glutDisplayFunc// clear render areampkChannelApplyBuffer( c );mpkChannelApplyViewport( c );glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );// apply projection matrixglMatrixMode( GL_PROJECTION );glLoadIdentity();mpkChannelApplyFrustum( c );// apply modelview matrixglMatrixMode( GL_MODELVIEW );glLoadIdentity();mpkChannelApplyTransformation( c );// cull and/or draw cow, sharks, etc.drawSharedData( c, framedata );
13
Rendering Flow
Pipe => Window => Thread => GL Context => Channel
Application Thread Window Thread Window Thread
for each channel
do per window work
for each window
do channel rendering
for each frame
mpkConfigFrame
14
Config FileSimple ASCII file representation of MPKConfig data structureHierarchical Description for Framebuffer ResourcesChannel Physical LayoutChannel Decomposition
15
Simple Config
1 pipe, 1 windowconfig {
name “1-window”pipe {
window {name “MPU:simple”viewport [ 0.25 0.25 0.5 0.5]
channel {name “channel”wall {
bottom_left [0 0 0]bottom_right [1 0 1]top_left [1 1 1]
}}
}}
}
16
Simple Config1 pipe, 2 windowsconfig {
name “2-windows”pipe {
window {name “left”viewport [ 0.25 0.25 0.25 0.5]
channel {name “channel”wall {
bottom_left [0 0 0]bottom_right [1 0 1]top_left [1 1 1]
}}
}window {name “right”viewport [ 0.5 0.25 0.25 0.5]
channel {}
}}
}
17
CompoundsCompounds provide an abstraction for parallel rendering• A Config can have one or more compounds• Compounds can be hierarchical with a tree-like structure• Compounds reference channels as sources and/or destinations• SW as well as HW compositing• Scaling may require some application awareness
18
Compounds
19
Compoundsconfig {
# one or more pipes with windows and channelspipe {... ...}...
# compound for the above configcompound {
# specify the compound type, format and output channelmode [ 2D/DB/DPLEX, HW/NOCOPY, etc ]format [ COLOR, DEPTH, etc]channel "channel_1“# specify one or more source channels and their paramsregion {
... ...}...
}}
20
CompoundsCommonly used Modes• 2D (screen tiling)• DB (database decomposition)• DPLEX (time-slice multiplexing)• EYE (stereo decomposition)• Others...
21
2D CompoundEach pipe renders a different viewport
22
2D Compoundcompound {
mode [ 2D ]
format [ COLOR ]
channel "channel_1"
region {
viewport [ 0., .0, 1.0, 0.5 ]
channel “channel_1"
}
region {
viewport [ 0., .5, 1.0, 0.5 ]
channel "channel_2"
}
}
23
2D CompoundAutomatic Load balancing
• Based on timing values from last frame• Good results for low-latency decompositions
24
DB Compound
N times pixel fill rateN times texture memory
Each pipe renders a different part of the data set
N times texture download rate
25
DB CompoundCompositing order changes with viewAdaptive Readback comes in handy
26
DB Compoundcompound {
mode [ DB ]
format [ COLOR DEPTH ]
channel "channel_1"
region {
range [ 0., 0.5 ]
channel “channel_1"
}
region {
range [ 0.5, 1 ]
channel "channel_2"
}
}
27
DPLEX Compound
Each pipe renders a different frame
28
DPLEX Compoundcompound {
mode [ DPLEX ]
format [ COLOR ]
channel "channel_1"
region {
channel “channel_1"
}
region {
channel "channel_2"
}
}
29
EYE CompoundEach pipe renders for a different eye position
30
Compound ConfigsChoosing the right decomposition mode
YY
Y/N
Geometry Processing
YNN
Graphics Memory
YYYDPLEXY
N
Bandwidth to graphics
NYDB
Y/NY2D
Application Transparent
Pixel FillMode
31
Hierarchical Compoundscompound {
mode [ DPLEX ASYNC ]channel "channel"region {
compound {mode [ DPLEX ASYNC ]channel "dplex::1"region { channel "dplex:a:1" }... ...
} }region {
compound {mode [ DPLEX ASYNC ]channel "dplex::2"region { channel "dplex:b:1" }... ...
} }region {
... ...} }
9 => 3 => 1 windows
32
Hardware Compositioncompound {
mode [ 2D HW NOCOPY ]
channel "channel0"
region {
viewport [ 0., .75, 1., .25 ]
channel "channel0"
}
... ...
region {
viewport [ 0., .25, 1., .25 ]
channel "channel2"
}
}
33
Hybrid CompoundsCombined DPLEX - 2D
+ +
Pipe 0 Pipe 1 Pipe 2 Pipe 3
34
Related ProjectsRelated Projects• Chromium
http://chromium.sourceforge.net• OpenGL Multipipe (OMP)
http://www.sgi.com/software/multipipe• CAVELib• VRJuggler
35
Scalability Approaches• Aware Applications
– Effort required to port the app to run in MP environment (MPK, PF)
– Good scalability with app work
– Immersive environments easier to handle
• Unaware Applications– Effort goes into the intercept-
dispatch library (CR, OMP)
– Good/Limited scalability depending on the app
– Immersive environments not so easy
36
MPK vs OMP• Multipipe SDK
– API for writing MP apps– App scales fill, geometry,
memory and display
• OpenGL Multipipe– Transparent app layer– Scales display size, fill,
well. Limited geometry, texture, scaling.
37
Recap: Features
Ease of Integration• fork, sproc, pthread support• Event-driven execution model• Adaptive readback interface• App-created windows support• Non-threaded windows support• Xinerama integration• Custom compositing interface
Runtime Portability• ASCII File Format specification• Multi-frustum support• Dynamic parallel rendering
Runtime Scalability• Compound class specification• 2D, DB, EYE, DPLEX and FSAA compounds• RGBA, Z and STENCIL image compositing• Latency / ASYNC decomposition • Automatic load-balancing• SGI Scalable Graphics Hardware integration
Stereo / Immersion• Off-axis frustum computations• Stereo / Head-Tracking support• Head Mounted Display [ HMD ]• Mirrored Projection Support
38
MPK: More InformationMPK 3.0.1 web release availableMultipipe SDK product web site http://www.sgi.com/software/multipipe/sdkEngineering mailing [email protected]
40
MPK/OMP/ChromiumMultipipe API Comparison
Chromium OMP MPKApplication-transparent Yes/No Yes NoOpen source Yes No NoSupported OSes Windows, Linux, IRIX, etc. Linux (IA64), IRIX Linux (IA64), IRIXProgramming model application-transparent OpenGL +
optional Chromium extension(s)application-transparent OpenGL callbacks for frame and data
management
Runtime configuration method python launch scripts, interchangeable modular Stream Processing Units (SPUs)
command line flags, environment variables
MPK config file
Architecture multiprocess multiprocess multithreaded/forkNode structure arbitrary directed graph of SPUs
(many masters, many slaves)one master (app), one or more cullers, many slaves
one master, many slaves (optional culler per slave)
Codec WireGL-like GLScodec N/ATransport among processes tcp, miranet, MPI, IB? shared memory (queue) - data
must be copied into shmshared memory (arena) - can pass pointers to data residing in shm
Decomposition modesSort-first (Tilesort) Yes Yes YesSort-last (Depth/Alpha) Yes No YesSort-last w/ HW readback No No NoTimeslice ?? No YesStereo Yes No Yes
Culling (tilesort)BBox computation Master node Master node ApplicationBBox transformation Master Culler ApplicationGL state management Master Slave Application
Number of transport channels one per edge in the graph one per rendering application thread
one per MPK application
Readback/glGet Not fully supported? Master queries slaves or local pipe Native GL
41
MPK: Configuration