Jump to content
  • Advertisement
Sign in to follow this  
paulshady

OpenGL Optimizing OpenTK/OpenGL code in C#

This topic is 2595 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

Hey guys,

I am working on a project in C# using OpenTK. I am using it in Windowed mode, meaning there are other controls visible on my WinForm, and there is also a GLControl visible on the WinForm.
I'm drawing about 200-300 textured quads every frame.
Right now I am not using the fixed function pipeline and not using any shaders.

The vertex data for the quad is stored in a vertex buffer and index buffer.
The VBO never changes, I just use matrix manipulation to move the quad around the screen and draw it where I need to.

I used a profiler on my program and it seems over 95% of the time is spent in the OpenTK method: GL.DrawElements(...)

My questions are:
Is there any optimization I should be doing to lower that percentage?
If I must draw this many quads every frame should I just assume the draw time will be very high?
Is there a smarter way to do what I'm trying to accomplish?
Should I even bother with other optimizing other areas such as ordering my texture switches? Since the draw call takes such a bulk of the time, it doesn't seem like other optimizations would get me very far.

Any input or insight would be greatly appreciated

Thanks guys!

Share this post


Link to post
Share on other sites
Advertisement
If your application has nothing else to do besides drawing triangles with DrawElements call, then of course 95% or all the time will be spent in this function.
Are you not happy with performance you have right now?

Share this post


Link to post
Share on other sites
I wouldn't say I'm unhappy, I would say I'm surprised with the results that I got.

Here's what surprised me:
In my Draw() loop I do hundreds of texture switches every frame, loads of matrix math, quite a bit of string manipulation, and I have nested foreach loops that could be optimized and written much more efficiently.
But at the moment since the DrawElements() call takes up such a glaring percentage of time inside the Draw() loop, I don't really see a large payoff if I start cleaning up and optimizing the rest of the method.

The open question I have at the moment is:
Is the DrawElements() call much more expensive than almost any other call I would make? IE - Are results similar to what I have described expected?

Thanks in advance for any replys.

Share this post


Link to post
Share on other sites
Check if there is VSync enabled.
If not, then its doesnt means that your software is slow. Its like running in infinite loop mathematical equations.
All you need to do, is limit somehow rendering. If it is in separate thread, just put in there Thread.Sleep(1). That will sort out the problem, and wont affect on your FPS too much.

Share this post


Link to post
Share on other sites
This is pretty normal; most drivers will do lazy state changes, so your texture switches/etc are just stored out rather than applied immediately, and then the first draw call where they're used will cause them to be applied.

A pitfall of trying to profile graphics code is that most profilers will only measure CPU time, whereas the real action isn't actually happening on your CPU at all - it's happening on your GPU. All that glDrawElements (or virtually any other OpenGL call) does is hand over a bunch of data and commands to the GPU, which will then execute those data and commands in it's own sweet time.

The number of textured quads you're drawing is nothing; it's so low that any GPU nowadays (and virtually any one from the previous 10-15 years) will eat it for breakfast and come back looking for more. If you've got vertex buffers available you're definitely capable of handling this.

One thing I see that you're doing is mixing OpenGL with GDI code. This is generally not recommended; see: http://www.opengl.or...ticle/vol003_7/ for example.

Share this post


Link to post
Share on other sites
Thanks, mhagain, that was really helpful.


The link was very informative, too.

One more question:
So, the GPU is basically free? Meaning the developer doesn't have to do anything specific to cause work to be handed off to the GPU?
Even if I'm just using the fixed function pipeline.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!