c++ - glGetError and performance -


background

at work, develop 2 products both have opengl 3.x+ , gles 2.0/3.0+ backends. teams independent, have overlap, , discussing performance of glgeterror.

in both products, design such no gl calls should generate error code recorded glgeterror. detect such errors, in debug have macro adds glgeterror after each gl call, , asserts if errors detected, means there bug. on product, enabled default, in other, must explicitly enabled.

these have been present in codebase of product work on many years, , see cause performance hits, in neighbourhood of 25% across many platforms. have decided reasonable price pay detection of errors. other team claimed under circumstances, adding these checks can slow down execution of product running @ 60fps < 1fps, making product unusable, why not enabled default. both products run on many opengl/gles platforms (pc, osx, linux, ios , android).

questions

i understand reasoning behind glgeterror reducing performance; (may) require cpu/gpu synchronization status of previous operation correct. understanding should change expected frame time "max(cpu time, gpu time)" (assuming no other sync points, , no queued frames) "cpu time + gpu time + synchronization overheap" (assuming every glgeterror call results in sync point). not correct reasoning, or, there additional reason performance reduction using glgeterror?

i under impression per-call glgeterror in debug reasonable thing (at least after gl calls no errors should possible). not case or not considered 'best practice'? there circumstance(s) can cause extreme performance issues such other team described (eg. particular set of gl calls and/or platform)?

glgeterror() not have wait gpu. errors reports checking arguments of api calls, internal state managed driver. cpu/gpu synchronization not come play here.

the error may appear deferred gl_out_of_memory, spec open 1 ("may generated"), it's not reason synchronization either.

i can think of 2 reasons why calling glgeterror() after each api call may reduce performance:

  • you make twice many opengl calls. there overhead call itself, checking , returning error state. while calling glgeterror() once may not expensive, adds if call millions of times.
  • some drivers use multithreading inside driver. in case, glgeterror() cause synchronization between threads in driver, have substantial performance impact if happens frequently.

as should doing, have find out works. thoughts/suggestions:

  • i not call glgeterror() in release build. it's useful during debugging, unnecessary overhead once testing/qa completed.
  • errors sticky. if want know if there errors, don't have call glgeterror() after each call. example, can call once @ end of each frame. of course if error, , want know call caused it, need more frequent calls. have multiple build types.

    • release build no glgeterror() calls.
    • testing/qa build glgeterror() call @ end of each frame.
    • debug build glgeterror() call after each opengl call.

Comments

Popular posts from this blog

angularjs - ADAL JS Angular- WebAPI add a new role claim to the token -

php - CakePHP HttpSockets send array of paramms -

node.js - Using Node without global install -