On 17-07-27 10:25:51, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-27 10:05:00)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Yet another attempt to get this series reviewed and merged...
I've heard Vulkan might be creating a lot of userptr objects so might be
interesting to check what benefit it brings to those use cases.
Optimist :) My thinking is that this should only impact get_pages ->
vma_bind, which is supposed a rare operation, and if should happen as
part of the steady state that we have too many sg in a chain is just one
of the myriad little paper cuts :)
Vulkan is critically dependent on userptr, but I don't believe we create many
usrptr BOs as the implementation and API reduce the number of BOs in general.
I don't see any reason not to do any of this though. Series is
Acked-by: Ben Widawsky <ben@xxxxxxxxxxxx>
As an introduction, this allows i915 to create fewer sg table entries for the bo
backing store representation. As such it primarily saves kernel slab memory.
When we added this optimisation to normal i915 bos, the savings were as far as
I remember around 1-2MiB of slab after booting to KDE desktop, and 2-4Mib on
neverball (game) main screen (or maybe it was while playing).
I think we also want to think about the aspect where we are creating
objects of multiple 1G huge pages, so we are going to run into the sg
limits very quickly.
-Chris
--
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
