Download presentation
Presentation is loading. Please wait.
Published byDina Gardner Modified over 9 years ago
1
Project “Smoke” N-core engine experiment Threading for Performance AND Features
2
“Smoke” is threaded for performance and features – here’s how! 2 Well partitioned, configurable Share source, demos, samples, workloads, white papers More info at Intel Developer Forum Engine + framework with typical game subsystems
3
Experiment with game tech – how does it all fit together? Explore performance on n-cores –Framework designed to scale to n threads –Which game architecture runs well with 8 threads? More? Try features –Procedural fire/smoke –Dynamic vegetation, etc. Measure them separately/together (to see interplay) –Core threading techniques –Physics –Dynamic vegetation –Fire/smoke, etc. Extend into the future 3
4
It’s working today! Display (Ogre3D) TaskManager Physics Sound Volumetric Smoke Procedural Fire Procedural Trees AI Animation User input/control Scripting Instrumentation Camera bot 4
5
The framework holds it together Heavy use of interfaces, easy to extend Minimizes thread sync via messaging Most of the code is in the Systems Engine Managers Framework Scheduler Parser Environment Service Platform Task Messaging (Change control) UScene UObject … Systems Definition Files Interfaces System 5
6
GDC 2007: Restructuring will take games to multiple processors! 6
7
Three configurations: Single thread – shut threading off Native threads Threading Building Blocks Thread count scales to HW (4-core here) Task Manager puts System’s update in pool Systems chunk the update for other threads Thread pool used by all systems (even external ones, like Havok) Task Manager: scalable n-core thread pool 7
8
AI System Graphics System Physics System Systems subscribe to change messages 8 Each system subscribes to changes it needs Decoupled communication reduces dependencies –Observer/Mediator Lower memory bandwidth Subscribe …
9
AI System Graphics System Physics System Physics AI Render AI... Tasks get subdivided 9 Scheduler invokes each system per frame System subdivides work into sub-tasks Using “natural” granularity Good middleware makes this easy
10
AI System Graphics System Physics System Physics AI Job Pool Render AI... Render Physics AI... 10 Tasks get subdivided All sub-tasks in single job pool
11
AI System Graphics System Physics System Physics AI Job Pool Render AI... Render Physics AI... AI Physics AI Physics AI Worker Threads Tasks get subdivided 11 Render N worker threads, 1 per processor core Sub-tasks spread out as needed
12
AI System Graphics System Physics System Physics AI Job Pool Render AI... Render Physics AI... AI Physics AI Physics AI Worker Threads Tasks post changes 12 Render Post changes Messaging (change control)
13
AI System Graphics System Physics System Physics AI Job Pool Render AI... Render Physics AI... AI Physics AI Physics AI Worker Threads Each thread has queued changes 13 Render Messaging (change control) C1 C2 C3 C4 C5 C6 C7
14
AI System Graphics System Physics System Physics AI Job Pool Render AI... Render Physics AI... AI Physics AI Physics AI Worker Threads Changes are sent to observers 14 Render C1 C2 C3 C4 C5 C6 C7 Change Occurred Messaging (change control)
15
Good news/bad news: systems can (must) chunk up work Some systems are very good at this (physics, fire, volumetric smoke, animation) Harder in other cases (graphics, script) 15
16
Sounds great, what makes this harder? Messaging system isn’t natural for sharing some data Service manager selectively exposes framework/system interfaces How do collision and AI work without data from multiple systems? 16
17
Graphics and animation show it all Using Ogre3D Extending window –Display performance stats –Debug output Extending Ogre’s animation –Drive skeletal based data to provide realistic creature expressions and locomotion –Use skeletons and weight maps –Hierarchical skeletal animation supports animation blending 17 Orion Granatir
18
Scene layout is configurable 18 Meteor.Object FireBall.Object Physics Properties FallingMeteorOnFire.Object + +
19
How do we put a scene together? 19 // Meteor 1 // Meteor 2... // Meteor 10 SmokeDemo.Scene
20
The fire system burns brightly! Propagates naturally Smart particle systems use heat particles from each fire to spread procedurally Configurable density, velocity, direction, etc. 20
21
Procedural trees Editable grammar and seeded parser –Easy to create an endless variety of trees Canopies can be added, changed, or removed for seasonal effects Create Forests: each seed creates a different tree 21
22
Physics rocks (and shatters)! Integrated physics –ODE/Newton –Havok (with CharacterProxy and BreakOffParts) –Bullet Physics Library Porting all systems to work with different physics Physics issues jobs that we put in thread pool as tasks
23
AI makes the world appear alive Flocks of chickens, herds of horses, and swoops of swallows all interact with the scene using custom AIs “Smart” enough to find companions, fear fire, and avoid falling objects AI was built from the ground up to be highly threaded AI drives velocity changes, uses Havok’s Character Proxy to interact w/environment 23
24
Sometimes, things go wrong Heavy contention on global sync objectPer-thread sync 24
25
What’s next for Smoke? Continuing development Look for public showing later in 2008 Code and white paper release to follow 25
26
Lessons learned (so far) Do: Evaluate the features of your middleware for integration. Find the best “chunking” in your systems. Measure, understand and tune your performance/content. Be the one that figures this all out! Don’t : Ignore thread interaction between systems, especially middleware. Panic. No one method works for everybody. Forget to share your great success stories at GDC 2009! 26
27
Questions from the attendees What do you think? Where should we go from here? Any favorite technologies we should integrate? Have you tried something like this? How did it go? Have you rejected trying something like this? Why? 27
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.