[Intel-gfx] [PATCH 10/39] drm/i915/execlists: Minimalistic timeslicing

If we have multiple contexts of equal priority pending execution, activate a timer to demote the currently executing context in favour of the next in the queue when that timeslice expires. This enforces fairness between contexts (so long as they allow preemption -- forced preemption, in the future,

[Intel-gfx] [PATCH 19/39] drm/i915: Provide an i915_active.acquire callback

If we introduce a callback for i915_active that is only called the first time we use the i915_active and is symmetrically paired with the i915_active.retire callback, we can replace the open-coded and non-atomic implementations -- which will be very fragile (i.e. broken) upon removing the struct_mu

[Intel-gfx] [PATCH 22/39] drm/i915: Forgo last_fence active request tracking

We were using the last_fence to track the last request that used this vma that might be interpreted by a fence register and forced ourselves to wait for this request before modifying any fence register that overlapped our vma. Due to requirement that we need to track any XY_BLT command, linear or t

[Intel-gfx] [PATCH 16/39] drm/i915: Execute signal callbacks from no-op i915_request_wait

If we enter i915_request_wait() with an already completed request, but unsignaled dma-fence, signal the fence before returning. This allows us to execute any of the signal callbacks at the earliest opportunity. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file ch

[Intel-gfx] [PATCH 18/39] drm/i915: Throw away the active object retirement complexity

Remove the accumulated optimisations that we have for i915_vma_retire and reduce it to the bare essential of tracking the active object reference. This allows us to only use atomic operations, and so will be able to avoid the struct_mutex requirement. The principal loss here is the shrinker MRU bu

[Intel-gfx] [PATCH 07/39] drm/i915: Replace engine->timeline with a plain list

To continue the onslaught of removing the assumption of a global execution ordering, another casualty is the engine->timeline. Without an actual timeline to track, it is overkill and we can replace it with a much less grand plain list. We still need a list of requests inflight, for the simple purpo

[Intel-gfx] [PATCH 08/39] drm/i915: Flush the execution-callbacks on retiring

In the unlikely case the request completes while we regard it as not even executing on the GPU (see the next patch!), we have to flush any pending execution callbacks at retirement and ensure that we do not add any more. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 93 ++

[Intel-gfx] [PATCH 11/39] drm/i915/execlists: Force preemption

If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging

[Intel-gfx] [PATCH 26/39] drm/i915: Only track bound elements of the GTT

The premise here is to simply avoiding having to acquire the vm->mutex inside vma create/destroy to update the vm->unbound_lists, to avoid some nasty lock recursions later. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +- drivers/gpu/drm/i915/i915_gem_gtt.c

[Intel-gfx] [PATCH 29/39] drm/i915: Make i915_vma track its own kref

Throughout the code base we internally track vma (objects bound into a particular GTT), with the objects themselves being the common backing storage. By making the vma itself reference counted we can start operating on the vma concurrently, moving work into async threads. Just the conversion to ma

[Intel-gfx] [PATCH 17/39] drm/i915: Make the semaphore saturation mask global

The idea behind keeping the saturation mask local to a context backfired spectacularly. The premise with the local mask was that we would be more proactive in attempting to use semaphores after each time the context idled, and that all new contexts would attempt to use semaphores ignoring the curre

[Intel-gfx] [PATCH 06/39] drm/i915: Stop retiring along engine

We no longer track the execution order along the engine and so no longer need to enforce ordering of retire along the engine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 128 +++- 1 file changed, 52 insertions(+), 76 deletions(-) diff --git a/dr

[Intel-gfx] [PATCH 15/39] dma-fence: Always execute signal callbacks

Allow for some users to surreptiously insert lazy signal callbacks that do not depend on enabling the signaling mechanism around every fence. This means that we may have a cb_list even if the signaling bit is not enabled, so always notify the callbacks. The cost is that dma_fence_signal() must alw

[Intel-gfx] [PATCH 20/39] drm/i915: Push the i915_active.retire into a worker

As we need to use a mutex to serialisation i915_active activation (because we want to allow the callback to sleep), we need to push the i915_active.retire into a worker callback in case we get need to retire from an atomic context. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_active

[Intel-gfx] [PATCH 05/39] drm/i915: Keep contexts pinned until after the next kernel context switch

We need to keep the context image pinned in memory until after the GPU has finished writing into it. Since it continues to write as we signal the final breadcrumb, we need to keep it pinned until the request after it is complete. Currently we know the order in which requests execute on each engine,

[Intel-gfx] [PATCH 39/39] active-rings

--- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 38 drivers/gpu/drm/i915/gem/i915_gem_pm.c| 6 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 - drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 - drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 12 ++- drivers/gpu/dr

[Intel-gfx] [PATCH 31/39] drm/i915: Allow page pinning to be in the background

Assume that pages may be pinned in a background task and use a completion event to synchronise with callers that must access the pages immediately. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 + drivers/gpu/drm/i915/gem/i915_gem_o

[Intel-gfx] [PATCH 09/39] drm/i915/execlists: Preempt-to-busy

When using a global seqno, we required a precise stop-the-workd event to handle preemption and unwind the global seqno counter. To accomplish this, we would preempt to a special out-of-band context and wait for the machine to report that it was idle. Given an idle machine, we could very precisely s

[Intel-gfx] [PATCH 14/39] dma-fence: Refactor signaling for manual invocation

Move the duplicated code within dma-fence.c into the header for wider reuse. In the process apply a small micro-optimisation to only prune the fence->cb_list once rather than use list_del on every entry. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/dma-buf/Makefile

[Intel-gfx] [PATCH 30/39] drm/i915: Propagate fence errors

Errors spread like wildfire, and must eventually be returned to the user. They need to be captured and passed along the flow of fences, infecting each in turn with the existing error, until finally they fall out of a user visible result. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

[Intel-gfx] WIP glance towards struct_mutex removal

This series is still under development, getting the coordination right for async vma (having just make i915_vma refcounted, I need to actually prevent the refcycles and fixup good old userspace in ggtt, vma->open_count for everyone incl. gem_vm_ops). [PATCH 01/39] drm/i915: Discard some redundant

[Intel-gfx] [PATCH 37/39] drm/i915: Use forced preemptions in preference over hangcheck

How well does this work in practice? It means that unless someone else is attempting to run we do not reset infinite loops. Maybe that is a good thing. Opens: * This sacrifices error capture. Maybe make that an opt-in with a watchdog. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ur

[Intel-gfx] [PATCH 03/39] drm/i915: Avoid tainting i915_gem_park() with wakeref.lock

While we need to flush the wakeref before parking, we do not need to perform the i915_gem_park() itself underneath the wakeref lock, merely the struct_mutex. If we rearrange the locks, we can avoid the unnecessary tainting. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_pm.c |

[Intel-gfx] [PATCH 23/39] drm/i915: Extract intel_frontbuffer active tracking

Move the active tracking for the frontbuffer operations out of the i915_gem_object and into its own first class (refcounted) object. In the process of detangling, we switch from low level request tracking to the easier i915_active -- with the plan that this avoids any potential atomic callbacks as

[Intel-gfx] [PATCH 21/39] drm/i915/overlay: Switch to using i915_active tracking

Remove the raw i915_active_request tracking in favour of the higher level i915_active tracking for the sole purpose of making the lockless transition easier in later patches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_active.h | 19 drivers/gpu/drm/i915/intel_overlay.c | 1

[Intel-gfx] [PATCH 35/39] drm/i915: Pin pages before waiting

In order to allow for asynchronous gathering of pages tracked by the obj->resv, we take advantage of pinning the pages before doing waiting on the reservation, and where possible do an early wait before acquiring the object lock (with a follow up locked waited to ensure we have exclusive access whe

[Intel-gfx] [PATCH 25/39] drm/i915: Track ggtt fence reservations under its own mutex

We can reduce the locking for fence registers from the dev->struct_mutex to a local mutex. We could introduce a mutex for the sole purpose of tracking the fence acquisition, except there is a little bit of overlap with the fault tracking, so use the i915_ggtt.mutex as it covers both. Signed-off-by

[Intel-gfx] [PATCH 02/39] drm/i915: Refine i915_reset.lock_map

We already use a mutex to serialise i915_reset() and wedging, so all we need it to link that into i915_request_wait() and we have our lock cycle detection. v2.5: Take error mutex for selftests Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_reset.c|

[Intel-gfx] [PATCH 24/39] drm/i915: Coordinate i915_active with its own mutex

Forgo the struct_mutex serialisation for i915_active, and interpose its own mutex handling for active/retire. This is a multi-layered sleight-of-hand. First, we had to ensure that no active/retire callbacks accidentally inverted the mutex ordering rules, nor assumed that they were themselves seria

[Intel-gfx] [PATCH 36/39] drm/i915: Use reservation_object to coordinate userptr get_pages()

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 27 +-- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 - drivers/gpu/drm/i915/gem/i915_gem_internal.c | 30 +-- .../gpu/drm/i915/gem/i915_gem_object_types.h | 11 +- drivers/gpu/drm/i915/gem/i915_gem_pages.

[Intel-gfx] [PATCH 32/39] drm/i915: Allow vma binding to occur asynchronously

If we let pages be allocated asynchronously, we also then want to push the binding process into an asynchronous task. Make it so, utilising the recent improvements to fence error tracking and struct_mutex reduction. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c|

[Intel-gfx] [PATCH 27/39] drm/i915: Explicitly cleanup initial_plane_config

I am about to stuff more objects into the plane_config and would like to have it clean up after itself. Move the current framebuffer release into a common function so it can be extended with the new object with relative ease. Signed-off-by: Chris Wilson Cc: Ville Syrjälä --- drivers/gpu/drm/i91

[Intel-gfx] [PATCH 34/39] drm/i915: Use vm->mutex for serialising GTT insertion

Serialising insertion into each of the global GTT and ppGTT accounts for a large chunk of the current struct_mutex serialisation requireemnts. (Note that it is not just the drm_mm / gtt management itself being serialised, but the pin count and various flags.) Previously, the main blocker for replac

[Intel-gfx] [PATCH 38/39] drm/i915: Remove logical HW ID

We only need to keep a unique tag for the active lifetime of the context, and for as long as we need to identify that context. The HW uses the tag to determine if it should use a lite-restore (why not the LRCA?) and passes the tag back for various status identifies. The only status we need to track

[Intel-gfx] [PATCH 33/39] revoke-fence

--- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 16 ++-- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 ++--- drivers/gpu/drm/i915/i915_gem.c | 38 --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 16 ++-- drivers/gpu/drm/i915/i915_vma.c

[Intel-gfx] [PATCH 04/39] drm/i915: Enable refcount debugging for default debug levels

refcount_t is our first line of defence against use-after-free, so let's enable it for debugging. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index

[Intel-gfx] [PATCH 28/39] initial-plane-vma

--- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 88 +++-- drivers/gpu/drm/i915/i915_drv.h| 1 - drivers/gpu/drm/i915/intel_display.c | 146 + drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c| 1 - 5

[Intel-gfx] [PATCH 01/39] drm/i915: Discard some redundant cache domain flushes

Since commit a679f58d0510 ("drm/i915: Flush pages on acquisition"), we flush objects on acquire their pages and as such when we create an object for the purpose of writing into it, we do not need to manually flush. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/selftests/i915_gem_conte

[Intel-gfx] [PATCH 13/39] dma-fence: Report the composite sync_file status

Same as for the individual fences, we want to report the actual status of the fence when queried. Reported-by: Petri Latvala Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo Padovan Cc: Petri Latvala --- drivers/dma-buf/sync_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-

[Intel-gfx] [PATCH 12/39] dma-fence: Propagate errors to dma-fence-array container

When one of the array of fences is signaled, propagate its errors to the parent fence-array (keeping the first error to be raised). v2: Opencode cmpxchg_local to avoid compiler freakout. Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo Padovan --- drivers/dma-buf/dma-fence-array.c | 1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/39] drm/i915: Discard some redundant cache domain flushes

== Series Details == Series: series starting with [01/39] drm/i915: Discard some redundant cache domain flushes URL : https://patchwork.freedesktop.org/series/62085/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6eb3b4d8d4bd drm/i915: Discard some redundant cache domain flushe

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/39] drm/i915: Discard some redundant cache domain flushes

== Series Details == Series: series starting with [01/39] drm/i915: Discard some redundant cache domain flushes URL : https://patchwork.freedesktop.org/series/62085/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Discard some redundant cache

Re: [Intel-gfx] [PATCH] drm/amdgpu: Fix connector atomic_check compilation fail

Op 14-06-2019 om 02:27 schreef Sean Paul: > From: Sean Paul > > I missed amdgpu in my connnector_helper_funcs->atomic_check conversion, > which is understandably causing compilation failures. > > Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to > accept drm_atomic_state"

Re: [Intel-gfx] [PATCH] drm/i915: Refine eDP aux backlight enable sequence.

On Fri, 14 Jun 2019, "Lee, Shawn C" wrote: > On Thu, 13 Jun 2019, Jani Nikula wrote: >>On Thu, 13 Jun 2019, Ville Syrjälä wrote: >>> On Wed, Jun 12, 2019 at 10:47:22PM -0700, Lee, Shawn C wrote: Modify aux backlight enable sequence just like what we did for genernal eDP panel. 1.

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add backlight enable on/off delay for DP aux backlight control

On Thu, 13 Jun 2019, "Lee, Shawn C" wrote: > Follow generla eDP backlight enable control sequence. Add T8 (valid video > data to backlight enable) delay before turn backlight_enable on. > And T9 (backlight disable to end of valida video data) delay after > backlight_enable off. There are two thin

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 1/4] meson: add libatomic dependency

On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote: > Add conditional dependency on libatomic in order to be able to use the > __atomic_* functions instead of the older __sync_* ones. The > libatomic library is only needed when there aren't any native support > on the current architecture,

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/4] gitlab-ci: add libatomic to docker images

On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote: > Add libatomic to the Fedora docker image so it can link binaries that > use __atomic_* functions. Also explicitly add libatomic1 to Debian > docker images even though it's already installed as a dependency. > > Signed-off-by: Guillaume

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 3/4] i915/gem_create: use atomic_* instead of __sync_*

On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote: > This fixes builds on some architectures, in particular MIPS which > doesn't have __sync_add_and_fetch_8 and __sync_val_compare_and_swap_8 > for 64-bit variable handling. > > * replace calls to the older __sync_* functions with the new at

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 4/4] tests/sw_sync: use atomic_* instead of __sync_*

On Thu, 2019-06-13 at 14:53 +0100, Guillaume Tucker wrote: > Replace calls to the older __sync_* functions with the new atomic_* > standard ones to be consistent with other tests and improve > portability across CPU architectures. Add dependency of sw_sync on > libatomic. > > Signed-off-by: Guill

Re: [Intel-gfx] [PATCH] drm/ioctl: Ditch DRM_UNLOCKED except for the legacy vblank ioctl

On Fri, Jun 07, 2019 at 11:24:01AM +0100, Emil Velikov wrote: > On Wed, 5 Jun 2019 at 13:08, Daniel Vetter wrote: > > > > This completes Emil's series of removing DRM_UNLOCKED from modern > > drivers. It's entirely cargo-culted since we ignore it on > > non-DRIVER_LEGACY drivers since: > > > > com

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add backlight enable on/off delay for DP aux backlight control

On Fri, 14 Jun 2019, Jani Nikula wrote: >On Thu, 13 Jun 2019, "Lee, Shawn C" wrote: >> Follow generla eDP backlight enable control sequence. Add T8 (valid >> video data to backlight enable) delay before turn backlight_enable on. >> And T9 (backlight disable to end of valida video data) delay af

[Intel-gfx] [PULL] drm-misc-next

Hi Dave and Daniel, Next pull request, with more fixes and features! drm-misc-next-2019-06-14: drm-misc-next for v5.3: UAPI Changes: Cross-subsystem Changes: - Add code to signal all dma-fences when freed with pending signals. - Annotate reservation object access in CONFIG_DEBUG_MUTEXES Core C

Re: [Intel-gfx] [RFC 06/28] drm/i915: Convert i915_gem_init_swizzling to intel_gt

On 13/06/2019 14:49, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-13 14:35:17) From: Tvrtko Ursulin Start using the newly introduced struct intel_gt to fuse together correct logical init flow with uncore for more removal of implicit dev_priv in mmio access. Signed-off-by: Tvrtko Ursul

Re: [Intel-gfx] [PATCH 01/39] drm/i915: Discard some redundant cache domain flushes

On Fri, 14 Jun 2019 at 08:11, Chris Wilson wrote: > > Since commit a679f58d0510 ("drm/i915: Flush pages on acquisition"), we > flush objects on acquire their pages and as such when we create an acquiring > object for the purpose of writing into it, we do not need to manually > flush. > > Signed-

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep contexts pinned until after the next kernel context switch

Chris Wilson writes: > We need to keep the context image pinned in memory until after the GPU > has finished writing into it. Since it continues to write as we signal > the final breadcrumb, we need to keep it pinned until the request after > it is complete. Currently we know the order in which r

Re: [Intel-gfx] [RFC 06/28] drm/i915: Convert i915_gem_init_swizzling to intel_gt

Quoting Tvrtko Ursulin (2019-06-14 10:06:41) > > On 13/06/2019 14:49, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-06-13 14:35:17) > >> From: Tvrtko Ursulin > >> > >> Start using the newly introduced struct intel_gt to fuse together correct > >> logical init flow with uncore for more remo

[Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3

Hi all, As discussed with Daniel V, I'm just doing the paperwork here as drm-misc maintainer. This is the topic pull request for the fbdev notifier removal. Bar, please make a final check and pull into your fbdev tree. Lee, please make a final check and pull into your backlight tree. Greg, th

Re: [Intel-gfx] [RFC 13/28] drm/i915: Convert i915_gem_init_hw to intel_gt

On 13/06/2019 17:30, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-13 17:11:43) On 13/06/2019 14:59, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-13 14:35:24) From: Tvrtko Ursulin More removal of implicit dev_priv from using old mmio accessors. Actually the top level function

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep contexts pinned until after the next kernel context switch

Quoting Mika Kuoppala (2019-06-14 10:22:16) > Chris Wilson writes: > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c > > b/drivers/gpu/drm/i915/gt/intel_context.c > > index c78ec0b58e77..8e299c631575 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_context.c > > +++ b/drivers/gpu/drm/i915/gt

Re: [Intel-gfx] [PULL] drm-misc-next

On Fri, Jun 14, 2019 at 10:57:34AM +0200, Maarten Lankhorst wrote: > Hi Dave and Daniel, > > Next pull request, with more fixes and features! > > drm-misc-next-2019-06-14: > drm-misc-next for v5.3: > > UAPI Changes: > > Cross-subsystem Changes: > - Add code to signal all dma-fences when freed w

Re: [Intel-gfx] [RFC 16/28] drm/i915: Compartmentalize i915_ggtt_probe_hw

On 13/06/2019 15:03, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-13 14:35:27) From: Tvrtko Ursulin Having made start to better code compartmentalization by introducing struct intel_gt, continue the theme elsewhere in code by making functions take parameters take what logically makes m

Re: [Intel-gfx] [RFC 13/28] drm/i915: Convert i915_gem_init_hw to intel_gt

Quoting Tvrtko Ursulin (2019-06-14 10:34:06) > > On 13/06/2019 17:30, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-06-13 17:11:43) > >> > >> On 13/06/2019 14:59, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2019-06-13 14:35:24) > diff --git a/drivers/gpu/drm/i915/i915_gem.c > >>

Re: [Intel-gfx] [RFC 06/28] drm/i915: Convert i915_gem_init_swizzling to intel_gt

On 14/06/2019 10:24, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-14 10:06:41) On 13/06/2019 14:49, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-13 14:35:17) From: Tvrtko Ursulin Start using the newly introduced struct intel_gt to fuse together correct logical init flow with

Re: [Intel-gfx] [RFC 20/28] drm/i915: Compartmentalize i915_gem_suspend/restore_gtt_mappings

On 13/06/2019 15:08, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-13 14:35:31) From: Tvrtko Ursulin Having made start to better code compartmentalization by introducing struct intel_gt, continue the theme elsewhere in code by making functions take parameters take what logically makes m

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2] drm/i915: Keep contexts pinned until after the next kernel context switch (rev2)

== Series Details == Series: series starting with [v2] drm/i915: Keep contexts pinned until after the next kernel context switch (rev2) URL : https://patchwork.freedesktop.org/series/61946/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6251_full -> Patchwork_13254_full ==

Re: [Intel-gfx] [RFC 06/28] drm/i915: Convert i915_gem_init_swizzling to intel_gt

Quoting Tvrtko Ursulin (2019-06-14 10:42:11) > > On 14/06/2019 10:24, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-06-14 10:06:41) > >> > >> On 13/06/2019 14:49, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2019-06-13 14:35:17) > From: Tvrtko Ursulin > > Start using th

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/4] gitlab-ci: add libatomic to docker images

On Thu, Jun 13, 2019 at 02:53:20PM +0100, Guillaume Tucker wrote: > Add libatomic to the Fedora docker image so it can link binaries that > use __atomic_* functions. Also explicitly add libatomic1 to Debian > docker images even though it's already installed as a dependency. > > Signed-off-by: Gui

Re: [Intel-gfx] [PATCH i-g-t v2] gitlab-ci: add build for MIPS

On Thu, Jun 13, 2019 at 03:01:06PM +0100, Guillaume Tucker wrote: > Add Docker image and Gitlab CI steps to run builds for the MIPS > architecture using Debian Stretch with backports. > > Signed-off-by: Guillaume Tucker Same comment on libatomic1 as in the other thread applies here. -- Petri

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable refcount debugging for default debug levels

== Series Details == Series: drm/i915: Enable refcount debugging for default debug levels URL : https://patchwork.freedesktop.org/series/62027/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13270 Summary -

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: gvt: no need to check return value of debugfs_create functions

== Series Details == Series: i915: gvt: no need to check return value of debugfs_create functions URL : https://patchwork.freedesktop.org/series/62042/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13271 S

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Refine i915_reset.lock_map (rev3)

== Series Details == Series: drm/i915: Refine i915_reset.lock_map (rev3) URL : https://patchwork.freedesktop.org/series/62017/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13272 Summary --- **SUCCE

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep contexts pinned until after the next kernel context switch

Chris Wilson writes: > Quoting Mika Kuoppala (2019-06-14 10:22:16) >> Chris Wilson writes: >> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c >> > b/drivers/gpu/drm/i915/gt/intel_context.c >> > index c78ec0b58e77..8e299c631575 100644 >> > --- a/drivers/gpu/drm/i915/gt/intel_context.c >>

Re: [Intel-gfx] [RFC 16/28] drm/i915: Compartmentalize i915_ggtt_probe_hw

Quoting Tvrtko Ursulin (2019-06-14 10:35:57) > > On 13/06/2019 15:03, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-06-13 14:35:27) > >> From: Tvrtko Ursulin > >> > >> Having made start to better code compartmentalization by introducing > >> struct intel_gt, continue the theme elsewhere in

Re: [Intel-gfx] [RFC 20/28] drm/i915: Compartmentalize i915_gem_suspend/restore_gtt_mappings

Quoting Tvrtko Ursulin (2019-06-14 10:51:59) > > On 13/06/2019 15:08, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-06-13 14:35:31) > >> From: Tvrtko Ursulin > >> > >> Having made start to better code compartmentalization by introducing > >> struct intel_gt, continue the theme elsewhere in

Re: [Intel-gfx] [RFC 24/28] drm/i915: Compartmentalize i915_ggtt_cleanup_hw

On 13/06/2019 16:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-13 16:19:00) From: Tvrtko Ursulin Continuing on the theme of better logical organization of our code, make the first step towards making the ggtt code better isolated from wider struct drm_i915_private. Signed-off-by: T

Re: [Intel-gfx] [PATCH i-g-t v2] gitlab-ci: add build for MIPS

On Thu, Jun 13, 2019 at 03:01:06PM +0100, Guillaume Tucker wrote: > Add Docker image and Gitlab CI steps to run builds for the MIPS > architecture using Debian Stretch with backports. > > Signed-off-by: Guillaume Tucker > --- > .gitlab-ci.yml | 28 > Dockerfi

[Intel-gfx] [PATCH] drm/i915: Check visibility in icl_build_plane_wm

When a planar YUV plane is configured, but the crtc is marked inactive, we can end up with a linked plane without visibility. Handle this by checking for visibility early, instead of doing a WARN. <4> [201.742919] [ cut here ] <4> [201.742920] WARN_ON(!intel_wm_plane_visibl

Re: [Intel-gfx] [PATCH 16/39] drm/i915: Execute signal callbacks from no-op i915_request_wait

On 14/06/2019 08:10, Chris Wilson wrote: If we enter i915_request_wait() with an already completed request, but unsignaled dma-fence, signal the fence before returning. This allows us to execute any of the signal callbacks at the earliest opportunity. Signed-off-by: Chris Wilson --- drivers/

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: no need to check return value of debugfs_create functions (rev2)

== Series Details == Series: i915: no need to check return value of debugfs_create functions (rev2) URL : https://patchwork.freedesktop.org/series/62040/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13273

[Intel-gfx] [CI 2/2] drm/i915: Execute signal callbacks from no-op i915_request_wait

If we enter i915_request_wait() with an already completed request, but unsignaled dma-fence, signal the fence before returning. This allows us to execute any of the signal callbacks at the earliest opportunity. v2: Also signal after busyspin success Signed-off-by: Chris Wilson Reviewed-by: Tvrtk

[Intel-gfx] [CI 1/2] drm/i915: Discard some redundant cache domain flushes

Since commit a679f58d0510 ("drm/i915: Flush pages on acquisition"), we flush objects on acquire their pages and as such when we create an object for the purpose of writing into it, we do not need to manually flush. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/g

Re: [Intel-gfx] [PATCH 29/39] drm/i915: Make i915_vma track its own kref

On Fri, 14 Jun 2019 at 08:10, Chris Wilson wrote: > > Throughout the code base we internally track vma (objects bound into > a particular GTT), with the objects themselves being the common backing > storage. By making the vma itself reference counted we can start > operating on the vma concurrentl

Re: [Intel-gfx] [PATCH 29/39] drm/i915: Make i915_vma track its own kref

Quoting Matthew Auld (2019-06-14 12:15:27) > On Fri, 14 Jun 2019 at 08:10, Chris Wilson wrote: > > > > Throughout the code base we internally track vma (objects bound into > > a particular GTT), with the objects themselves being the common backing > > storage. By making the vma itself reference co

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/4] gitlab-ci: add libatomic to docker images

On Fri, 2019-06-14 at 13:00 +0300, Petri Latvala wrote: > On Thu, Jun 13, 2019 at 02:53:20PM +0100, Guillaume Tucker wrote: > > Add libatomic to the Fedora docker image so it can link binaries that > > use __atomic_* functions. Also explicitly add libatomic1 to Debian > > docker images even though

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: PATH prop for all connectors?

== Series Details == Series: drm: PATH prop for all connectors? URL : https://patchwork.freedesktop.org/series/62061/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13274 Summary --- **SUCCESS** N

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: kerneldoc warnings squelched

== Series Details == Series: drm/i915: kerneldoc warnings squelched URL : https://patchwork.freedesktop.org/series/61969/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6252_full -> Patchwork_13255_full Summary --- **

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Check visibility in icl_build_plane_wm

== Series Details == Series: drm/i915: Check visibility in icl_build_plane_wm URL : https://patchwork.freedesktop.org/series/62098/ State : warning == Summary == $ dim checkpatch origin/drm-tip 534240f724bc drm/i915: Check visibility in icl_build_plane_wm -:13: WARNING:COMMIT_LOG_LONG_LINE: Po

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/4] gitlab-ci: add libatomic to docker images

On Fri, Jun 14, 2019 at 02:24:53PM +0300, Ser, Simon wrote: > On Fri, 2019-06-14 at 13:00 +0300, Petri Latvala wrote: > > On Thu, Jun 13, 2019 at 02:53:20PM +0100, Guillaume Tucker wrote: > > > Add libatomic to the Fedora docker image so it can link binaries that > > > use __atomic_* functions. Al

Re: [Intel-gfx] [PATCH] gpu/drm/i915: globally replace dev_priv with i915

On Thu, 13 Jun 2019, Rodrigo Vivi wrote: > On Thu, Jun 13, 2019 at 09:48:16AM -0700, Lucas De Marchi wrote: >> On Thu, Jun 13, 2019 at 09:29:48AM -0700, Lucas De Marchi wrote: >> > On Thu, Jun 13, 2019 at 04:12:37PM +0300, Jani Nikula wrote: >> > > On Wed, 12 Jun 2019, Lucas De Marchi wrote: >> >

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/4] gitlab-ci: add libatomic to docker images

On Fri, 2019-06-14 at 15:43 +0300, Petri Latvala wrote: > On Fri, Jun 14, 2019 at 02:24:53PM +0300, Ser, Simon wrote: > > On Fri, 2019-06-14 at 13:00 +0300, Petri Latvala wrote: > > > On Thu, Jun 13, 2019 at 02:53:20PM +0100, Guillaume Tucker wrote: > > > > Add libatomic to the Fedora docker image

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Refine placement of gt.reset_lockmap

== Series Details == Series: drm/i915: Refine placement of gt.reset_lockmap URL : https://patchwork.freedesktop.org/series/61973/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6253_full -> Patchwork_13256_full Summary -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Discard some redundant cache domain flushes

== Series Details == Series: drm/i915: Discard some redundant cache domain flushes URL : https://patchwork.freedesktop.org/series/62067/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13275 Summary ---

[Intel-gfx] [PATCH] drm/i915/guc: Check if reset is supported before attempting to reset GuC

Let's trust both the user (i915.reset modparam) and device caps instead of attempting to reset unconditionally. Signed-off-by: Michał Winiarski Cc: Arkadiusz Hiler Cc: Michal Wajdeczko Cc: Stuart Summers Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_uc.c | 5 + 1 file changed, 5 inse

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915: Don't clobber M/N values during fastset check (rev2)

== Series Details == Series: series starting with [v2,1/4] drm/i915: Don't clobber M/N values during fastset check (rev2) URL : https://patchwork.freedesktop.org/series/61960/ State : success == Summary == CI Bug Log - changes from CI_DRM_6253_full -> Patchwork_13257_full

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_shared: Prefer explicit domain control

Chris Wilson writes: > Since we are fiddling behind the scenes, we are writing to objects that > are not part of the execbuffer, do not rely on implicit domain > management being able to track the appropriate CPU cache status. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110890 > Si

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Update MOCS table for EHL (rev2)

== Series Details == Series: drm/i915/ehl: Update MOCS table for EHL (rev2) URL : https://patchwork.freedesktop.org/series/61409/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13276 Summary --- **SU

Re: [Intel-gfx] [PATCH v3 0/8] RPM encapsulation

On Thu, Jun 13, 2019 at 04:21:48PM -0700, Daniele Ceraolo Spurio wrote: > Same as v2, just rebased (some code moved + a couple of new get/put > calls that had to be updated) > > Cc: Imre Deak > Reviewed-by: Chris Wilson Looks ok to me: Acked-by: Imre Deak > > Daniele Ceraolo Spurio (8): >

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Enable Multi-segmented-gamma for ICL (rev4)

On 13/06/2019 10:39, Shankar, Uma wrote: > > >> -Original Message- >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >> Patchwork >> Sent: Thursday, June 13, 2019 12:36 PM >> To: Sharma, Shashank >> Cc: intel-gfx@lists.freedesktop.org >> Subject: [Intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add Wa_1409120013:icl,ehl (rev3)

== Series Details == Series: drm/i915: Add Wa_1409120013:icl,ehl (rev3) URL : https://patchwork.freedesktop.org/series/61867/ State : success == Summary == CI Bug Log - changes from CI_DRM_6253_full -> Patchwork_13258_full Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for RPM Encapsulation (rev2)

== Series Details == Series: RPM Encapsulation (rev2) URL : https://patchwork.freedesktop.org/series/61976/ State : success == Summary == CI Bug Log - changes from CI_DRM_6265 -> Patchwork_13277 Summary --- **SUCCESS** No regressi

  1   2   3   4   >