An Incremental Rendering VM. Georg Haaser, Harald Steinlechner Stefan Maierhofer, and Robert F. Tobler VRVis Research Center Vienna, Austria

Transcription

1 , Harald Steinlechner Stefan Maierhofer, and Robert F. Tobler VRVis Research Center Vienna, Austria

2 Motivation Rendering huge scenes with dynamism Editor applications / strategy games Everything is changeable (add / remove / modify) Changes are relatively rare Problems Many driver calls Driver calls impose cost (e.g. redundancy, validation) Hardware not utilized 2

3 Typical approaches Static Re-organize the scene (e.g. grouping) Merge geometries Render caches (e.g. Durbin et. al. 1995) Difficult to update Dynamic Filter redundant API calls State sorting (e.g. sort by shaders) Runtime overhead 3

4 Ultimate Goal Dynamic flexibility without compromising performance 4

5 Minimal frontend Expected input Set of Render Objects Order independent Render Objects Draw call arguments Stateless Render Object State Shaders Modes (BlendMode,...) IndexBuffer Vertex Attributes Instance Attributes Uniforms DrawCall Arguments 5

6 How to render those objects? track changes {s 1, t 2, b 2 } {s 1, t 1, b 1 } {s 2, t 3, b 3 } sort by state prune & execute commands per frame 6

7 State Sorting Optimal order Costs for all transitions (shaders, textures, etc.) Minimize total cost Incremental changes? Cannot maintain optimality State-trie turns out to be effective Easy to update 7

8 s 1 s 2 t 1 t 3 b 1 b 3 shaders textures buffers {s 1, t 1, b 1 } {s 2, t 3, b 3 } 8

9 {s 1, t 2, b 2 } s 1 s 2 t 1 t 3 b 1 b 3 shaders textures buffers {s 1, t 1, b 1 } {s 2, t 3, b 3 } 8

10 {s 1, t 2, b 2 } s 1 s 2 t 1 t 3 b 1 b 3 shaders textures buffers {s 1, t 1, b 1 } {s 2, t 3, b 3 } 8

11 {s 1, t 2, b 2 } s 1 s 2 t 1 t 2 t 3 b 1 b 3 shaders textures buffers {s 1, t 1, b 1 } {s 2, t 3, b 3 } 8

12 s 1 s 2 t 1 t 2 t 3 {s 1, t 2, b 2 } b 1 b 3 shaders textures buffers {s 1, t 1, b 1 } {s 2, t 3, b 3 } 8

13 s 1 s 2 t 1 t 2 t 3 {s 1, t 2, b 2 } b 1 b 2 b 3 shaders textures buffers {s 1, t 1, b 1 } {s 2, t 3, b 3 } 8

14 s 1 s 2 t 1 t 2 t 3 b 1 b 2 b 3 shaders textures buffers {s 1, t 1, b 1 } {s 1, t 2, b 2 } {s 2, t 3, b 3 } 8

15 Reduce runtime costs track changes {s 1, t 2, b 2 } {s 1, t 1, b 1 } {s 2, t 3, b 3 } sort by state prune & execute commands per frame 15

16 Reduce runtime costs track changes {s 1, t 2, b 2 } {s 1, t 1, b 1 } {s 2, t 3, b 3 } sort by state prune & execute commands per frame Success: less stuff at runtime! 15

17 Idea: Graphics commands are data too Instructions describe graphics commands Decouple creation and execution Examples SetShaderInstruction(5) DrawInstruction(Lines, 0, 100)... 17

18 Idea: Instructions are data too generate instructions optimize execute prune & execute commands 18

19 {s 1, t 1, b 1 } {s 1, t 2, b 2 } SetShader(s 1 ) SetTexture(t 1 ) SetBuffer(b 1 ) Draw() SetShader(s 1 ) SetTexture(t 2 ) SetBuffer(b 2 )) Draw() 19

20 Reduce runtime costs generate abstract instructions redundancy removal per frame execute 20

21 Reduce runtime costs generate abstract instructions redundancy removal execute Success: less stuff at runtime! per frame 20

22 But... How to efficiently execute optimized instructions? 22

23 Interpreter techniques Switch interpreter Managed / Unmanaged Employed by Wörister et al Indirect threaded code Array of function pointers Direct threaded [Bell 1973] Compile the whole list of fragments Baseline for performance (changes are expensive) 23

24 No overhead! Native compilation SetShader(s 1 ) SetTexture(t 1 ) SetBuffer(b 1 ) Draw() SetTexture(t 2 ) SetBuffer(b 2 ) Draw() Just-in-time compilation Executable memory 0xEAF1 MOV EXC, 0xb44 MOV RAX, 0x7f CALL RAX JMP 0xFEED 0xFEED MOV EXC, 0xe44 MOV RAX, 0x5a CALL RAX JMP 0xDEAD 24

25 Time per Instruction Benchmark: fake driver 45 ns 40 ns 35 ns 30 ns 25 ns 20 ns 15 ns 10 ns 5 ns 0 ns 0k 50k 100k 150k 200k 250k Instruction Count Direct Threaded Ours (sequential) C# switch C++ switch 25

26 Benchmark: real driver Radeon HD 7970, AMD FX-9590 GTX 680, Intel i % 100% 80% 80% 60% 60% 40% 40% 20% 20% 0% switch no-opt switch runtime opt switch static opt Ours 0% switch no-opt switch runtime opt switch static opt Ours (Average relative framerate) 26

27 Benchmark: other engines Architecture (7022 objects) 27

28 Benchmark: other engines Sponza24 (9408 objects) 27

29 Benchmark: other engines HugeCity (6580 objects) 27

30 Windows Linux Benchmark: other engines Sponza24 HugeCity > 200 ms Architecture Sponza24 HugeCity > 200 ms Architecture 0 ms 10 ms 20 ms 30 ms 40 ms 50 ms 60 ms 70 ms 80 ms Frame Time Ours Unity 4.6 Open Scenegraph 30

31 What we achieved incremental changes State trie Instructions JIT Compiler per frame Execution 31

32 Time per Change Costs & Outlook Costs Compilation overhead still more than 2000 changes/s Platform dependent compiler Outlook NV_command_lists, Mantle, DirectX 12, etc. SceneGraph frontend Driver integration anyone? Order dependent rendering 0,5 ms 0,4 ms 0,3 ms 0,2 ms Number of Render Objects C++ Ours 32

33 Thank you for your attention! Please visit us at