Quoting Rogovin, Kevin (2017-09-27 15:22:00) > Hi, > > > Hmm, this needs updating for the batch/state split; > > This was rebased (and working) against Mesa of Monday, Sept 25, 2017, which I > thought already had the batchbuffer split. I had thought the split was > already in master... but why would it need to know that the state is on a > separate BO? The logger reads into the batchbuffer, in particular, > STATE_BASE_ADDRESS, and uses that data to fetch the data structure placed > into the direct state jazz (which used to be at the end of the batchbuffer), > i.e. the logger chases GPU address to get GEM BO's and offsets into them. It > does this by tracking the creation (and destruction) all GEM BO's by > intercepting drmIoctl. The Logger chases everything so it can write out all > sorts of things, including shader disassembly (shaders are placed on a > different GEM BO as well).
No problem, I guessed it was assuming the old behaviour and knew that everything (more or less) referred to the batch->bo. > > > and of particular note that the batch->bo is no longer constant. It > > shouldn't > > matter overall as the contents/offsets are preserved. > > I would need to go back and see why you need to know the handle before the > > submit, > > but the obvious solution to me would be to record the submission. > > The system if perfectly fine (and happy) if the value behind batch->bo > changes on every execbuffer2. The logger works as follows: > Application calls pre_call() before issuing a GL API call. That function then > has the Logger ask the driver "what is the active batch buffer on this > thread?" whose answer is by calling intel_active_batchbuffer (). The active > batch buffer is identified by the pair (fd, GEM BO handle). The driver_data > pointer is not used by the Logger to track, rather it is for the driver to > use to point to whatever data structure it has for tracking batchbuffer (in > i965's case the address of brw->batch) so that can tell where it is in a > given batchbuffer. Now that the logger has the ID of the batchbuffer, i.e. > the pair (fd, GEM BO handle), it then knows to what batchbuffer the GL API > call is to be associated and it appends the call information to the log for > that batchbuffer. What is also important, is that the system will also work > if there are multiple threads in the calling application each with their own > context current. My worry is that batch->bo is not constant for the construction of a single execbuf2. If intel_batchbuffer.c runs out of room inside the batch->bo, it will allocate a new one and continue building it. > When drmIoctl happens, the logger then trivially extracts the (fd, GEM BO > handle) pair of the batchbuffer to be executed and from there knows what log > to emit. I'm just mentioning that may not be the same handle as some of the earlier state calls. -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
