[Mesa-dev] [PATCH 08/10] i965: Introduce an OUT_RELOC64 macro.

[Daniel Vetter]

On Fri, Dec 13, 2013 at 10:04:53AM -0800, Kenneth Graunke wrote:
> On 12/13/2013 09:28 AM, Daniel Vetter wrote:
> > On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
> >> Broadwell uses 48-bit addresses.  The first DWord is the low 32 bits,
> >> and the second DWord is the high 16 bits.
> >>
> >> Since individual buffers shouldn't be larger than 4GB in size, any
> >> offsets into those buffers (buffer->offset + delta) should fit in the
> >> low 32 bits.  So I believe we can simply emit 0 for the high 16-bits,
> >> and drm_intel_bo_emit_reloc() should patch it up.
> >>
> >> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
> >> ---
> >>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> >> index 159f928..128eed9 100644
> >> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> >> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> >> @@ -178,6 +178,11 @@ void intel_batchbuffer_cached_advance(struct brw_context *brw);
> >>  				read_domains, write_domain, delta);	\
> >>  } while (0)
> >>  
> >> +/* Handle 48-bit address relocations for Gen8+ */
> >> +#define OUT_RELOC64(buf, read_domains, write_domain, delta) \
> >> +   OUT_RELOC(buf, read_domains, write_domain, delta);       \
> >> +   OUT_BATCH(0);
> > 
> > Please not. The presumed_offset that libdrm uses is 64bits, and you need
> > to emit the full presumed address (and correctly shifted). Atm the kernel
> > never gives you a presumed reloc offset with the high bits set so it
> > doesn't matter. But I'd prefer if we don't need to make this opt-in
> > behaviour once we enable address spaces with more than 4G.
> > 
> > i-g-t gets away with the cheap hack since we're allowed to break igt.
> > Let me check ddx and libva whether I've lost this fight already ...
> > -Daniel
> 
> I'm more than happy to do the right thing, I just don't know what that
> is.  I don't see any uint64_t values in the interface we use at all:
> 
> OUT_RELOC becomes
>    ret = drm_intel_bo_emit_reloc(brw->batch.bo, 4*brw->batch.used,
>                                  buffer, delta,
>                                  read_domains, write_domain);

This function here only adds the relocation entry to the batch buffer, so
that the kernel can fix stuff up in case anything moved. But you still
need to write the 64bit value into the batch itself, under the assumption
that the target buffer has not moved. For that the kernel tells you the
last offset in target_bo->presumed_offset. Of course you also need to add
the delta and all that.

On a very quick read (it's getting late here, please double check) you
need to add an OUT_RELOC64 and intel_batchbuffer_emit_reloc64. The call to
drm_intel_bo_emit_reloc stays the same, but you then need a new variant of
the function which writes the presumed reloc stuff into the batch, so a
new intel_batchbuffer_emit_qword which writes the 2 dwords for the reloc
entry.

> 
> which is:
> 
> static int
> drm_intel_gem_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
>                 drm_intel_bo *target_bo, uint32_t target_offset,
>                 uint32_t read_domains, uint32_t write_domain)
> 
> ...all 32-bit values.  It sounds like you're thinking we use Chris's
> "let's presume it hasn't moved since last time" relocation stuff?  We
> don't (at least not yet)...

The presumed_offset handling is all in libdrm and the above mentioned
stuff in OUT_RELOC. So I'm pretty sure you're using it ;-)

SNA on top uses a slightly different layout of the actual relocations
entries submitted to the kernel. The upshot of that is that the fastpath
can get a bit better (the kernel essentially ends up doing nothing besides
checking that all the objects are still at the same spot), the downside is
that userspace needs to follow stricter rules around emitting relocs and
reusing buffers. Last time I've chatted with Eric he said it's not worth
the trouble for mesa. Anyway, completely different topic.
 
> I'm more than happy to take suggestions.

Hope this helps.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch