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