[Mesa-dev] Batch buffer sizes, flushing questions

[Paul Berry]

On 31 October 2013 05:38, Rogovin, Kevin <kevin.rogovin at intel.com> wrote:

>
>
> >> but I do not quite follow the second upload; what
> >> is the magicks going on with batch->state_batch_offset and for that
> matter
> >> batch->bo->size ??
>
> >This is stack and heap model for batchbuffer submission. Direct state,
> which
> >is usually composed of the commands, is allocated at the beginning and
> >indirect (dynamic) state data is allocated from the end of the
> batchbuffer.
> >The batch->state_batch_offset is the start location of the indirect state
> data
>
> 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)?
>
> 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?


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.


> 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?
>

>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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131031/782dc561/attachment.html>