<div dir="ltr">On 31 October 2013 05:38, 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"><div class="im"><br>
<br>
>> but I do not quite follow the second upload; what<br>
>> is the magicks going on with batch->state_batch_offset and for that matter<br>
>> batch->bo->size ??<br>
<br>
>This is stack and heap model for batchbuffer submission. Direct state, which<br>
>is usually composed of the commands, is allocated at the beginning and<br>
>indirect (dynamic) state data is allocated from the end of the batchbuffer.<br>
>The batch->state_batch_offset is the start location of the indirect state data<br>
<br>
</div>By indirect state, do you mean addresses for things (like shader binary, image and buffer object sources)? I admit that I see nothing about the ideas of stack (last in is first out) or heap (biggest is out first) about that. What is being pushed (stack) or in priority (usual use case for heaps)?<br>

<br>
Assuming it is addresses, is it just putting addresses of the data sources used in a draw call within a batch, do those values -need- to be in the end? is that need from the hardware or for the kernel?</blockquote><div><br>
</div><div>No, there's no need for them to be at the end.  It's just our little trick to allow us to use the same buffer object for both batch commands and indirect state. <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">
 is the offset into those addresses also packed into the batch buffer? if so where? also, what is the address space of the addresses? GTT values? Usermode values [which means kernel converts]? something else?<br></blockquote>
<div><br></div><div>From the GPU's point of view, all addresses are relative to the GTT.  The address of most indirect state is specified using two values: a base pointer and an offset.  The base pointer is specified using the STATE_BASE_ADDRESS command, and the offset is specified in whatever command is trying to establish the state in question (for example, if we're talking about the scissor rectangle, it's the 3DSTATE_SCISSOR_STATE_POINTERS command).  Different types of data use different base address pointers, but for all of the data we're talking about right now, we always set the base address pointers to the start of the batch buffer.  Then, in the individual commands, the offset we supply is simply the offset to the data within the batch buffer.  So, for example, if you look at gen6_upload_scissor_state(), you'll see that it allocates the indirect state for the scissor rectangle using brw_state_batch().  That gives it back an offset (scissor_state_offset) telling it the offset (relative to the batch) where the indirect state is.  Then it uses BEGIN_BATCH(), OUT_BATCH(), and ADVANCE_BATCH() to send a 3DSTATE_SCISSOR_STATE_POINTERS command containing the offset.<br>
<br></div><div>The kernel is in charge of deciding where to locate each buffer object in the GTT, and it decides this after Mesa has submitted the batch.  So Mesa can't program the STATE_BASE_ADDRESSes directly.  Instead, it gives the kernel a data structure full of "relocations", which tell the kernel how to patch up things like the STATE_BASE_ADDRESS command once the GTT addresses have been decided.  So, for example, if you look at upload_state_base_address(), you'll see that it outputs the base addresses using the OUT_RELOC() macro.  This emits a speculative address into the batch (based on the GTT address that the batch buffer had last time it was used), and tells the kernel how to fix it up if the batch buffer winds up getting relocated to a different GTT address.<br>
</div></div></div></div>