On Thu, Nov 03, 2016 at 09:07:55PM -0700, Jason Ekstrand wrote:
>On Thu, Nov 3, 2016 at 3:00 PM, Chris Wilson <[1]ch...@chris-wilson.co.uk>
>wrote:
>
> As it stands today, using NO_RELOC without PINNED, the kernel will
> arbitrarily assign an address to each buffer. (The kernel d
On Thu, Nov 3, 2016 at 3:00 PM, Chris Wilson
wrote:
> On Thu, Nov 03, 2016 at 02:19:01PM -0700, Jason Ekstrand wrote:
> >On Thu, Nov 3, 2016 at 1:53 AM, Chris Wilson <[1]
> ch...@chris-wilson.co.uk>
> >wrote:
> >
> > Something to consider is just randomly assigning an address and
> u
On Thu, Nov 03, 2016 at 02:19:01PM -0700, Jason Ekstrand wrote:
>On Thu, Nov 3, 2016 at 1:53 AM, Chris Wilson <[1]ch...@chris-wilson.co.uk>
>wrote:
>
> Something to consider is just randomly assigning an address and using
> it. The kernel will relocate if it wants to, but in futu
On Thu, Nov 3, 2016 at 1:53 AM, Chris Wilson
wrote:
> On Wed, Nov 02, 2016 at 01:58:43PM -0700, Jason Ekstrand wrote:
> > +/**
> > + * This function applies the relocation for a command buffer and writes
> the
> > + * actual addresses into the buffers as per what we were told by the
> kernel on
>
On Wed, Nov 02, 2016 at 01:58:43PM -0700, Jason Ekstrand wrote:
> +/**
> + * This function applies the relocation for a command buffer and writes the
> + * actual addresses into the buffers as per what we were told by the kernel
> on
> + * the previous execbuf2 call. This should be safe to do bec
From: Kristian Høgsberg Kristensen
Since our surface state buffer is shared by all batches, the kernel does a
full stall and sync with the CPU between batches every time we call
execbuf2 because it refuses to do relocations on an active buffer. Doing
them in userspace and passing the NO_RELOC fl
