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. 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? -Kevin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
