280 likes | 380 Views
Project “Smoke” N-core engine experiment. Threading for Performance AND Features. “Smoke” is threaded for performance and features – here’s how!. Engine + framework with typical game subsystems. Well partitioned, configurable Share source, demos, samples, workloads, white papers
E N D
Project “Smoke”N-core engine experiment Threading for Performance AND Features
“Smoke” is threaded for performance and features – here’s how! Engine + framework with typical game subsystems • Well partitioned, configurable • Share source, demos, samples, workloads, white papers • More info at Intel Developer Forum
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
It’s working today! • Display (Ogre3D) • TaskManager • Physics • Sound • Volumetric Smoke • Procedural Fire • Procedural Trees • AI • Animation • User input/control • Scripting • Instrumentation • Camera bot
Engine Framework Managers Environment Parser Scheduler Task Messaging (Change control) Service UScene Platform … UObject UObject Interfaces Systems Definition Files 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 System
GDC 2007: Restructuring will take games to multiple processors!
Task Manager: scalable n-core thread pool • 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)
Systems subscribe to change messages Subscribe Graphics System • Each system subscribes to changes it needs • Decoupled communication reduces dependencies • Observer/Mediator • Lower memory bandwidth Subscribe Physics System Subscribe AI System …
Render Tasks get subdivided Graphics System • Scheduler invokes each system per frame • System subdivides work into sub-tasks • Using “natural” granularity • Good middleware makes this easy Physics Physics Physics System AI System AI AI AI AI ...
Render Tasks get subdivided Graphics System • All sub-tasks in single job pool Physics Physics Physics System AI System AI AI AI AI Render ... Job Pool Physics Physics AI AI AI AI ...
Render Tasks get subdivided Graphics System • N worker threads, 1 per processor core • Sub-tasks spread out as needed Physics Physics Physics System AI System AI AI AI AI Render Render ... Physics Worker Threads AI AI Job Pool Physics Physics Physics AI AI AI AI AI AI AI AI AI AI AI ...
Render Tasks post changes Graphics System Messaging (change control) Physics Physics Physics System Post changes AI System AI AI AI AI Render Render ... Physics Worker Threads AI AI Job Pool Physics Physics Physics AI AI AI AI AI AI AI AI AI AI AI ...
Render Each thread has queued changes Graphics System C3 C1 C5 Messaging (change control) Physics Physics C7 Physics System C2 C6 C4 AI System AI AI AI AI Render Render ... Physics Worker Threads AI AI Job Pool Physics Physics Physics AI AI AI AI AI AI AI AI AI AI AI ...
Render Changes are sent to observers Graphics System C3 C1 C5 Messaging (change control) Physics Physics C7 Physics System C2 C6 C4 AI System Change Occurred AI AI AI AI Render Render ... Physics Worker Threads AI AI Job Pool Physics Physics Physics AI AI AI AI AI AI AI AI AI AI AI ...
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)
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?
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 Orion Granatir
Scene layout is configurable FireBall.Object Meteor.Object Physics Properties + + FallingMeteorOnFire.Object
How do we put a scene together? SmokeDemo.Scene <Scene> <Include CDF="House.Scene"/> <Include CDF="Sky.Object"/> <Include CDF="Terrain.Object"/> // Meteor 1 <Include ODF="FallingMeteorOnFire.Object"/> // Meteor 2 <Include ODF="FallingMeteorOnFire.Object"/> ... // Meteor 10 <Include ODF="FallingMeteorOnFire.Object"/> </Scene>
The fire system burns brightly! • Propagates naturally • Smart particle systems use heat particles from each fire to spread procedurally • Configurable density, velocity, direction, etc.
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
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
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
Sometimes, things go wrong Heavy contention on global sync object Per-thread sync
What’s next for Smoke? • Continuing development • Look for public showing later in 2008 • Code and white paper release to follow
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!
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?