[Intel-gfx] [PATCH] drm/i915: Introduce a new create ioctl for user specified placement

[Chris Wilson]

On Mon, Jul 08, 2013 at 10:57:09PM +0200, Daniel Vetter wrote:
> On Fri, Jul 05, 2013 at 02:42:04PM +0100, Chris Wilson wrote:
> > Despite being a unified memory architecture (UMA) some bits of memory
> > are more equal than others. In particular we have the thorny issue of
> > stolen memory, memory stolen from the system by the BIOS and reserved
> > for igfx use. Stolen memory is required for some functions of the GPU
> > and display engine, but in general it goes wasted. Whilst we cannot
> > return it back to the system, we need to find some other method for
> > utilising it. As we do not support direct access to the physical address
> > in the stolen region, it behaves like a different class of memory,
> > closer in kin to local GPU memory. This strongly suggests that we need a
> > placement model like TTM if we are to fully utilize these discrete
> > chunks of differing memory.
> > 
> > This new create ioctl therefore exists to allow the user to create these
> > second class buffer objects from stolen memory. At the moment direct
> > access by the CPU through mmaps and pread/pwrite are verboten on the
> > objects, and so the user must be aware of the limitations of the objects
> > created. Yet, those limitations rarely reduce the desired functionality
> > in many use cases and so the user should be able to easily fill the
> > stolen memory and so help to reduce overall memory pressure.
> > 
> > The most obvious use case for stolen memory is for the creation of objects
> > for the display engine which already have very similar restrictions on
> > access. However, we want a reasonably general ioctl in order to cater
> > for diverse scenarios beyond the author's imagination.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> Looks like a sane idea. But I think we should call the new placement flags
> placaments, not domains, since imo they are a rather different concept
> than what we currently call domains.
> 
> I also wonder whether we should have some for of initial domain (for
> people who want to do the clflushing up-front, or in case we ever get a
> clflushed page-cache), but the spare bits in flags should be good enough.
> Or maybe leave the domain ioctl struct member and move the placement
> defines to the high bits.

placement, read_domains, write_domain?

FLAG_UNINITIALIZED && capable(SYS_ADMIN) - avoid having to clear stolen?

domains could be an u16 and still allow for expansion,
placement and tiling could be as small as a u8. But is it worth triming
the bit count? We have to keep the struct below 128 to benefit from the
onstack copy, and keeping the copy as small as possible is good, but we
should also leave room for future expansion. So include pad[1234]?

I don't see this as being a (comparatively) frequently called function.

> And I want i-g-t tests, both basic functionality tests and checking
> whether all the verboten stuff is indeed forbidden.

We don't have enough queries for userspace to check that the kernel is
obeying its instructions. But we can at least check the restrictions on
ABI are enforced.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre