kernel/drivers/gpu/drm/i915/i915_utils.h, branch linux-4.17.y

drm/i915: Move some utility functions to i915_util.h

2017-12-22T09:13:47Z

We have dedicated header file for utility functions and macros. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Joonas Lahtinen Reviewed-by: Chris Wilson Acked-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20171221185334.17396-2-michal.wajdeczko@intel.com Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20171221215735.30314-1-chris@chris-wilson.co.uk

drm/i915: Warn in debug builds of incorrect usages of ptr_pack_bits

2017-11-03T09:28:06Z

GEM_BUG_ON if the packed bits do not fit into the specified width. v2: Avoid using the macro argument twice. v3: Drop unnecessary braces. (Joonas) Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson (v1) Reviewed-by: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/20171103090538.14474-1-tvrtko.ursulin@linux.intel.com

drm/i915: Try harder to finish the idle-worker

2017-10-06T16:49:46Z

If a worker requeues itself, it may switch to a different kworker pool, which flush_work() considers as complete. To be strict, we then need to keep flushing the work until it is no longer pending. References: https://bugs.freedesktop.org/show_bug.cgi?id=102456 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Reviewed-by: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/20171006104038.22337-1-chris@chris-wilson.co.uk

drm/i915: Fix pointer-to-int conversion

2017-10-06T15:29:47Z

Commit faf654864b25 ("drm/i915: Unify uC variable types to avoid flooding checkpatch.pl") breaks 32-bit kernel builds. Lets use cast helper to make compiler happy. v2: introduce ptr_to_u64 (Chris) Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20171006130844.49012-1-michal.wajdeczko@intel.com Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson

drm/i915: Store a direct lookup from object handle to vma

2017-06-16T15:54:04Z

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, most notably hiding the misuse of execobj[].rsvd2 Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

drm/i915: Split execlist priority queue into rbtree + linked list

2017-05-17T12:38:09Z

All the requests at the same priority are executed in FIFO order. They do not need to be stored in the rbtree themselves, as they are a simple list within a level. If we move the requests at one priority into a list, we can then reduce the rbtree to the set of priorities. This should keep the height of the rbtree small, as the number of active priorities can not exceed the number of active requests and should be typically only a few. Currently, we have ~2k possible different priority levels, that may increase to allow even more fine grained selection. Allocating those in advance seems a waste (and may be impossible), so we opt for allocating upon first use, and freeing after its requests are depleted. To avoid the possibility of an allocation failure causing us to lose a request, we preallocate the default priority (0) and bump any request to that priority if we fail to allocate it the appropriate plist. Having a request (that is ready to run, so not leading to corruption) execute out-of-order is better than leaking the request (and its dependency tree) entirely. There should be a benefit to reducing execlists_dequeue() to principally using a simple list (and reducing the frequency of both rbtree iteration and balancing on erase) but for typical workloads, request coalescing should be small enough that we don't notice any change. The main gain is from improving PI calls to schedule, and the explicit list within a level should make request unwinding simpler (we just need to insert at the head of the list rather than the tail and not have to make the rbtree search more complicated). v2: Avoid use-after-free when deleting a depleted priolist v3: Michał found the solution to handling the allocation failure gracefully. If we disable all priority scheduling following the allocation failure, those requests will be executed in fifo and we will ensure that this request and its dependencies are in strict fifo (even when it doesn't realise it is only a single list). Normal scheduling is restored once we know the device is idle, until the next failure! Suggested-by: Michał Wajdeczko Signed-off-by: Chris Wilson Cc: Michał Winiarski Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Reviewed-by: Michał Winiarski Reviewed-by: Tvrtko Ursulin Link: http://patchwork.freedesktop.org/patch/msgid/20170517121007.27224-8-chris@chris-wilson.co.uk

drm/i915: Redefine ptr_pack_bits() and friends

2017-05-17T12:38:04Z

Rebrand the current (pointer | bits) pack/unpack utility macros as explicit bit twiddling for PAGE_SIZE so that we can use the more flexible underlying macros for different bits. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/20170517121007.27224-4-chris@chris-wilson.co.uk

drm/i915: Make ptr_unpack_bits() more function-like

2017-05-17T12:38:03Z

ptr_unpack_bits() is a function-like macro, as such it is meant to be replaceable by a function. In this case, we should be passing in the out-param as a pointer. Bizarrely this does affect code generation: function old new delta i915_gem_object_pin_map 409 389 -20 An improvement(?) in this case, but one can't help wonder what strict-aliasing optimisations we are preventing. The generated code looks identical in using ptr_unpack_bits (no extra motions to stack, the pointer and bits appear to be kept in registers), the difference appears to be code ordering and with a reorder it is able to use smaller forward jumps. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/20170517121007.27224-3-chris@chris-wilson.co.uk

drm/i915: Move uncore definitions into a separate header

2017-05-09T13:02:47Z

In order to allow use of e.g. forcewake_domains in a other feature headers included from the top of i915_drv.h, move all uncore related definitions into their own header. v2: move __mask_next_bit macro to utils header (Mika) Signed-off-by: Michal Wajdeczko Suggested-by: Joonas Lahtinen Cc: Joonas Lahtinen Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala Signed-off-by: Mika Kuoppala

drm/i915: Move WARN_ON/MISSING_CASE macros to i915_utils.h

2017-03-29T10:10:28Z

We can't sometimes use these macros in other headers due to include and definition order. As i915_utils.h already contains other helper macros move these macros there. v2: checkpatch cleanup for WARN() macro. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/20170328084513.174200-1-michal.wajdeczko@intel.com Signed-off-by: Chris Wilson