[Mesa-dev] Batch buffer sizes, flushing questions

Abdiel Janulgue abdiel.janulgue at linux.intel.com
Thu Oct 31 14:11:03 CET 2013


On Thursday, October 31, 2013 12:38:37 PM Rogovin, Kevin 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)? 

Usually, indirect state are objects that are referenced by the commands. A 
shader binary image itself can be classified as indirect state.

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

Stack/heap in process memory management sense. The direct state grows from the 
bottom and the indirect state goes down from the top.

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

It depends, for some commands it could be an offset size from a buffer object 
itself. Sometimes they could be virtual addresses (offset from the aperture). 
Then there are commands that require physical addresses, AFAIK, I think only 
the kernel directly uses them, not the userspace...

> 
> If it is not addresses, what is it?
> 
> -Kevin
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list