Quoting Matthew Auld (2020-01-24 16:54:42)
> On 24/01/2020 16:46, Chris Wilson wrote:
> > Quoting Matthew Auld (2020-01-24 16:41:31)
> >> Technically mmap__cpu and mmap__wc just ignore the prot value, so it
> >> doesn't really matter, but the intention is to have write access to the
> >> ptr, so make that clear. Also if the underlying mmap__wc were to at some
> >> point use mmap_offset where the prot is not ignored then we won't have
> >> any surprises.
> >
> > The ptr here was just meant for cheaply reading back from the buffer to
> > verify the relocation took place. E.g.,
> >
> > -static void exec1(int fd, uint32_t handle, uint64_t reloc_ofs, unsigned flags, char *ptr)
> > +static void exec1(int fd, uint32_t handle, uint64_t reloc_ofs, unsigned flags, const char *ptr)
> > {
> > struct drm_i915_gem_execbuffer2 execbuf;
> > struct drm_i915_gem_exec_object2 gem_exec[1];
> > @@ -126,7 +126,7 @@ static void xchg_reloc(void *array, unsigned i, unsigned j)
> > *b = tmp;
> > }
> >
> > -static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, char *ptr)
> > +static void execN(int fd, uint32_t handle, uint64_t batch_size, unsigned flags, const char *ptr)
> > {
> >
> > What am I missing?
>
> *(uint64_t *)(ptr + gem_reloc[n].offset) = gem_reloc[n].presumed_offset;
They say your memory is the first to go.
Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
