• Chris Wilson's avatar
    drm/i915: Introduce an internal allocator for disposable private objects · 920cf419
    Chris Wilson authored
    Quite a few of our objects used for internal hardware programming do not
    benefit from being swappable or from being zero initialised. As such
    they do not benefit from using a shmemfs backing storage and since they
    are internal and never directly exposed to the user, we do not need to
    worry about providing a filp. For these we can use an
    drm_i915_gem_object wrapper around a sg_table of plain struct page. They
    are not swap backed and not automatically pinned. If they are reaped
    by the shrinker, the pages are released and the contents discarded. For
    the internal use case, this is fine as for example, ringbuffers are
    pinned from being written by a request to be read by the hardware. Once
    they are idle, they can be discarded entirely. As such they are a good
    match for execlist ringbuffers and a small variety of other internal
    objects.
    
    In the first iteration, this is limited to the scratch batch buffers we
    use (for command parsing and state initialisation).
    
    v2: Allocate physically contiguous pages, where possible.
    v3: Reduce maximum order on subsequent requests following an allocation
    failure.
    v4: Fix up mismatch between swiotlb segment size and page count (it
    counts in 2k units, not 4k pages)
    Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-7-chris@chris-wilson.co.uk
    920cf419
i915_gem_render_state.c 5.98 KB