On ke, 2017-03-29 at 16:56 +0100, Chris Wilson wrote: > The advent of full-ppgtt lead to an extra indirection between the object > and its binding. That extra indirection has a noticeable impact on how > fast we can convert from the user handles to our internal vma for > execbuffer. In order to bypass the extra indirection, we use a > resizable hashtable to jump from the object to the per-ctx vma. > rhashtable was considered but we don't need the online resizing feature > and the extra complexity proved to undermine its usefulness. Instead, we > simply reallocate the hastable on demand in a background task and > serialize it before iterating. > > In non-full-ppgtt modes, multiple files and multiple contexts can share > the same vma. This leads to having multiple possible handle->vma links, > so we only use the first to establish the fast path. The majority of > buffers are not shared and so we should still be able to realise > speedups with multiple clients. > > v2: Prettier names, more magic. > v3: Many style tweaks, notable hiding the misuse of execobj[].rsvd2 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Changelog checks out. 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
