<div dir="ltr">On 30 October 2013 11:55, Rogovin, Kevin <span dir="ltr"><<a href="mailto:kevin.rogovin@intel.com" target="_blank">kevin.rogovin@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
  I've got some questions and I would appreciate if anyone could help me out. Here goes:<br>
<br>
I've been digging through brw_try_draw_prims(), and trying to figure out what it is doing, so far this is what I see:<br>
<br>
 1) it is essentially called each time a non-degenerate "real drawing" glDrawFoo() is called<br>
 2) it appends to the current batch buffer the necessary commands to the GPU to execute the draw call. This includes state change upload is essentially handled by brw_upload_state() which essentially walks atoms.<br>
 3) if the batch buffer gets full enough it is flushed.<br>
<br>
Now bits that confuse me:<br>
1)  When I look at intel_batch_buffer_flush() I see that it adds a marker MI_BATCH_BUFFER_END (and possible a no-op marker to keep the size even) and then makes the DRM call, drm_intel_bo_subdata() and then unreferences the upload data. What I do not understand is where/how is the signal to kernel made to say the buffer should be processed.. is is just by uploading the data?<br>
</blockquote><div><br></div><div>No.  do_flush_locked() (which is called by intel_batch_buffer_flush()) follows that by calling either drm_intel_bo_mrb_exec() or drm_intel_gem_bo_context_exec().  That's what causes the batch to be queued for execution.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) I admit that I have not gone through the VBO module super fine-like, but when and where is nr_prims not one? The calls I have looked at have that value being one. What calls, if any, have that argument not as one?<br>
</blockquote><div><br></div><div>nr_prims is sometimes != 1 when the client is using the legacy glBegin()/glEnd() technique to emit primitives.  I don't recall the exact circumstances that cause it to happen, but here's one example:<br>
<br>glBegin(GL_LINE_STRIP);<br>glArrayElement(...);<br>...<br>glEnd();<br>glBegin(GL_LINE_LOOP);<br>glArrayElement(...);<br>...<br>glEnd();<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

3) It appears that a batch buffer gets flushed if blorp is used,  glFlush is called or if it gets too full. Is there anything to say if the command looks heavy so that it should trigger a flush to make sure the GPU command queue is full-ish usually?<br>
</blockquote><div><br></div><div>Not that I'm aware of.  My intuition is that since GL apps typically do a very large number of small-ish draw calls, this wouldn't be beneficial most of the time, and it would be tricky to tune the heuristics to make it effective in the rare circumstances where it mattered without sacrificing performance elsewhere.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4) Going further, is there any mechanism (and if so what is it) to say a batch has made its way through the gfx pipeline? Going further, fine details of making its way through. For example, if a memory region, say for attributes, is no longer read so it can be modified. I am looking at glBufferSubData and glTexSubImage calls on buffer and texture objects used by previous draw calls.</blockquote>
<div><br></div><div>drm_intel_bo_busy() will tell if a buffer object is still being used by the GPU.  Also, calling drm_intel_bo_map() on a buffer will cause the CPU to wait until the GPU is done with the buffer.  (In the rare cases where we want to map a buffer object without waiting for the GPU we use drm_intel_gem_bo_map_unsynchronized()).<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Also, what is the tangle for seeing if a query is ready? For example, an application can ask if a query is ready and if it is then get the value otherwise not ask for the value. Doing so can avoid a pipeline flush.<br>
</blockquote><div><br></div><div>We implement this using drm_intel_bo_busy() to see whether the GPU has finished using the buffer object containing the query result.  See the implementation of gen6_check_query() for example.<br>
</div><br></div></div></div>