There are two lights in the scene: one infinite (directional) light, and one spotlight casting from the lighthouse.

Transcription

1 Sample Tweaker Ocean Fog Overview This paper will discuss how we successfully optimized an existing graphics demo, named Ocean Fog, for our latest processors with Intel Integrated Graphics. We achieved a 4x boost in performance (40 FPS to 160 FPS) with very little to no fidelity loss by applying techniques such as reducing texture sizes and lowering precision. These optimization techniques are not revolutionary by any means, but knowing when to apply them can be a bit more involved. To help us identify where we might be able to optimize, we used Intel s graphics profiler, called Intel Graphics Performance Analyzers or Intel GPA for short. We will use screenshots of Intel GPA to show how we identified a graphics bottleneck and then detail how we tried to optimize or fix those problem areas. Understanding the architecture that you are optimizing for can really help you in deciding how to fix problem areas. Intel GPA allows you to run different tests against problem areas to help identify the problems and possible fixes without an intimate knowledge of the architecture. In this paper, you will see that our tests are labeled as 2x2 textures or simple pixel shader. Those tests are built into Intel GPA and are not something that a person would have to modify themselves in the existing application. The purpose of the original Ocean Fog project was to investigate how to effectively render a realistic ocean scene on differing graphics solutions while trying to provide a good, current, working class set of data to the graphics community. The ocean was rendered by using a projected grid that is displayed orthogonally to the viewer. The vertices of the grid are displaced using a height field. Perlin noise was used for generating wave motion. In the original paper, the author notes that computation Perlin noise was less CPU-intensive than other methods. However, other methods like Navier- Stokes work better on the GPU side and the author mentions it is worth further investigation. Snell s law was used for reflection and refractions. For more information on how the water was rendered, please see Claes Johanson s Master s thesis, Real-time water rendering - Introducing the projected grid concept. The fog was also generated using Perlin noise. The processing for the fog was also done on the CPU side. This was done by sampling points in the 3D texture space. There are two lights in the scene: one infinite (directional) light, and one spotlight casting from the lighthouse. For further discussion please see: Ocean Fog using Direct3D 10. Optimization Summary The original application was running at 40 FPS on our test hardware 1 ; after all optimizations, it was running 4x faster at 160 FPS. CPU utilization went from 8% to 84%, GPU active time from 32% to 85%, and GPU stall time from 53% to 9%. 1 We used 3 systems. First, an Intel microarchitecture codename Sandy Bridge processor-based platform with a 2.4Ghz processor running 64-bit Microsoft Windows* 7, 4GB of memory and an 80GB solid-state disk. Second, an Intel Core i5 640 processor-based platform with a 3.2Ghz processor running 32-bit Microsoft Windows Vista*, 2GB of memory and a Seagate* 7200RPM 500GB disk. Third, an Intel Core 2 Duo T7700 processor-based system with a 2.4Ghz processor running 64-bit Microsoft Windows* 7, 4GB of memory, an 80GB solid-state disk, and an NVIDIA Quadro* FX-570 graphics card 1

2 The largest slowdown on the application was the generation and shading of the water. Optimizations included normal map size and depth reduction, reflection and refraction size and depth reduction, code and resource cleanup, and rendering fixes. Output Figure 1 - Ocean Fog Results Final Results (msec/frame) Sandy Bridge Intel Core i5-661 with Intel HD Graphics Intel Core TM 2 Duo T7700 with an NVIDIA Quadro* FX 570M card Original Optimized Intel microarchitecture codename Sandy Bridge showed 4x improvement over original. Below are side-by-side screenshots of the Intel GPA System Analyzer application before and after optimizations. The application has several line charts that show the activity levels of the CPU and GPU. The first line chart (at the top) 2

3 shows the frame rate. The second chart down shows the CPU utilization by processor. The third chart down shows the GPU EU active % time, which is roughly the utilization of the GPU. The fourth chart down is the GPU % busy time, which is the GPU active time plus the GPU stalled time. The fifth chart down is the GPU % stalled time. Stalls are a general bucket that could refer to many conditions. For example, you could be stalled on a texture fetch from the sampler, or a vertex fetch from main memory. As you can see here, the application is stalled on the GPU a good percentage of the time and is hardly utilizing any of the CPU or GPU. This is typically a good sign if you are looking to see whether there are possible optimizations. Original No Overrides Original vs. Optimized Optimized No Overrides Significant increase in GPU percent active time and significant decrease in GPU percent stalled time. 3

4 Below are side by side screenshots of the Intel GPA Frame Analyzer tool. The tool can show the performance of each individual draw call (named erg in the tool) and allow you to try experiments to see how you might be able to improve that particular draw call. Ergs that take longer are represented by taller bars in the bar chart, so those are generally a good place to start. It is hard to tell, but if you look at the Y-scale numbers of the bar chart, you will notice the biggest erg went from over 12,000 microseconds to around 2500 microseconds. Original Original vs. Optimized Optimized The two largest ergs went from 62.5% of scene time to 35.7% of the scene time. 4

5 Next is another side-by-side screenshot of Intel GPA System Analyzer. This time we compare the original profile against 2x2 textures. 2x2 textures is an override in the tool that causes all textures to be used in the GPU to be a simple 2x2 texture. This is a good way to know whether you are stalled due to size of your textures. You ll notice below that the GPU stalled time (bottom chart) goes from around 57% down to 17% with 2x2 textures. This tells us that our textures are too big for our sampler cache to hold efficiently. No Overrides Original 2x2 Textures Note: The Core i5-661 processor-based system with Intel HD Graphics showed similar results 5

6 Performance Analysis Overview Intel GPA System Analyzer showed nearly 60% stall time initially. Using 2x2 textures override showed the greatest reduction of GPU stall time, to about 17%. Normal Map Generation Calculation of water normal map (1024x2048 RGBA 32 bit) Pixel Shader takes substantially more time. Optimizations Scaling water normal map The water normal map took about 32 MB to generate and was shown in Intel GPA Frame Analyzer to be the most costly erg. Remember the tall yellow line that went from 12,000 microseconds to 2500 microseconds in the side-by-side screen shot of Intel GPA Frame Analyzer? This is what it actually represents in the scene. We experimented by changing the size of the normal map to see how it affected performance and visual fidelity. Our goal throughout optimization was to preserve visual fidelity as much as possible. In the table below, you will notice that reducing the size of the normal map greatly reduced the time of that erg. Looking at the 3 side-by-side screenshots of the water, you will notice some falloff in visual fidelity based on the reduction in size. Normal Map Build Resolution msec/frame Original 1024x Optimized 1024x Optimized 512x Optimized 256x Figure 2 - Normal map sizes: 1024, 512, 256 6

7 In conjunction with other water noise settings (falloff, scale), we were able to get the quality to look almost as good as the original 1024x2048 normal map without the frame rate penalty while maintaining the crisp water effect. Figure 3 - Normal map: 1024 vs. 256 Settings Tweaked 7

8 Water Shading In the Intel GPA Frame Analyzer side-by-side screenshot below, we are showing the before and after of applying the 2x2 textures experiment within the tool. This erg is definitely texture-bound. Before 2x2 Textures Experiment After After 2x2 Textures experiment, there was 32.2% less GPU time After performing Intel GPA Frame Analyzer s 2x2 Textures experiment, it was shown there was a 32.2% improvement on GPU time. Additionally, the textures in the pipeline were inspected. The reflection, refraction, and normal map were 32- bit textures. So the optimizations here would be reducing the size and depth of the textures without losing much fidelity. 8

9 Figure 4 - Graphics Pipeline showing 32-bit textures Water.fx sampled textures in pixel shader, Original Build Type Description Resolution Depth TextureCube Environment 1024 x 1024 x 6 8 bit Texture3D Fog 50 x 50 x 50 8 bit Texture2D Fresnel 256 x 1 8 bit Texture2D Normal 1024 x bit Texture2D Refraction 512 x bit Texture2D Reflection 512 x bit Optimizations Reflection, refraction and normal maps were changed from 32-bit to 16-bit textures and their changes to the FPS were noted. Reduction of reflection and refraction maps showed the greatest improvement, followed by using 16-bit depth. Texture depth changes (msec/frame) Reflection/Refraction Map Normal Map RGBA 32 bit RGBA 16 bit Reflection/Refraction Map Dimension change (msec/frame) Reflection/Refraction Map 512x512, RGBA 32 bit x256, RGBA 32 bit x256, RGBA 16 bit Both map reduction and 16 bit depth provided 1.5x improvement The depth change from 32-bit to 16-bit showed a slightly grainier normal map. The reflection and refraction dimension reduction to 256x256 showed a pixelated reflection/refraction map only when there was zero wave amplitude, and thus no water distortion. However, after any wave amplitude or water distortion, the pixelation could not be seen; along with the addition of fog, the difference between the image fidelities could not be seen anymore. 9

10 Figure 5 - Reflection/Refraction Map 32bit vs 16 bit Figure 6 - Reflection/Refraction Map - 256x256 vs. 512x512 Next, the skybox (1024x1024x6) was replaced with a smaller version (256x256x6), and because of the gradient and unfocused nature of the texture, there was no change in fidelity. There was about a 3% FPS increase with all other objects turned off in the scene. 10

11 Figure x1024 vs 256x256 Cubemap 11

12 Miscellaneous Optimizations Removing unnecessary clear calls The clearing of the reflection and refraction render targets were disabled when they were unchecked from the GUI. This gave a frame boost from 52 FPS (water render only) to about 73 FPS. When everything else was rendered in the scene, the frame rate dropped when reflection was disabled; however, this behavior was also observed with the original build. Clearing must be done at every frame because as the camera moves, the reflection and refraction map must change. MIP Generation Generating the additional MIP levels for the normal map did not show a significant change in FPS, but we thought it might help, so we tried the experiment anyway. MIP generation (msec/frame) Normal Map Size MIPs 1024x2048, 32 bit 1024x2048, 16 bit 256x512, 16 bit One All eight levels Offloading GPU work One possible optimization would be moving more work from the GPU because the CPU is not being fully utilized. The two largest shaders that compute the height and normal map were disabled, which showed about a 14% increase in frame rate. One possible implementation would to pass normal and height map information, generated on the CPU, along with the rest of the vertex data. This could also greatly reduce frame time, but we thought it might be an interesting experiment that we didn t have time to try. Disabling Shader work (msec/frame) Normal Map Size 256x x2048 GPU Work No GPU Work Summary We achieved a 4x performance improvement in this application by using Intel GPA to help us identify the GPU bottlenecks and possible solutions. This application was stalled mainly on textures, so reducing the size and precision allowed us to gain some substantial performance. In doing so, we lost some minor visual fidelity, and in some cases we mitigated that loss by varying other simulation parameters. The optimizations that we did should be considered on a case-by-case basis, because sometimes you might need that extra precision or even fidelity to convey to the user what is visually important in your application or game. The technique and tools we used can be applied to any graphics application to troubleshoot performance problems, so you should consider those on your next optimization adventure. About the Author Jeff Laflam is a software engineer in the Intel Software and Services Group, where he supports Intel graphics solutions in the Visual Computing Software Division. 12

13 Optimization Notice Refer to our Optimization Notice for more information regarding performance and optimization choices in Intel software products. 13

14 Appendix General Procedure Various application overrides were created such as disabling the water, island, lighthouse spot light, clouds, and sky (Fig. 12). It was found that disabling the water showed the greatest improvement in frame rate. The application overrides were used in conjunction with Intel GPA. Slowdowns were further narrowed down through Intel GPA System Analyzer, showing that 2x2 textures override marked the greatest frame improvement. Finally, Intel GPA Frame Analyzer was used to pinpoint the exact ergs in which the slowdowns occurred. Additionally, Intel GPA Frame Analyzer allowed 2x2 textures experiment and texture information in the pipeline, which allowed better measurement of what was being used in the erg. Figure 8 - Application Overrides 14

15 Final Results Miscellaneous Original 2x2 Textures vs. Optimized Original 2x2 Textures Optimized - No Overrides Optimized version shows better results than the original s 2x2 textures override. Textures There are 27 textures (29.5 MB) in the textures folder. The skybox, cubemap-newer.dds, is 24 MB of the total. There are additional textures procedurally generated at the beginning. First is the fog texture, which is a 50x50x50 8-bit texture. The application takes up about MB of memory before starting (before optimizations). This can be from file reads, texture generation, and various inefficiencies. Other textures need to be adjusted for proper use, as some are too large or small for their surface. 15