aboutsummaryrefslogtreecommitdiffstats
path: root/bin
diff options
context:
space:
mode:
authorChris Wilson <[email protected]>2015-02-26 11:25:18 +0000
committerChris Wilson <[email protected]>2015-03-18 09:33:33 +0000
commit8b9bd19021c0efef33d66ae24f8871b826d66e8a (patch)
tree083c874b30a10d14c4ebfea0d82cc5d7ccf273ed /bin
parent27bf37ba05b69ebf6f373d1637a26b4839265921 (diff)
i965: Throttle rendering to an fbo
When rendering to an fbo, even though it may be acting as a winsys frontbuffer or just generally, we never throttle. However, when rendering to an fbo, there is no natural frame boundary. Conventionally we use SwapBuffers and glFinish, but potential callers avoid often glFinish for being too heavy handed (waiting on all outstanding rendering to complete). The kernel provides a soft-throttling option for this case that waits for rendering older than 20ms to be complete (that's a little too lax to be used for swapbuffers, but is here a useful safety net). The remaining choice is then either never to throttle, throttle after every draw call, or at after intermediate user defined point such as glFlush and thus all the implied flushes. This patch opts for the latter as that is the current method used for flushing to front buffers. v2: Defer the throttling from inside the flush to the next intel_prepare_render() and switch non-fbo frontbuffer throttling over to use the same lax method. The issuing being that glFlush()/intel_prepare_read() is just as likely to be called inside a tight loop and not at "frame" boundaries. v3: Rename from need_front_throttle to need_flush_throttle to avoid any ambiguity between front buffer rendering and fbo rendering. (Chad) v4: Whitespace Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Kristian Høgsberg <[email protected]> Cc: Chad Versace <[email protected]> Cc: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
Diffstat (limited to 'bin')
0 files changed, 0 insertions, 0 deletions