web physics a hardware accelerated physics engine for web
play

Web Physics: A Hardware Accelerated Physics Engine for Web- Based - PowerPoint PPT Presentation

Web Physics: A Hardware Accelerated Physics Engine for Web- Based Applications Tasneem Brutch, Bo Li, Guodong Rong, Yi Shen, Chang Shu Samsung Research America-Silicon Valley {t.brutch, robert.li, g.rong, c.shu, yi.shen}@samsung.com Web


  1. Web Physics: A Hardware Accelerated Physics Engine for Web- Based Applications Tasneem Brutch, Bo Li, Guodong Rong, Yi Shen, Chang Shu Samsung Research America-Silicon Valley {t.brutch, robert.li, g.rong, c.shu, yi.shen}@samsung.com

  2. Web Physics Summary Web • Transparent access to native 2D physics engine through JS APIs. Physics • OpenCL accelerated 2D Physics Engine (Box2D-OpenCL). Web Games Media Motivation • High performance, interactive compute & graphics apps on mobile Apps Apps • Transparent & efficient access to acceleration from web apps. JavaScript Libraries Goals • Cross-platform, portable, accelerated, robust & flexible Web API Native Usages • Real time mobile gaming; Compute intensive simulation; Web Physics JS Apps Bindings • Computer Aided modeling; Physical effects & realism; • Augmented Reality; Real-time big data visualization; OpenCL Accelerated Approach Hybrid Web Physics approach: Box2D--OpenCL Native Physics Engine • Accelerate using native multicore hardware & open parallel APIs. OpenCL Device Driver • Expose parallelism through JS APIs to web applications. Manycore Multicore Accomplis • Web Physics JavaScript API Framework (Web Physics JS APIs) GPGPU CPU hments • OpenCL accelerated 2D Physics Engine (Box2D-OpenCL) • JavaScript Physics Engine (Box2DWeb 2.2.1 APIs) 2

  3. Web Physics Approach

  4. Web Physics Overview Architectural Reasoning Decision • JS performance a concern for high compute use cases. Accelerated • OpenCL parallelization API for heterogeneous multicore Box2D devices (CPU, GPU) can provide needed performance. JavaScript • Portable Web APIs for compute intensive web apps. bindings for • Cross platform application developer support physics • Transparent access to accelerated library, without requiring engine APIs parallelization of apps. Modular • Incremental parallelization of physics engine pipeline architecture • Ease of testing. Preserve • Leverage existing ecosystem: To ensure that existing apps Box2D open using Box2D physics engine can use Box2D-OpenCL source APIs 4

  5. Web Physics Requirements Transparent and efficient access to acceleration on client through JS APIs, from 1. Web applications: JS Bindings implemented in WebKit-based browser engine • Near-native performance for high compute web simulation: 2. Hybrid approach: Access to accelerated native physics engine through JS bindings • <= 1.5X performance impact from JS binding, relative to native physics engine • Full feature support, and no API change: 3. Complete Box2D features and API support in accelerated native physics engine • No API change: Box2D-OpenCL APIs should be identical to those of Box2D 2.2.1 • Complete JavaScript API support in JS physics engine for benchmarking 4. Box2DWeb 2.2.1 JS physics engine supporting all Box2D 2.2.1 features. • Acceleration using open parallel API for heterogeneous platforms: 5. OpenCL accelerated physics engine for multicore CPU and GPGPU (Box2D-OpenCL) • 5

  6. JavaScript Bindings

  7. Web Physics Architectural Approaches Web Applications Web Applications Web Applications Browser/ Box2D Browser/ Box2D Browser/ Box2D Web Runtime Web API WebRuntime Web API Web Runtime Web API WebKit WebKit WebKit Dynamic WebCore JavaScript WebCore WebCore NPAPI Injection Core Framework Box2D JavaScript JS Box2D Core Injected Box2D JS Binding Plugin IPC Bundle Binding Binding Box2D- Box2D-OpenCL Box2D-OpenCL OpenCL Plugin-Approach WebCore Approach Inject Bundle Pros • Browser portability. • Usable by native and web apps • Maintainability: Less impact from • Portability • Best comparative performance. physics engine changes • Maintainability • No IPC overhead • Code reusability • No IPC overhead Cons • IPC communication expensive • Difficult to Maintain • Complexity between plugin & web process • More complex • Not Reusable across browsers 7

  8. Box2DWeb 2.2.1 JavaScript Physics Engine • Physics Engine written entirely in JavaScript. Web Apps • Existing open source project (box2dweb) had Box2DWeb2.2.1 JS Library implemented Box2D 2.1.2 APIs. Browser / • Box2DWeb 2.2.1 JS physics engine implements WebRuntime JS APIs corresponding to all Box2D 2.2.1 APIs. WebKit • Used for benchmarking & comparative analysis. • Currently in the process of being open sourced. JavaScript WebCore Core 8

  9. Web Physics Binding Implementation ² IDL code generator features: ² Performance overhead <= 1.5x relative to Box2D + Constructor overloading − Includes parsing overhead of JavaScript code, and + Support for constructor-type static read-only binding code overhead attribute in IDL ² Implementation restrictions: • Patch up-streamed to WebKit.org − Strict type checking, relative to Box2DWeb • JSC specific binding classes, functions − Native classes & functions written into IDL files, & generated from Box2D IDLs. Code generator their implementation added manually can support JSC & V8. ² Wrapper Layer features: + Interfaces with native Box2D physics engine. A glue layer from Box2D native engine to auto- generated JS binding classes. + Most code is JS engine independent + Complete support for Box2D classes + 1:1 mapping to Box2D native objects + Preserves Box2D tree structure + Callback function support using Listeners + Supports DebugDraw Web Physics JS Bindings Framework 9

  10. OpenCL Acceleration

  11. Box2D-OpenCL Parallelization Collision Detection: • Broad Phase and Narrow Phase . • Enforces natural physical constraints on simulated physical objects Detects collisions. Constraint Solver: • Computes velocity and position constraints • Updates velocities and positions of bodies Benchmarking: • Collision Detection & Constraints Solver prioritized for parallelization • ~64% of total time spent in Collision Detection stage • ~21% of time spent in Broad Phase • ~43% in Narrow Phase • ~35% of total time spent in Solver 11

  12. Collision Detection – Broad Phase Goal: Quickly find pairs of objects that might collide each other, and cull out all pairs that cannot collide each other. Algorithm: Axis Aligned Bounding Box (AABB) used to approximate objects for fast testing Parallel Broad Phase: Sequential Broad Phase: • SaP (Sweep and Prune) [1] • BVH (Bounding Volume Hierarchy) • Compute an interval [ x i , X i ] for each AABB O i • Traverse from top to bottom • Sort all AABBs by x_min • Good for sequential programs but not • For all AABBs O i , execute the followings in efficient for parallel programs due to low parallel: parallelism in higher levels of BVH • Sweep from x i to X i to find all O j with x j ∈ [ x i , X i ] and i < j • For each O j , if O i ∩ O j ≠ ∅ , output a pair ( O i , O j ) [1] F. Liu, T. Harada, Y. Lee, and Y. J. Kim, “Real-time collision culling of a million bodies on graphics processing units,” ACM Trans. Graph., vol. 29, no. 6, pp. 154:1–154:8, 2010. 12

  13. Collision Detection – Narrow Phase Goal: For each pair generated by BP, test whether the two objects collide or not. If collide, generate a manifold for the pair. Algorithm: Separating Axis Theorem (SAT) used to test intersection of two objects. Sequential Narrow Phase: Parallel NP (Solution 1): Parallel NP (Solution 2): • Loop over all pairs • Execute a single kernel for • Execute a multiple kernels • Check each pair using all pairs, using different for different type of pairs, different functions for branches for different types each kernel deal with one different types (e.g. inside the kernel: type of pair only. polygon-polygon, if polygon-polygon pair polygon-edge, circle- Compute for p-p type edge, etc.) else if circle-edge pair Ø Solution 2 has better Compute for c-e type performance … 13

  14. Collision Detection – Narrow Phase • At the end of NP stage, we compact all “valid” pairs (i.e. whose two objects collide with each other), to the head of the list for the next stage. input pairs A B C D E F G H I J K L M N O P (from BP) validity masks 0 1 1 0 0 0 1 1 1 1 0 1 0 0 0 1 (1-valid, 0-invalid) exclusive scan results 0 0 1 2 2 2 2 3 4 5 6 6 7 7 7 7 (b i =a 0 +a 1 + … a i-1 ) B C G H I J L P compacted valid pairs 14

  15. Solver Goal: For each collided contact pair generated by collision detection, solve the physics constraints and update two bodies’ velocities and positions 1. Solve velocity constraints iteratively Compute relative velocities between bodies • Compute impulse from the relative velocities • Update velocities using the impulse • Solve position constraints iteratively 2. Compute penetration and convert it to impulse • Update positions using the impulse • Parallel Solver: Accelerated pipeline for parallel computation of contact constraints 15

Recommend


More recommend