Re: [PATCH 06/38] drm/i915: Pad GTT views of exec objects up to user specified size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 08, 2016 at 11:41:01AM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 05:55:21PM +0100, Chris Wilson wrote:
> > Our GPUs impose certain requirements upon buffers that depend upon how
> > exactly they are used. Typically this is expressed as that they require
> > a larger surface than would be naively computed by pitch * height.
> > Normally such requirements are hidden away in the userspace driver, but
> > when we accept pointers from strangers and later impose extra conditions
> > on them, the original client allocator has no idea about the
> > monstrosities in the GPU and we require the userspace driver to inform
> > the kernel how many padding pages are required beyond the client
> > allocation.
> > 
> > v2: Long time, no see
> > v3: Try an anonymous union for uapi struct compatability
> > 
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> 
> Hm, where's the userspace for this? Commit message should elaborate imo a
> bit more on what's going on here ...

ddx, igt both posted.

For dri3 the client passes us a buffer with one size that may not match
all uses (but is sufficient for its intended). At the moment we reject
it, but I could allow it through and pad the missing pages in the GTT
instead (ala lazy fencing). 

The earliest motivation for this was for OpenCL wrapping blobs of
userspace and trying to manage the similar problem that the client
memory may not match the actual requirements of the GPU.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux