[Beignet] [Intel-gfx] Preventing zero GPU virtual address allocation

[Daniel Vetter]

On Thu, Mar 05, 2015 at 01:01:21PM +0000, Chris Wilson wrote:
> On Thu, Mar 05, 2015 at 01:52:51PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:56:52AM +0000, Song, Ruiling wrote:
> > > Hi Daniel,
> > > 
> > > OpenCL language support NULL pointer, using zero as the NULL pointer is
> > > the obvious way. That is zero will be treated as invalid address.  Then
> > > it requires drm won't allocate zero to drm buffer. And David in CC
> > > list has help us make a patch, please see attached. The logic is only
> > > for ppgtt, and he said zero offset is used under ggtt. My question is
> > > what is offset zero used under ggtt? Will it make sure zero is not
> > > allocatable to drm buffer object?
> > 
> > The code in i915_gem_execbuf.c already supports an optional bias to avoid
> > putting a buffer into the first few kb. See __EXEC_OBJECT_NEEDS_BIAS. I
> > suggest you expose this to userspace, which also address your issue that
> > you didn't add an abi revision flag.
> 
> A better API would be to allow userspace to request a buffer to place at
> a specific point in the VM and fail if that is not possible aka
> soft-pinning. Then OCL could assign a bo to offset 0 and detect writes
> to the NULL address if it so desired. With full-ppgtt, userspace can be
> sure of being able to evict any location in its VM and so also allows
> graceful detection of scenarios under which it cannot provide the NULL
> address safety feature (and opt not to run, or just bury its head in the
> sand).

I recommended exposing the PIN_BIAS since that will work without full
ppgtt too. And yeah for full ppgtt we could just use svm where userspace
controls the address, but since that's still a bit out we might need a
quick interim solution?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch