<div dir="ltr">On 19 March 2013 17:10, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> writes:<br>
<br>
> Normally when submitting the first batch buffer after a flush, we<br>
> check whether the GPU has completed processing of the first batch<br>
> buffer of the previous frame.  If it hasn't, we wait for it to finish<br>
> before submitting any more batches.  This prevents GPU-heavy and<br>
> CPU-light applications from racing too far ahead of the current frame,<br>
> but at the expense of possibly lower frame rates.  Sometimes when<br>
> benchmarking we want to disable this mechanism.<br>
><br>
> This patch adds the driconf option "disable_throttling" to disable the<br>
> throttling mechanism.<br>
<br>
</div>We often do our driver-specific options inside of intel_screen.c, but I<br>
suppose this way someone could potentially translate it.<br>
<br>
Reviewed-by: Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>><br>
<br>
Have you found any interesting cases where this is a problem?<br>
</blockquote></div><br></div><div class="gmail_extra">I think Ken found a benchmark where there was a marginal improvement, but I don't recall exactly what it was.<br></div></div>