• Advertisement

Archived

This topic is now archived and is closed to further replies.

Bottleneck detection

This topic is 5266 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I posted this in the NeHe forum but didnlt have much luck, so here it is again... I was wondering what methods there are for detecting the bottleneck in an OpenGL program? It''s out of personal interest for future reference, but I thought it''d make interesting reading for anyone else here if we compile a summary. The one I can think of is running the app in a window and resizing it. If decreasing the size of the window increases the framerate, the program is fill-rate limited, and is probably suffering from overdraw. AFAIK, a possible remedy is to draw the nearest objects first and let the depth-buffer do some culling. Alternatively just do anything to reduce the number of polys (space partitioning etc). I''m fairly new to this so I welcome any corrections to the above! What other tests are there that might show a bottleneck?

Share this post


Link to post
Share on other sites
Advertisement
If you're using Microsoft Visual C++ 6.0/.NET, then you have an option called profiling. Basically, you enable profiling, run your program, and after it closes, MSVC creates a list of the functions your program called and how long (in milliseconds) it took each of them to execute.

To enable profiling, open Project->Settings... and navigate to the Link tab. Check the checkboxes marked "Enable profiling" and "Generate mapfile". Then, compile your program, and click Build->Profile... Make sure "Function timing" selected. It helps if you split your program into functions, so then you can see which function is taking the most time to run. That's your bottleneck.

As regards OpenGL: it's always best to send as few vertices to the GL as possible. Frustum culling can increase a program's speed exponentially by not drawing polygons which are out of the frustum. Likewise, BSP, octree or quadtree systems also limit the number of polygons being sent to OpenGL. However, the depth buffer won't help at all with polygon culling and program speed. The depth buffer is there to sort which pixels of which polygons are actually visible to the user at a given position. Even polygons which are completely hidden by others still have to have their vertices processed by OpenGL. Just because they're not visible doesn't mean they're not there...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on August 19, 2003 7:48:17 AM]

Share this post


Link to post
Share on other sites
Is there a profiling tool in VS.NET? I haven't found it?!

NVidia has some docs for increasing performance and detecting bottlenecks. It can be found at their developer site:

http://developer.nvidia.com/docs/io/4000/GDC2003_OGL_Performance.pdf

http://developer.nvidia.com/docs/io/4000/GDC2003_PipelinePerformance.pdf

[edited by - ALiENiD on August 19, 2003 8:01:26 AM]

Share this post


Link to post
Share on other sites
The profiler is part of Visual C++.Net, not Visual Studio.Net in general.

Share this post


Link to post
Share on other sites
Where can it be found? I don''t have any Profiling option in my Build or Debug menus...

Share this post


Link to post
Share on other sites
Maybe you''re using one of the stripped down versions? Like say, evaluation edition, educational edition or other?

Share this post


Link to post
Share on other sites
Profiling is not a Visual Studio.NET feature, it's a feature of C++, so you'll only find it in Visual C++.NET. I made the instructions above as clear as possible, but they are for MSVC++ 6.0. I can't vouch for MSVC.NET, as I'm not using. I assumed it had it, based on some stuff I read about it, but I could be wrong. However, profiling is a very useful tool, I can't see Microsoft omitting it in .NET. Look through your MSDN stuff.

Open a project (a Windows project), and go to the Project menu. Open Settings... Alt+F7. Click the Link tab, and look for the profiling checkbox...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on August 19, 2003 8:28:07 AM]

Share this post


Link to post
Share on other sites
I had Visual C++ 6.0 before and the profiler worked great. Unfortunatly, I can''t find one in VC++.NET

Share this post


Link to post
Share on other sites
It's gotta be there somewhere. Maybe they made it separate program, or hid it?

Those NVIDIA docs are pretty good, by the way...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on August 19, 2003 8:43:32 AM]

Share this post


Link to post
Share on other sites
I've come across some API calls that involves profiling, but that seems a little bit too much work. Maybe they have a deal with Intel so they can sell more of their VTune, who knows?!

And yeah, the NVidia docs ARE good!

---

Found this on a web site: "Although Visual C++ does not ship with a profiler", so I guess profiling stops with VC++ 6.0 . At least easy profiling...

Also, it seems like it's just the .NET Framework that has the profiling API calls when I read on.

---

I found a free profiler to use with VS.NET. Haven't tried it, but if someone is interesed, the link is:

http://www.compuware.com/products/devpartner/profiler/default.asp

[edited by - ALiENiD on August 19, 2003 9:01:48 AM]

Share this post


Link to post
Share on other sites
iNsAn1tY, using the profiler will show where a bottleneck occurs within the code. This assumes that the main bottleneck of the program is in the CPU, i.e. your fps are limited by the number of calculations the CPU is having to perform for each frame (e.g. AI, collision detection, occlusion culling etc.).

If the bottleneck is in the GPU (e.g. fill-rate limits as I mentioned in my previous post) the CPU is basically waiting around for the gfx card to finish drawing the scene, and the profiler cannot help you (since making any CPU routines run faster will not help your fps - the CPU will still be waiting for the graphics card to catch up).

I believe the depth-buffer can help in fill-rate limited scenarios: While the vertex data still has to be sent to the gfx card, the depth buffer will prevent hidden surfaces from being rendered, since they are behind other polys. This means the texturing and lighting operations (and maybe others?) will not need to be performed for the hidden polys and so the frame rate will increase. Hence if decreasing the window size increases the frame rate, the bottleneck was the fill-rate limitations of the gfx card (fps increases because there are fewer pixels to "fill"), it cannot be the cpu since the same number of calculations are still being performed by the CPU (sending vertices etc.)

Are the only two types of bottleneck therefore fill-rate limited and CPU limited then? Or have I forgotten others? I guess vsync could be seen as a bottleneck in that it is a fps limiter!

iNsAn1tY, your post on the profiler was very useful, I had heard of it but never got round to using it. I guess it would be used to locate the source of a CPU bottleneck more precisely, but won''t tell you if your bottleneck is fill-rate or GPU limited, AFAIK.

Share this post


Link to post
Share on other sites
Hmmm. Yes, if it is a fill rate problem, then profiling won't be much use. However, it is an excellent optimization tool, and you can catch other bottlenecks with it, like inefficent code. You should see the speed increase in function call times when you use glDrawArrays/glDrawElements instead of the high-level glBegin/glVertex3f/glEnd functions. Another good utility for checking graphics card fill rate, CPU and GPU loads and a whole heap of other stuff is 3D Mark 2003. Plus, it's demos are really quite impressive. You can find 3D Mark 2003 (for modern machines) and 3D Mark 2001 (for older machines) at Futuremark's website.

By the way, the depth buffer still performs it's test on a per-fragment basis though. It has to check whether each fragment of a polygon is visible, and with large numbers of polygons, performance can be seriously slowed. The best option for reducing geometry is still frustum culling and spatial occlusion (BSP, etc).

There's a nice tutorial on frustum culling at www.gametutorials.com...



Coding Stuff ->  [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff    ->  [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]


[edited by - iNsAn1tY on August 19, 2003 12:52:42 PM]

Share this post


Link to post
Share on other sites
A program can be fill bound or transform bound. There was a nice two part article on it in Game Developer magazine recently(june and july) by Guillaume Provost. Hopefully it''ll appear on Gamasutra soon.

Share this post


Link to post
Share on other sites

  • Advertisement