On la, 2016-10-08 at 09:34 +0100, Chris Wilson wrote: > 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. Does not hurt, but what does it gain us, exactly? > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
