<br><br><div class="gmail_quote">On Thu, Mar 10, 2011 at 12:56 PM, Brian Paul <span dir="ltr">&lt;<a href="mailto:brianp@vmware.com">brianp@vmware.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 03/10/2011 12:25 PM, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I have reviewed where we call flush() and why and some of them<br>
seem unnecessary to me. Those flushes may slightly decrease<br>
performance, depending on each driver, and may hide driver bugs.<br>
<br>
glFlush doesn&#39;t have to be called in OpenGL so often, and<br>
I think state trackers should follow suit.<br>
<br>
The worst example of this is st/vega. I guess those flushes are<br>
there for debugging only.<br>
<br>
Please review.<br>
<br>
Marek Olšák (3):<br>
       st/mesa: remove unnecessary flushes<br>
       st/vega: remove unnecessary flushes<br>
       draw: remove unnecessary flush<br>
<br>
  src/gallium/auxiliary/draw/draw_pipe_pstipple.c |    7 -------<br>
  src/gallium/auxiliary/util/u_gen_mipmap.c       |    2 --<br>
  src/gallium/state_trackers/vega/api_images.c    |    4 ----<br>
  src/gallium/state_trackers/vega/image.c         |    8 --------<br>
  src/gallium/state_trackers/vega/mask.c          |    2 --<br>
  src/mesa/state_tracker/st_cb_fbo.c              |    3 ---<br>
  6 files changed, 0 insertions(+), 26 deletions(-)<br>
</blockquote>
<br></div>
If there aren&#39;t any regressions with piglit and the OpenVG demos, looks good.<br><font color="#888888">
</font></blockquote><div><br><br>Some time back I did some heavy duty vega work that was focused specifcally on conformance and found the flushes to be important, but that was also on a version of gallium much older than today&#39;s code, which I am not as familiar with. Thus YMMV... from my own.<br>
<br>One example is that OpenVG uses blend modes that generally aren&#39;t supported in most hardware, thus a custom shader is loaded that samples from a texture created immediately prior to the draw via a blt of the actual render target. The flush was important in this case to make sure that the frame buffer was current prior to the creation of that texture copy. My memory is vague but I believe this also applied to mask, filters... probably others in there too. If the render target is safely current without the flush in today&#39;s gallium, then the flush probably servers no purpose.<br>
<br>Mark<br><br> </div></div>