[Mesa-dev] [PATCH 3/5] i965: Rename brw_bo::offset64 to presumed_offset.

[Chris Wilson]

Quoting Kenneth Graunke (2017-08-31 21:17:58)
> We can drop the meaningless "64" suffix - libdrm_intel originally had
> an "offset" field that was an "unsigned long" which was the wrong size,
> and we couldn't remove/alter that field without breaking ABI, so we had
> to add a uint64_t "offset64" field.
> 
> "presumed_offset" is a bit more descriptive than "offset".

Another aspect is that is used as a hint by the kernel for where to place
the object, so offset_hint, request_offset both apply. But once you
start mixing in EXEC_OBJECT_PINNED, it is no more presumed.

I would suggest that presumed_offset is perhaps a little misleading
considering all the possible uses, and would suggest gtt_offset instead.

/*
 * Offset of the buffer inside the Graphics Translation Table.
 *
 * This is effectively our GPU address for the buffer and we use it
 * as our base for all state pointers into the buffer. However, since the
 * kernel may be forced to move it around during the course of the
 * buffer's lifetime, we can only know where the buffer was on the last
 * execbuf. We presume, and are usually right, that the buffer will not
 * move and so we use that last offset for the next batch and by doing
 * so we can avoid having the kernel perform a relocation fixup pass as
 * our pointers inside the batch will be using the correct base offset.
 *
 * Since we do use it as a base address for the next batch of pointers,
 * the kernel treats our offset as a request, and if possible will
 * arrange the buffer to placed at that address (trying to balance
 * the cost of buffer migration versus the cost of performing
 * relocations). Furthermore, we can force the kernel to place the buffer, or
 * report a failure if we specified a conflicting offset, at our chosen
 * offset by specifying EXEC_OBJECT_PINNED.
 *
 * Note the GTT may be either per context, or shared globally across the
 * system. On a shared system, our buffers have to contend for address
 * space with both aperture mappings and framebuffers and so are more
 * likely to be moved. On a full ppGTT system, each batch exists in its
 * own GTT, and so each buffer may have their own offset within each
 * context.
 */