[Mesa-dev] [PATCH 06/22] i965: Enable BatchbufferLogger in i965 driver

[Chris Wilson]

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