![/* Welcome! */ ,[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à SPU Assisted Rendering
Similaire à SPU Assisted Rendering (20)
Dernier
Dernier (20)
SPU Assisted Rendering
- 1. /* * SPU Assisted Rendering. */ Steven Tovey & Stephen McAuley Graphics Programmers, Bizarre Creations Ltd. steven.tovey@bizarrecreations.com stephen.mcauley@bizarrecreations.com http://www.bizarrecreations.com
- 3. Car Lighting
- 5. /* * Part I w/ Steven Tovey */ SPU Acceleration of Car Rendering in Blur
- 7. Why do this?Free up RSX™ to do other things. Enable otherwise unfeasible techniques. Optimise rendering. /* What is SPU AR? I */
- 12. Local store
- 14. Etc./* What is SPU AR? II */
- 17. 2xVTF (volume & 2D) for damage.
- 18. Large amount of work in vertex shader, making cars in Blur heavily vertex-bound.
- 19. All lighting in pixel shader./* Case Study: Cars I */
- 25. Increase rendering speed of cars.
- 26. Maintain same quality./* Case Study: Cars VI */
- 28. Large parts are SPU based.
- 29. On demand.
- 30. Sync-free.
- 31. Deferred.
- 32. Work split between GPU/SPU./* Damage: Solution */
- 34. Read-only car vertex data.
- 35. Shared between similar cars.
- 36. SPU-modified damage vertex data.
- 37. Per instance.
- 38. One-to-one mapping of vertices.
- 39. Control points:
- 40. Crude approximation of volume preservation.
- 41. Dent/scratch blend levels./* Damage: Data I */
- 42. /* Damage: Data II */ Stream0 Stream1 Position SPU_Position Normal UV0 SPU_Normal UV1 PosOffset NormalOffset ControlPoints AO
- 43. /* Damage: Data II */ Stream0 Stream1 Position SPU_Position Normal UV0 SPU_Normal UV1 PosOffset NormalOffset ControlPoints AO
- 44. /* Damage: Data II */ Stream0 Stream1 Position SPU_Position Normal UV0 SPU_Normal UV1 PosOffset NormalOffset ControlPoints AO
- 45. /* Damage: Data II */ Stream0 Stream1 Position SPU_Position Normal UV0 SPU_Normal UV1 PosOffset NormalOffset ControlPoints AO
- 46. /* Damage: Data II */ Stream0 Stream1 Position SPU_Position Normal UV0 SPU_Normal UV1 PosOffset NormalOffset ControlPoints AO
- 47. /* Damage: Data II */ Stream0 Stream1 Position SPU_Position Normal UV0 SPU_Normal UV1 PosOffset NormalOffset ControlPoints AO
- 48. /* Damage: Data II */ Stream0 Stream1 Position SPU_Position Normal UV0 SPU_Normal UV1 PosOffset NormalOffset ControlPoints AO
- 50. If vertex format is 16 bytes exactly can atomically change a vertex from SPU.
- 51. If you can live with the odd vertex being wrong for a frame, this could be a huge win!/* Damage: Data III */
- 52. /* Damage: Data IV */ SPU RSX Local Main Write-only Vertices Read-only Vertices
- 54. Note: There is no link to the player health, purely superficial./* Damage: Events */ Impact Impact Game Code Impact Impact Impact Impact
- 55. /* Damage: Data V */ Impact Impact Impact Constants Impact Impact Impact SPU GPU Write-only Vertices* Read-only Vertices* * - w.r.t to SPU
- 56. /* Damage: Data VI */ SPU GPU Write-only Vertices* Read-only Vertices* * - w.r.t to SPU
- 65. We favour si style for simplicity and ease./* de-code into IEEE754-ish 32bit float (meh): */ qword sign_bit = si_and(result, sign_bit_mask); sign_bit = si_shli(sign_bit, 0x10); /* move 16 bits into correct place. */ qword significand = si_and(result, mant_bit_mask); significand = si_shli(significand, 0xd); qword is_zero_mask = si_cgti(significand, 0x0); /* all bits set if non-zero. */ expo_bias = si_and(is_zero_mask, expo_bias); qword exponent_bias= si_a(significand, expo_bias); /* move expo up range, 0x07800000=>0x3f800000. */ exponent_bias= si_or(exponent_bias, sign_bit); /* Damage: SPU I */
- 67. GPU version relied on bilinear filtering of volume texture to smooth damage.
- 68. Filtering on SPU is a bit of a pain.
- 69. Working out which events affect which vertices?/* Damage: SPU II */
- 72. 1. Get data in volume texture-ish format.
- 73. 2. Apply x-form to all vertices./* Damage: SPU III */
- 76. Some interesting instructions in ISA will help here./* Damage: SPU IV */
- 80. We added some of the per-vertex lighting calculations for brake lights, for example./* Damage: Lessons III */
- 81. /* Damage: Results */
- 84. 40 in total (accounting for double buffer).
- 85. 8x8 per face.
- 86. Deferred.
- 87. Work split between GPU/SPU.
- 88. Cars are lit with a mixture of things:
- 89. SH (world + dynamic)
- 91. Vertex lighting/* Lighting: Solution */
- 94. Output:
- 95. Cube map.
- 96. Simples!/* Lighting: Data */ Light SPU Light Cube map Light Light Light Light
- 98. Cube maps are double buffered to avoid artefacts and contention with GPU.
- 100. Number of cube maps per task can change dynamically if need be./* Lighting: Control */
- 103. /* Lighting: Results I */
- 104. /* Lighting: Results I */
- 105. /* Lighting: Results I */
- 106. /* Lighting: Results II */
- 107. /* Lighting: Results II */
- 108. /* * Part II w/ Steve McAuley */ SPU Acceleration of Fragment Shading
- 110. /* The Pipeline */ Vertices Vertex shader Triangle setup Rasterisation Textures Fragment shader ROP
- 114. /* Light Pre-Pass */ Geometry Normals Final Colour Geometry Real-Time Lighting Depth
- 115. /* A Frame of Blur */ Solid Alpha Post Pre-Pass Lights Mirror, Cube Map & Reflection GPU:
- 122. /* Step #1: The Data */ Normal X Normal Y Depth Hi Transform Depth Lo Lights
- 124. Divide the frame buffer into tiles.
- 125. Each tile is a unit of work./* Step #2: Jobs */
- 128. /* Step #3: Sync */ Solid Alpha Post Pre-Pass Mirror, Cube Map & Reflection GPU: Lights SPUs:
- 129. /* Step #3: Sync */ Solid Alpha Post Pre-Pass Mirror, Cube Map & Reflection GPU: Lights SPUs:
- 130. /* Step #3: Sync */ Solid Alpha Post Pre-Pass Mirror, Cube Map & Reflection WriteLabel GPU: Lights SPUs:
- 131. /* Step #3: Sync */ Solid Alpha Post Pre-Pass Mirror, Cube Map & Reflection WriteLabel GPU: Lights Wait on Label SPUs:
- 132. /* Step #3: Sync */ Solid Alpha Post Pre-Pass Mirror, Cube Map & Reflection WriteLabel GPU: Lights Wait on Label SPUs:
- 133. /* Step #3: Sync */ Solid Alpha Post Pre-Pass Mirror, Cube Map & Reflection WriteLabel Jump To Self GPU: Lights Wait on Label SPUs:
- 134. /* Step #3: Sync */ Solid Alpha Post Pre-Pass Mirror, Cube Map & Reflection WriteLabel GPU: Lights Wait on Label SPUs:
- 136. Cull an entire tile if:Depth min and max are both far clip. No lights intersect. /* Step #4: Culling */
- 137. /* Step #5: Light! */
- 140. - Array-of-structures: 1 dot product, 23 cycles qword d0 = si_fm(xyz0, abc0); qword d1 = si_rotqbyi(d0, 0x4); qword d2 = si_rotqbyi(d0, 0x8); qword dot = si_fa(d0, d1); dot = si_fa(dot, d2); - Structure-of-arrays: 4 dot products, 18 cycles qword dot0123 = si_fm(x0123, a0123); dot0123 = si_fma(y0123, b0123, dot0123); dot0123 = si_fma(z0123, c0123, dot0123); /* Step #6: Optimise! */
- 143. Slightly faster than the RSX.
- 144. An optimisation even if you have nothing to parallelise with!/* Case Study: Lighting */
- 145. /* Case Study: Lighting */
- 146. Lighting Damage Rendering Physics /* The Complete Picture */
- 148. /* Further Reading */ - Steven Tovey & Stephen McAuley, “Parallelized Light Pre-Pass Rendering with the Cell Broadband Engine”, GPU Pro - Stephen McAuley & Steven Tovey, “A Bizarre Way to do Real-Time Lighting”, Develop in Liverpool 2009
- 149. If you’re talented, then we’re hiring ;) jobs@bizarrecreations.com
- 150. lqd $r1,question_count stopd $r0,$r0,0x1 ; thanks for listening! ;) brnz $r1,questions
Notes de l'éditeur
- Local space position of vertex
- Normal
- Couple of sets of Uvs.
- Morph-targets.
- Control point index into an array of curves.
- Spherical Harmonic
- Damage data... Position offset, Normal offset, scratch and dent levels.
- Explain why 16KB chunks, MFC max per transfer.
- Don’t want lumpiness if parallel read/write.
- Don’t want lumpiness if parallel read/write.
- Rim lighting here.
- Tyres use low-power specular.
- Brake lights.
- Used on alloys for low-power specular.
- Used for the scratch lighting, again for low-power specular.
- We need to look at the pipeline of the graphics card to work out how we can move more of our GPU work onto the SPUs. Two main areas we can insert data – either through vertices at the top, or textures at the fragment stage. Sadly, we can’t hook into the rasteriser, which would be ace.
- Of course, these look-up textures end up being screen-space look-up textures, which means some sort of deferred rendering…
- I have a problem with forward rendering. I think most people traditionally design their engine this way, especially on 360 and PC. But all the work is done in the fragment shader, so when you port to the PS3 with a slower fragment shader unit, your whole game runs slower. Although you can use EDGE to speed up your vertex processing and your post processing, they both only step around the core of the issue that you’re fragment shader bound and there’s no easy way of solving it.
- We found a light pre-pass renderer suited our goals pretty well. It’s a halfway house between traditional and deferred rendering.
- We render a rear-view mirror, cube map reflections for the cars and planar reflections for the road and water in addition to the pre-pass and main views. Multi-threaded rendering helps a lot!
- Deferring by a frame isn’t ideal. Either you just use the previous frame’s lighting buffer for the next frame, with obvious artefacts (especially if you’re doing a racing game like us), or you have to add a frame of latency.I don’t think adding frames of latency is ideal, especially for cross-platform games. If you add a frame of latency on the PS3, are you going to do the same on the 360? If you’re not, then game play could be different between both platforms.I’m not saying this is something I’d never do, I think in lots of circumstances you’ll have to. But avoid it where you can, and this is one instance.
- If we wanted to take this further for future projects, we could add shadow maps in at the start of our pipeline, then do an exponential blur on the SPUs whilst we’re rendering the pre-pass geometry…
- This is real multi-threaded graphics processing, with multiple processors doing different jobs at the same time. Therefore, architect your engine accordingly!Having small graphics jobs allows you to spread the workload. Obviously, not everything can be done like this. Some things will most likely have to be deferred a frame, adding a frame of latency, such as post-processing or MLAA. But there’s lots of tasks, smaller tasks, that don’t have to be, from SSAO to blurring exponential shadow maps. You have to find things to parallelise with!Think about the data again! Rendering has lots of stages, each with its own inputs and outputs. What could sync with what?
- We combine the normals and depth into one 32-bit buffer. This is an optimisation as it halves the inputs into the SPU program, but also allows us to keep the depth buffer in local memory which is good for performance.
- The first step, but the biggest stumbling block!
- No blocking! Our jobs are optionally dependent on a label.
- To be accurate, we have a jump-to-self per SPU.
- When we load in a tile, we quickly iterate over every pixel and calculate minimum and maximum depth.No need to use a stencil buffer to cull out the sky as depth min and max will do it for us. (Remember, we don’t have the stencil buffer as we’re not using the depth buffer!)This technique is really useful for a variety of things, including depth of field (check out Matt Swoboda’s optimisation in PhyreEngine).
- This is actually the easiest bit. Just write the lighting equations in intrinsics! However, they really have to be fast otherwise performance just won’t be good enough. Next is some helpful tips for optimisation.
- So we triple buffer. It ends up that we have plenty of local store left as it’s simple job and our job size was relatively small. Another reason to write in siintrinsics though as it keeps the code size down!
- Just like Ste said earlier, this is a big win. Probably a good rule of thumb for most SPU jobs!
- Just like Ste said earlier, this is a big win. Probably a good rule of thumb for most SPU jobs!
- When kicking SPU jobs off on the RSX, you have to be careful as you can interfere with jobs the PPU is running. This is where sync-free systems are a win! We’re lucky as we just avoided the physics, but also, running only on 3 SPUs was a good idea so we had 3 free for other tasks. See how quick the rendering is even though we’re rendering so many views!
- Apologies for the shameless self-promotion!