All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 00/03] Preventing zero GPU virtual address allocation
Date: Wed, 20 May 2015 18:00:43 +0200	[thread overview]
Message-ID: <20150520160043.GK15256@phenom.ffwll.local> (raw)
In-Reply-To: <20150520141406.GD17761@nuc-i3427.alporthouse.com>

On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > This patch series (one patch each for libdrm, the kernel, and beignet)
> > > aims to provide a means to add a context-specific means to prevent
> > > a mapping to GPU virtual address zero.  This is needed at least by
> > > Beignet (possibly in other use-cases too, though I don't know of any
> > > other) to allow use of address zero to represent NULL.
> > 
> > Urm, you cannot allow absolute addressing period. What happens to the
> > object at 0 when the user reads from it or writes to it? You have to
> > have an object at 0 for the user's NULL pointer access.
> 
> I'll mollify that: outside of full-ppgtt where you need to share the VM.

The description is misleading, the new flag doesn't prevent anything from
getting mapped at 0 but only prevents any bo submitted through execbuf on
the given context from being bound at address 0. If that would happen
compute kernels using NULL checks for some things would fall over.

Essentially it applies the PIN_BIAS for all execbuf objects, which works
even on ggtt execbufs.

Patches themselves look good, but we miss the igt to update the invalid
ctx flags testcase. And a bare minimal function testcase (which checks the
reloc offset with and without a ctx with this flag set) would be nice too.
With that and an r-b from the beignet developers I'll pull this in.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-05-20 15:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 13:54 [PATCH 00/03] Preventing zero GPU virtual address allocation David Weinehall
2015-05-20 14:00 ` [PATCH 01/03] drm/i915: add a context parameter to {en, dis}able zero address mapping David Weinehall
2015-05-28 14:39   ` Chris Wilson
2015-05-28 15:52     ` Daniel Vetter
2015-05-28 16:56       ` Chris Wilson
2015-05-29  8:18         ` David Weinehall
2015-05-20 14:01 ` [PATCH 02/03] libdrm: export context_{get, set}param and I915_CONTEXT_PARAM_NO_ZEROMAP David Weinehall
2015-05-20 14:02 ` [PATCH 03/03] beignet: set I915_CONTEXT_PARAM_NO_ZEROMAP when initializing context David Weinehall
2015-05-20 14:09 ` [PATCH 00/03] Preventing zero GPU virtual address allocation Chris Wilson
2015-05-20 14:14   ` Chris Wilson
2015-05-20 16:00     ` Daniel Vetter [this message]
2015-05-20 16:10       ` Chris Wilson
2015-05-21  8:08         ` David Weinehall
2015-05-21  8:43           ` Chris Wilson
2015-05-21  9:38             ` David Weinehall
2015-05-21  9:59               ` Chris Wilson
2015-05-21  9:44             ` Daniel Vetter
2015-05-21  9:50               ` Chris Wilson
2015-05-27  9:17                 ` David Weinehall
2015-06-05 14:13                   ` Dave Gordon
2015-05-21  7:59       ` David Weinehall
2015-05-27  7:54       ` Zou, Nanhai
2015-05-27 11:29         ` Daniel Vetter
2015-05-21  9:44 ` [PATCH i-g-t 4/3] tests/gem_ctx_param_basic: Expand ctx_param tests David Weinehall
2015-05-27 11:32   ` Daniel Vetter
2015-05-28 12:20     ` David Weinehall
2015-05-28 14:53     ` David Weinehall
2015-05-29  7:52       ` Daniel Vetter
2015-08-06 21:30         ` Daniel Vetter
2015-08-06 21:30           ` Daniel Vetter
2015-08-06 21:33           ` Jesse Barnes
2015-08-10 14:15             ` David Weinehall
2015-08-13 23:12               ` Jesse Barnes
2015-08-10 14:17           ` David Weinehall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150520160043.GK15256@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.