Bindless Stuff

[Alfonse Reinheart]

Define "work"?

It does what they wanted it to.

[Aleksandar]

It's basically just counting the number of frames rendered after you reset the performance monitor, and dividing by the total time taken between just before the first frame was rendered after a performance monitor reset + just after the last frame was rendered.

Typically you'd just query "FramesPerSecond" every couple of seconds + reset the performance monitor straight after with "ResetPerformanceMonitor()" to get a framerate displayed that is responsive.

Well, measuring the time and dividing it with a number of frames drawn in that period is not a very accurate method to discover how much time is actually spent in the drawing itself. In the best case, I don't want a screen synchronization to take its part, and in real apps there can be a peace of code executing between two consecutive drawings. That's why many on this forum insist on ms and not on fps. So, the idea is to measure time taken for each frame, not a time-span interval across many frames.

// E.g.
   QueryPerformanceCounter(&q1);
   DrawScene();
   glFinish();
   QueryPerformanceCounter(&q2);
   time = CalcTime(q1,q2);
   SwapBuffers();
   //Etc...

[ScottManDeath]

You might want to supplement the CPU time by GPU ticks, as retrieved by the EXT/ARB_time_query extension.

[Dan Bartlett]

So you reckon this would provide more useful results?

glFinish();
glBeginQuery(GL_TIME_ELAPSED, timerQuery);
DrawScene();
glFinish;
glEndQuery(GL_TIME_ELAPSED);
glGetQueryObjectiv(timerQuery, GL_QUERY_RESULT, @timeElapsed);
// Calc average time elapsed

I assume it also requires an initial glFinish() before starting the timer query?
I'm not convinced running in a completely clean pipeline would give the most realistic results, but it will help eliminate cases where the fastest stats are limited by something else, and the lower stats are limited by what you are measuring.

[Aleksandar]

The first glFinish is not necessary, especially if there is only one thread drawing (and the previous glFinish committed drawing). But if you like, you can include even that.

[Groovounet]

The purpose of timer query is to AVOID glFinish.

Bu I'm not sure it's a key point for your test.

[Aleksandar]

It is crucial! Because we want to know exact moment when the driver finishes the drawing, not when it accepts the command.

[Groovounet]

That's what the timer query does...

The timer query, sit in the command queue. it takes the start and end time from when it is processed in the thread that process the command queue so that you never have to stall to get an accurate timing. Well, unless you call glGetQuery too soon, but it can have a Frame + 1 latency with no trouble.

[Aleksandar]

Oh, you are talking about the new GL3.3 extension - GL_ARB_timer_query. Sorry, I didn't understand!
Well I haven't tried it yet. And I cannot relay on it, because most of the cards/drivers do not implement GL 3.3.

Although it would be interesting to compare results of GL_ARB_timer_query with "the old method".
Thanks for the suggestion!

[Groovounet]

I should have quote the extension. It didn't went to my mind that Windows call this timer query too! Fun

Timer query is pretty old actually and supported through
GL_EXT_timer_query extension on nVidia hardware back to GeForce 6.