Reputation: 13002
Working on a game, and I was testing out my renderer. It unfortunately only runs at about 4 frames per second. Profiling reveals that surprisingly, only 5% of that runtime belongs to my code, and the remaining 95% of the total run time was spent in nvoglnt.dll
.
Only one 256x256 texture is used though, and beyond that, the only openGL code I use outside of a few camera transformations is this following template of code. It is executed only 134217728 times for a total of 33554432 quads.
glTexCoord2f(u, v);
glColor3f(r, g, b);
glVertex3f(x, y, z);
What could I be doing wrong that's causing OpenGL to become so slow? Are there any common performance techniques I could use to improve it?
Upvotes: 2
Views: 3535
Reputation: 7488
As datenwolf said, 134217728 is a lot of times. 33 million quads is even a lot if you were using vertex arrays. But modern cards should handle it pretty well.
The bottleneck here is completely the CPU, you're calling 134 million x 3 functions every frame. Since you're running at 4FPS. That's 1.6 billion function calls a second! No wonder it's running so slow.
What you should do is use Vertex Buffer Objects. It doesn't matter how volatile your data is, even if you have to update it every frame, it will be faster.
With that out of the way, I'm curious as to why you need to render 33 million volatile quads? If you give us a broader overview of what you are doing, we could propose other optimisation techniques.
Upvotes: 5
Reputation: 162164
It is executed only 134217728 times for a total of 33554432 quads.
Each of those "few" calls makes your system to switch execution context between your program and the OpenGL driver. This is not "few". Honestly I'd consider this question some fine trolling, because each and every OpenGL tutorial these days will tell you not to use immediate mode for excactly that serious performance hit you observed, which immediate mode causes, i.e. glBegin, glEnd, glVertex and so on.
Use Vertex Arrays or better yet Vertex Buffer Objects.
Upvotes: 4