[Mesa-dev] CACHED_BATCH questions

Kenneth Graunke kenneth at whitecape.org
Sat Nov 9 09:18:19 PST 2013


On 11/08/2013 12:45 AM, Rogovin, Kevin wrote:
> Hi all,
> 
> I am trying to get my head around CACHED_BATCH() which is just a
> macro for   intel_batchbuffer_cached_advance(), and when I dig into
> that code it leaves me some head scratching. I am guessing it checks
> if the current contents of the batch buffer already have command and
> if so, to skip sending that command. In this case, the commands match
> if essentially all the bytes match. I think the mechanics are by
> setting batch.used to batch.emit to skip sending the command. If the
> item was not found to then save the location in the batch buffer with
> a cached_batch_item object. If the op code was found, but contents
> different, then the command gets emitted anyways and the cache entry
> updated. So, that makes sense, but:
> 
> Why bother? the size of the cached batches does not look very big
> (the biggest one I found where 30-something for polygon stipple
> [upload_polygon_stipple()] and something that I guess is no more than
> 1+2N, where N is the number of vertex attributes (I think this is 16)
> for the vertex sources [ brw_emit_vertices() ]. Worse, the looking up
> of going through the cache looks more inefficient time-wise than just
> adding those bytes. Also, all the uses in an atom thing should not
> happen I'd guess because they check their dirty flags to decide
> weather or not to emit. That essentially leaves what happens in
> brw_emit_vertices(), which I'd think would also be saving the
> attribute source state.

You're not the only one confused by this code.  I spent quite a while
trying to figure out what on earth it does and why we'd want to do that.

I have a patch series to delete CACHED_BATCH entirely, but it needs some
benchmarking results saying that it doesn't impact performance.  Most of
the affected packets are Gen4 only, so I'd have to dig out that machine
to do it.

> 
> On a related question, I see in brw_emit_vertices(), a BEGIN_BATCH(1
> + nr_elements * 2) followed by a for-loop of length nr_elements that
> for each iteration does OUT_BATCH twice, but then there are some if's
> which also do OUT_BATCH, without a BEGIN_BATCH before hand, so it
> looks like that those last maybe OUT_BATCHES (two for each if-block)
> could be naughty. What am I missing?

   nr_elements = brw->vb.nr_enabled + brw->vs.prog_data->uses_vertexid;

- The first loop does brw->vb.nr_enabled iterations.
  It does not OUT_BATCH for the edgeflag input.
- The first if-block goes back and handles the edgeflag input,
  which was skipped by the loop above (via the continue).
- The last if-block handles uses_vertexid.


More information about the mesa-dev mailing list