I've been wondering about this issue for a while. How to find the bottleneck of the graphical pipeline. Recently I've been using a program to draw massive amount of polygons in a simple scene with alpha blending (AKA grass scene). I've used two programs, one uses static coordinates and another uses rotation and translation. Both run at 60 FPS with no other heavy processes running. But when I use them together (Two windows each having same amount of grasses and grass positions) the one that uses translation and rotation runs at 10 FPS but the other one is about 55 FPS. My question is why are both running @ 60 FPS and when such thing happens why does the second one(Rotation and translation of each grass) drop about 50 FPS but the second is still 55? Sounds like a bottle-neck to me. Please let me know if you have any idea, or in a more general answer if you have an idea or paper about finding bottleneck of GPU(or GPGPU), or optimizing the graphical code for running on GPU?
-
\$\begingroup\$ Are you sure it's not the CPU? I would profile anyway to see where your time is spent. \$\endgroup\$– PrettyPrincessKitty FSMay 26, 2011 at 11:23
-
\$\begingroup\$ No i'm almost sure. I have no operations around CPU and on many computers I have tested. \$\endgroup\$– Amir ZadehMay 26, 2011 at 11:59
-
3\$\begingroup\$ What do you mean when you say you have "two programs" running? Is it separate processes that has separate windows? Or do you use two libs to draw into one OpenGL context? \$\endgroup\$– voidMay 26, 2011 at 13:19
-
1\$\begingroup\$ Draw calls can use up a lot of CPU time. E.g. on the XBOX 360, 500 draw calls per frame can easily eat up all of your CPU time. You can be CPU bound with very little apparent "operations" being done on the CPU. \$\endgroup\$– OlhovskyMay 27, 2011 at 0:32
-
1\$\begingroup\$ Learn to create paragraphs :) (No offense, it would just help people like me actually read the question.) \$\endgroup\$– OlhovskyMay 27, 2011 at 0:32
3 Answers
The general answer is to do a frame capture and profile. Use something like NV PerfHUD or other GPU performance counters to see what the GPU is doing, and which draw calls takes time. You can then get information about what the bottle neck that draw call had.
Your case seems to be something like two programs interacting and context switching the GPU?
-
\$\begingroup\$ I guess exactly as you said there are alot of switches but why aren't they 50-50 (%)? one decreasing to 55 and another to 10?? \$\endgroup\$ Jun 7, 2011 at 19:10
-
\$\begingroup\$ @Green Code A lot of times the driver is optimized for a special case, where you only have one accelerated app running. The might be some internal scheduling problem you are hitting, or the driver might just go into panic mode and do everything "safe" for one of your apps (seen that happen before when using multiple context in one app). GL drivers (and 3D drivers in general) are quite fragile and you have to be careful in hitting just the good/fast paths. I would suggest using only a single context if you are not really carefull about buffer management. And render to back buffer from one only. \$\endgroup\$– voidJun 8, 2011 at 6:18
You can find some information in these materials:
Randima Fernando. GPU Gems: Programming Techniques, Tips and Tricks for Real-Time Graphics. Addison-Wesley Professional, 2004. Chapter 28
David Blythe, Brad Grantham, Tom Mcreynolds, and Scott R. Nelson. Advanced Graphics Programming Techniques Using OpenGL. Course Notes for SIGGRAPH ’99. ACM, 1999.
-
\$\begingroup\$ developer.download.nvidia.com/books/HTML/gpugems/… \$\endgroup\$ Dec 13, 2018 at 12:13
both running at 60FPS doesn't neccesorily mean they can both run with the same speed, there is usually a fps limiter in game engines that doesn't let fps go higher than 60fps (and that's somthing you can spot that and remove easily), so in your case maybe without this limiter the static fps wuold be around 120 and the dynamic one would be around 70, with them both running gpu can't handle both processes, assuming that your test shows even half of gpu's power is almost enough for static scene, but isn't near enough for dynamic one. and if you want to find bottleneck in your pipeline ,assuming that you have access to all your shaders source codes, you can use "nvidia fx composer". in that program you can draw your pipeline, give it all your shaders and it'll show how much time is consumed in each stage for each shader.
