SPU Shaders. Mike Acton Engine Director Insomniac Games

Transcription

1 SPU Shaders Mike Acton Engine Director Insomniac Games

2 State of Affairs Engine Systems on SPUs SPU Optimization Understood Remaining Systems Planned Out Still Have SPU Time to Spare PPU Still Driving The Game Arguing for More Parallelism Want More Customization, Iteration Insomniac Games, 2007

3 Needed Strategy Bridging the Cell Gap Reducing synchronization points Better data flow Encouraging SPU use by more systems and programmers. Keeping SPU code straightforward, fast and optimizable. Get as much on the SPUs as possible. More customization, iteration. Ultimately: Kill the main update loop.

4 What are SPU Shaders? SPU Shaders are: Fragments of code used in a larger system Code is injected at location pre-determined by system. Custom for any particular system. Custom modifications of system data. Feedback to other systems outside the scope of the current system.

5 What are SPU Shaders? Like scripts... Like callbacks... Like messages... Like overlays... Like iterators... BUT! On the SPU, and very simple.

6 What are SPU Shaders? SPU Shaders are NOT: Generic, general purpose system. A system of any kind, actually.

7 What are SPU Shaders? Why is it called a shader? Shares important similarities to GPU shaders. Native code fragments Part of a larger system In-context execution Independently optimizable Most important: Concept is approachable.

8 What are SPU Shaders? SPU Shaders as policy: Simplicity by force. Don't try to solve everyone's problems Solutions that try to solve all problems tend to cause more problems than they solve.

9 Advantages Easy to implement Put the programmer in the right place at the right time. Programmer writes to SPU, not to software layer. Core performance issues still managed by systems programmers. Fragments are optimizable. Insomniac Games, 2007

10 Advantages Systems don't need to provide functionality for every possible case More power in the hands of the gameplay programmers. More communication between gameplay and engine. Less work-around and more work-within. Insomniac Games, 2007

11 Advantages Add functionality without modifying the system. Less risk to core. Less risk to other systems. Less risk to other shaders. Insomniac Games, 2007

12 Advantages And the obvious... It's not on the PPU. It's faster. Insomniac Games, 2007

13 Costs Forced to think about data layout and synchronization. (But that's a good thing.) Haphazard access isn't going to work. Debugging can be trickier. Need manage shaders As code in project, linked-in? As data stored with instance data? How to reference shaders? Insomniac Games, 2007

14 Easy To Implement Pick stage(s) in system kernel to inject shaders. Define available inputs and outputs. Collect common functions. Compile shaders as data. Sort instance data based on shader type(s) Load shader on-demand based on data select. Call shaders.

15 Easy To Implement What data is being transformed? What are the inputs? What are the outputs? What can be modified?

16 Easy To Implement Collect the common functions... Always loaded by the system e.g. Dma wrapper functions Debugging functions Common transformation functions

17 struct CommonFunctions { } PrintfProc* m_print_proc; PrintVectorProc* m_print_vector; PrintIntegerProc* m_print_integer; PrintFloatProc* m_print_float; PrintMatrix4Proc* m_print_mtx4; PrintMatrix3Proc* m_print_mtx3; DmaGetProc* m_dma_get; DmaPutProc* m_dma_put;

18 struct common_t { void (*print_str)(const char *str); void (*dma_wait)(uint32_t tag); void (*dma_send)(void *ls, uint32_t ea, uint32_t size, uint32_t tag); void (*dma_recv)(void *ls, uint32_t ea, uint32_t size, uint32_t tag); char* ls; uint32_t ls_size; uint32_t data_ea; uint32_t data_size; };

19 Easy To Implement System Shader Configuration... System doesn't know what the fragments do. Fragments are in main RAM. Fragments don't need to be fixed. System knows where the fragments are. System knows when to call the fragments.

20 struct config_t { uint32_t max_frag_size; // so we can do double buffering uint32_t frag_count; // number of fragments in the list uint32_t frags_ea; // EA of list of fragments uint32_t pad_0; };

21 Easy To Implement System Shader Configuration. Manage fragment memory: Simplest method: Double buffer, On-demand, Fixed maximum size, By-index from array,...

22 struct fragment_t { uint32_t code_ea; // fragment's code EA uint32_t code_size; uint32_t entry_point; // in bytes, relative to code_ea uint32_t data_ea; uint32_t data_size; uint32_t pad[3]; }; // data in main RAM the fragment wants to process

23 Easy To Implement System Shader Configuration. Manage fragment memory: Alternate methods: Allocated, cached fragments (Lots of small shaders) Fixed locations (Offline analysis)... The best solution is specific to the system.

24 Easy To Implement Create the shader code... Code is just data Overlays or additional jobs are too complex and heavyweight. No special distinquishing feature on the SPUs Just want load and execute. No special system needed.

25 Easy To Implement Create the shader code.. Method 1: Shader as PPU header* Compile shader as normal, to obj file. Dump obj file using spu-objdump Convert dump to header using script. * This is what we're using now.

26 Easy To Implement Create the shader code.. Method 2: Shader as data Strip code from obj file and store as data. Put into data pipeline not code pipeline.

27 Easy To Implement Create the shader code.. Method 3: Use obj file Method 4: Use elf file Just pull code from obj file at runtime Requires extra compile step, but probably more debugger friendly. Other methods too, use whatever works for you.

28 Easy To Implement Calling the shader... Nothing could be easier. ShaderEntry* shader = (addr of fragment); shader( data, common );

29 Debugging Shaders Fragments are small Fragments have well defined inputs and outputs. Ideal for unit tests in separate framework. Test on PS3/Linux box.

30 Debugging Shaders Runtime debugging: Currently shaders have no debug info. Step through assembly. Often OK. Shaders are simple anyway, If written with intrinsics, not much difference. Alternatives: Debug on PPU (intrinsics are portable) Temporarily link in shader.

31 SPU Shader Rules Rule 1: Don't Manage Data for Shaders Just give shaders a buffer and fixed size. Shaders should depend on size, so leave room for system changes. Best size depends on system. (Maybe 4K, maybe 32K) Don't read or write from/to shader buffer. Insomniac Games, 2007

32 SPU Shader Data System-specific Shader-internal ( local ) Multiple list of instances to modify or transform Context data EA passed by system Fixed buffer Shader shared ( global ) EA passed by system Zero'd on system initialization Insomniac Games, 2007

33 SPU Shader Rules Rule 2: Don't Manage DMA for Shaders Give fixed number of DMA tags to shader Give DMA functions to shaders Grab them in the entry function and pass down) Avoid: GetDmaTagFromParentSystem() To allow system to run with any job manager, or none Don't use shader tags for other purposes Insomniac Games, 2007

34 SPU Shader Rules Rule 3: Enforce fixed maximum size for Shader code. System can be maintained. Rule 4: Shaders are always called in a clear, well defined context. i.e. Part of a larger system. Insomniac Games, 2007

35 SPU Shader Rules Rule 5: Fixed parameter list for shaders, persystem (or sub-system) Don't want to re-compile all shaders. Don't want to manage dynamic parameter lists. Rule 6: Shaders should be given as many instances as possible. More optimizable. Insomniac Games, 2007

36 SPU Shader Rules Rule 7: Don't break the rules. You'll end up with a new job manager. You'll end up re-inventing SPURS. You'll end up with a big headache. Insomniac Games, 2007

37 SPU Shader Guidelines Keep instance data contiguous Keep instance data separate from PPU data. Can pack/compress data. Don't fight with synchronization issues Keep shaders simple. Shaders should perform one simple tranformation (preferably branch-free) Switch shaders for new function. e.g. One shader per AI state. Insomniac Games, 2007

38 SPU Shader Guidelines Don't use globals in shaders. Requires code fixup Makes size less predictable Only use buffer provided by the system. Roll frequently used functions back into kernel Give space back to shaders. Insomniac Games, 2007

39 Integration with schedulers How are fragments scheduled? The aren't. The parent system is. Fragments are loaded and used on-demand. So, how is the parent system scheduled Enter SPURS rant..

40 Scheduling with SPURS SPURS... Wants to be a general purpose scheduler. Wants to solve all the allocation issues. Wants to be flexible for every possible case. Is overcomplicated. Is unnecessary. (With apologies to the SPURS team.)

41 Scheduling with SPURS How many parent systems are actually being scheduled? Dozens at best. Not thousands. There are always higher-level scheduling needs. Exactly like a general purpose memory allocator. Any scheduling needs, just like any dynamic memory needs, are going to be very simple. * Decide where in the frame the system will run, and for how long. Then stop.

42 Transitioning to Shaders Example from RCF: (FastPathFollower) Started with typical CPP update pattern: On PPU FastPathFollower* was Update instance All Updates called in a (sorted) list. (Sorted for icache hits) * Are classes derived from FastPathFollower Insomniac Games, 2007

43 Transitioning to Shaders Where there's one, there's more than one Grouped all FastPathFollowers together. Removed from Update list. Made single function to update all together. Update function now ignored. Insomniac Games, 2007

44 Transitioning to Shaders Know the inputs and outputs Most inputs were read-only Path update was read-write, but only here. Outputs: e.g. State (Exploded, Crashed, etc.) Animation (Change anim, frame, etc.) Collision database (Move, Update) A few more... Insomniac Games, 2007

45 Transitioning to Shaders Minimize Synchronization Points Collected all outputs to command buffers (Arrays of minimum data to execute) Advantage: Static cost limit Disadvantage: Always used space for worstcase (But small, so OK) e.g. Maximum number of exploded states e.g. Non-optional state changes need max instance count x command size. Executed command buffers after update. Insomniac Games, 2007

46 Transitioning to Shaders Minimize Synchronization Points Put FPF Update in separate PPU thread. Overlapped with standard Update hierarchy (Yes, time was completely swallowed but only because Update hierarchy has many dcache misses) Insomniac Games, 2007

47 Transitioning to Shaders Customization i.e. Proto-Shader Added callback function for customizations Moved all derived update functionality into callbacks. During update, registered callbacks placed into new command buffer for second pass. (Lose some dcache coherency, but overall better due to...) Insomniac Games, 2007

48 Transitioning to Shaders Limit Customization Static limit on custom callback command buffer size. So - Custom callbacks may not be called every frame. i.e. Selectively derived classes based on performance. (And can potentially select LOD callbacks.) Insomniac Games, 2007

49 Transitioning to Shaders Proto-Shader to Real Shader Now have async update on PPU with protoshader (w/ minimal code changes) Used as template for complete re-write: Today: AsyncMobyUpdate (Joe Valenzula) More generic (Not just one class) Update loop on SPU Lessons from Physics shaders And Joe's own contributions to the concept Insomniac Games, 2007

50 Use Cases Middleware as SPU Shaders Middleware can provide: i.e. SPURS is not the only solution to Middleware. PPU library (init, state changes, etc.) SPU shader(s) for update User provides: SPU entry (main) SPU LS buffer, dma tags, dma functions, and EA to main RAM data.

51 Use Cases Middleware as SPU Shaders Advantages: User can use any job manager (or none) Middleware is only does it's job. User in control of scheduling. Disadvantages: User spends less time bitching about SPURS....oh wait.

52 Use Cases System Pipeline Stage Management e.g. IgPhysics (Eric Christensen) Fixed pipeline, each stage as a shader. Shaders loaded in order by the kernel. Certain stages will themselves load shaders to manage specific data types. Result Completely deferred system, 2x speedup overall. (Mostly due to reduction of sync points)

53 Use Cases Others: Precondition data for GPU shaders Special Effects Animation Customizations Most PPU Code :)

54 Contact Info Mike Acton See also:

55 Credit Thanks guys for putting the SPU Shader ideas to the test and for your comments: Eric Christensen Joe Valenzuela Principal Engine Programmer Engine Programmer André De Leiradella Consultant for Engine Team

56 Credit Also thanks for the feedback from the guys on the Beyond3D CellPerformance forums: ebola, minty, patsu, Shifty Geezer (if just to tell me he didn't like the name), and LordOfThePing.