3
\$\begingroup\$

Is there any benchmark that actually measure state changes cost in OpenGL 3.x/4.x and gather an average statics for all graphics cards? (I don't want to optimize only for my old AMD card, I'm not even sure I'm profiling it correctly).

I found some profile data but is dated against fixed function pipeline wich is somewhat obsolete.

Actually seems FBO setup is the slowest operation (after swapping buffers wich is done only once), but I want to know in average "how much slower" it is compared in example to a texture binding. So that I can take says a 10% error treshold and try to organize up-front gl calls.

\$\endgroup\$
  • \$\begingroup\$ If you have data for your cards I'll try to gather and keep updated a table with average values (gonna do some weighted average by vendor and graphics cards. So assuming 3 cards profiled for each vendor they get equal weight, while if one vendor has 50% more profilings I would count that just 25% more than others.. if that make sense to anyone). \$\endgroup\$ – GameDeveloper Jan 21 '15 at 13:57
  • 1
    \$\begingroup\$ I found some interesting benchmarking of state changes here, at 32 minute mark. Not detailed, but still better than guesses. \$\endgroup\$ – wondra Feb 19 '15 at 15:37
5
\$\begingroup\$

Yes. FBO, shader (changing the currently active program, not necessarily shader state itself) and texture state changes tend to be the most expensive. Conversely, vertex pointers and uniforms tend to be the cheapest states to change.

It is almost impossible to actually calculate the expense of any one state change in modern GL implementations; you might pay a small validation cost up-front while the driver defers the heavy lifting until your next draw call or does certain tasks (e.g. pixel transfer data conversion) in parallel when possible. Rather than trying to profile down to the state change level, have you considered using OpenGL timer queries and partitioning your frame draw into a series of timed tasks?

Timer queries will give you a much better picture of how much time is spent actually doing work in the render pipeline. If you compare the time taken to finish a frame using CPU timers versus the sum of times taken for all pipeline tasks, that will give you some information about non-GPU related overhead. For example, if your entire frame finishes in 5 ms but the CPU blocks for VSYNC (let us assume 60 Hz), you will have a difference of 11 ms between the two numbers. That means there is 11 ms worth of idle GPU time per-frame (in this case because VSYNC is blocking). If you did not know how VSYNC works, that number would be very troubling ;)

In my own work, I calculate the time taken to build shadow maps, fill G-Buffers, composite lights, stream texture/mesh data, HDR post-process, apply anti-aliasing, etc. I can honestly say that knowing which state is the most expensive never delivers worthwhile optimization results but knowing which render task is bottlenecking, on the other hand, is an effective use of your time. You will probably figure out the former by solving the latter.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.