[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [01/55] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling()

== Series Details == Series: series starting with [01/55] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling() URL : https://patchwork.freedesktop.org/series/10246/ State : warning == Summary == Series 10246v1 Series without cover letter

Re: [Intel-gfx] [PATCH 31/55] drm/i915: Amalgamate GGTT/ppGTT vma debug list walkers

On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > As we can now have multiple VMA inside the global GTT (with partial > mappings, rotations, etc), it is no longer true that there may just be a > single GGTT entry and so we should walk the full vma_list to count up > the actual usage. In

Re: [Intel-gfx] [PATCH 17/55] drm/i915: Simplify request_alloc by returning the allocated request

On ma, 2016-07-25 at 18:31 +0100, Chris Wilson wrote: > If is simpler and leads to more readable code through the callstack if > the allocation returns the allocated struct through the return value. > > The importance of this is that it no longer looks like we accidentally > allocate requests as

Re: [Intel-gfx] [PATCH 01/55] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling()

On ma, 2016-07-25 at 18:31 +0100, Chris Wilson wrote: > Since intel_engine_enable_signaling() is now only called via > fence_enable_sw_signaling(), we can rely on it to provide serialisation > and run-once for us and so make ourselves slightly simpler. > Done in previous series, copying here;

Re: [Intel-gfx] [PATCH 16/55] drm/i915: Remove obsolete engine->gpu_caches_dirty

On ma, 2016-07-25 at 18:31 +0100, Chris Wilson wrote: > Space for flushing the GPU cache prior to completing the request is > preallocated and so cannot fail - the GPU caches will always be flushed > along with the completed request. This means we no longer have to track > whether the GPU cache is

Re: [Intel-gfx] [PATCH 08/55] drm/i915: Remove stray intel_engine_cs ring identifiers from i915_gem.c

On ma, 2016-07-25 at 18:31 +0100, Chris Wilson wrote: > A few places we use ring when referring to the struct intel_engine_cs. An > anachronism we are pruning out. > > Signed-off-by: Chris Wilson > Link: >

Re: [Intel-gfx] [PATCH 07/55] drm/i915: Avoid using intel_engine_cs *ring for GPU error capture

On ma, 2016-07-25 at 18:31 +0100, Chris Wilson wrote: > Inside the error capture itself, we refer to not only the hardware > engine, its ringbuffer but also the capture state. Finding clear names > for each whilst avoiding mixing ring/intel_engine_cs is tricky. As a > compromise we keep using

Re: [Intel-gfx] [PATCH 01/31] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling()

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > Since intel_engine_enable_signaling() is now only called via > fence_enable_sw_signaling(), we can rely on it to provide serialisation > and run-once for us and so make ourselves slightly simpler. > Originally left this patch for Tvrtko,

[Intel-gfx] [PATCH 32/55] drm/i915: Split early global GTT initialisation

Initialising the global GTT is tricky as we wish to use the drm_mm range manager during the modesetting initialisation (to capture stolen allocations from the BIOS) before we actually enable GEM. To overcome this, we currently setup the drm_mm first and then carefully rebind them. Signed-off-by:

[Intel-gfx] [PATCH 30/55] drm/i915: Rename engine->semaphore.sync_to, engine->sempahore.signal locals

In order to be more consistent with the rest of the request construction and ring emission, use the common names for the ring and request. Rather than using signaler_req, waiter_req, and intel_ring *wait, we use plain req and ring. Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH 42/55] drm/i915: Remove obsolete i915_gem_object_flush_active()

Since we track requests, and requests are always added to the GPU fully formed, we never have to flush the incomplete request and know that the given request will eventually complete without any further action on our part. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 45/55] drm/i915: Convert intel_overlay to request tracking

intel_overlay already tracks its last flip request, along with action to take after its completion. Refactor intel_overlay to reuse the common i915_gem_active tracker. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_overlay.c | 84

[Intel-gfx] [PATCH 41/55] drm/i915: Rename request->list to link for consistency

We use "list" to denote the list and "link" to denote an element on that list. Rename request->list to match this idiom. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/i915/i915_gem.c | 10 +-

[Intel-gfx] [PATCH 40/55] drm/i915: Refactor blocking waits

Tidy up the for loops that handle waiting for read/write vs read-only access. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 158 +++- 1 file changed, 75 insertions(+), 83 deletions(-) diff --git

[Intel-gfx] [PATCH 52/55] drm/i915: Track active vma requests

Hook the vma itself into the i915_gem_request_retire() so that we can accurately track when a solitary vma is inactive (as opposed to having to wait for the entire object to be idle). This improves the interaction when using multiple contexts (with full-ppgtt) and eliminates some frequent list

[Intel-gfx] [PATCH 53/55] drm/i915: Release vma when the handle is closed

In order to prevent a leak of the vma on shared objects, we need to hook into the object_close callback to destroy the vma on the object for this file. However, if we destroyed that vma immediately we may cause unexpected application stalls as we try to unbind a busy vma - hence we defer the

[Intel-gfx] [PATCH 43/55] drm/i915: Refactor activity tracking for requests

With the introduction of requests, we amplified the number of atomic refcounted objects we use and update every execbuffer; from none to several references, and a set of references that need to be changed. We also introduced interesting side-effects in the order of retiring requests and objects.

[Intel-gfx] [PATCH 48/55] drm/i915: s/__i915_wait_request/i915_wait_request/

There is onl one wait on request function now, so drop the "expert" indication of leading __. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 18 +- drivers/gpu/drm/i915/i915_gem_request.c | 16

[Intel-gfx] [PATCH 54/55] drm/i915: Mark the context and address space as closed

When the user closes the context mark it and the dependent address space as closed. As we use an asynchronous destruct method, this has two purposes. First it allows us to flag the closed context and detect internal errors if we to create any new objects for it (as it is removed from the user's

[Intel-gfx] [PATCH 46/55] drm/i915: Move the special case wait-request handling to its one caller

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 25 - drivers/gpu/drm/i915/i915_gem_request.h | 4 drivers/gpu/drm/i915/intel_ringbuffer.c | 18 +- 3 files changed, 13 insertions(+), 34 deletions(-)

[Intel-gfx] [PATCH 49/55] drm/i915: Double check activity before relocations

If the object is active and we need to perform a relocation upon it, we need to take the slow relocation path. Before we do, double check the active requests to see if they have completed. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 16

[Intel-gfx] [PATCH 55/55] Revert "drm/i915: Clean up associated VMAs on context destruction"

This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae. The patch was only a stop-gap measure that fixed half the problem - the leak of the fbcon when restarting X. A complete solution required releasing the VMA when the object itself was closed rather than rely on file/process exit. The

[Intel-gfx] [PATCH 50/55] drm/i915: Move request list retirement to i915_gem_request.c

As the list retirement is now clean of implementation details, we can move it closer to the request management. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 44 - drivers/gpu/drm/i915/i915_gem_request.c | 35

[Intel-gfx] [PATCH 47/55] drm/i915: Disable waitboosting for a saturated engine

If the user floods the GPU with so many requests that the engine stalls waiting for free space, don't automatically promote the GPU to maximum frequencies. If the GPU really is saturated with work, it will migrate to high clocks by itself, otherwise it is merely a user flooding us with busy-work.

[Intel-gfx] [PATCH 51/55] drm/i915: i915_vma_move_to_active prep patch

This patch is broken out of the next just to remove the code motion from that patch and make it more readable. What we do here is move the i915_vma_move_to_active() to i915_gem_execbuffer.c and put the three stages (read, write, fenced) together so that future modifications to active handling are

[Intel-gfx] [PATCH 44/55] drm/i915: Track requests inside each intel_ring

By tracking each request occupying space inside an individual intel_ring, we can greatly simplify the logic of tracking available space and not worry about other timelines. (Each ring is an ordered timeline of committed requests.) Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 37/55] drm/i915: Introduce i915_gem_active for request tracking

In the next patch, request tracking is made more generic and for that we need a new expanded struct and to separate out the logic changes from the mechanical churn, we split out the structure renaming into this patch. v2: Writer's block. Add some spiel about why we track requests. v3: Now

[Intel-gfx] [PATCH 34/55] drm/i915: Count how many VMA are bound for an object

Since we may have VMA allocated for an object, but we interrupted their binding, there is a disparity between have elements on the obj->vma_list and being bound. i915_gem_obj_bound_any() does this check, but this is not rigorously observed - add an explicit count to make it easier. Signed-off-by:

[Intel-gfx] [PATCH 38/55] drm/i915: Prepare i915_gem_active for annotations

In the future, we will want to add annotations to the i915_gem_active struct. The API is thus expanded to hide direct access to the contents of i915_gem_active and mediated instead through a number of helpers. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 12/55] drm/i915: Rename intel_context[engine].ringbuf

Perform s/ringbuf/ring/ on the context struct for consistency with the ring/engine split. v2: Kill an outdated error_ringbuf label Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [PATCH 35/55] drm/i915: Be more careful when unbinding vma

When we call i915_vma_unbind(), we will wait upon outstanding rendering. This will also trigger a retirement phase, which may update the object lists. If, we extend request tracking to the VMA itself (rather than keep it at the encompassing object), then there is a potential that the obj->vma_list

[Intel-gfx] [PATCH 39/55] drm/i915: Mark up i915_gem_active for locking annotation

The future annotations will track the locking used for access to ensure that it is always sufficient. We make the preparations now to present the API ahead and to make sure that GCC can eliminate the unused parameter. Before: 6298417 3619610 696320 10614347 a1f64b vmlinux After: 6298417

[Intel-gfx] [PATCH 29/55] drm/i915: Simplify calling engine->sync_to

Since requests can no longer be generated as a side-effect of intel_ring_begin(), we know that the seqno will be unchanged during ring-emission. This predicatablity then means we do not have to check for the seqno wrapping around whilst emitting the semaphore for engine->sync_to(). Signed-off-by:

[Intel-gfx] [PATCH 36/55] drm/i915: Kill drop_pages()

The drop_pages() function is a dangerous trap in that it can release the passed in object pointer and so unless the caller is aware, it can easily trick us into using the stale object afterwards. Move it into its solitary callsite where we know it is safe. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 27/55] drm/i915: Refactor golden render state emission to unconfuse gcc

GCC was inlining the init and setup functions, but was getting itself confused into thinking that variables could be used uninitialised. If we do the inline for gcc, it is happy! As a bonus we shrink the code. v2: A couple of minor tweaks from Joonas Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 31/55] drm/i915: Amalgamate GGTT/ppGTT vma debug list walkers

As we can now have multiple VMA inside the global GTT (with partial mappings, rotations, etc), it is no longer true that there may just be a single GGTT entry and so we should walk the full vma_list to count up the actual usage. In addition to unifying the two walkers, switch from multiplying the

[Intel-gfx] [PATCH 33/55] drm/i915: Store owning file on the i915_address_space

For the global GTT (and aliasing GTT), the address space is owned by the device (it is a global resource) and so the per-file owner field is NULL. For per-process GTT (where we create an address space per context), each is owned by the opening file. We can use this ownership information to both

[Intel-gfx] [PATCH 26/55] drm/i915: Remove duplicate golden render state init from execlists

Now that we use the same vfuncs for emitting the batch buffer in both execlists and legacy, the golden render state initialisation is identical between both. v2: gcc wants so.ggtt_offset initialised (even though it is not used) Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH 25/55] drm/i915/ringbuffer: Specialise SNB+ request emission for semaphores

As gen6_emit_request() only differs from i9xx_emit_request() when semaphores are enabled, only use the specialised vfunc in that scenario. v2: Reorder semaphore init so as to keep engine->emit_request default vfunc selection compact. Signed-off-by: Chris Wilson Link:

[Intel-gfx] [PATCH 14/55] drm/i915: Rename residual ringbuf parameters

Now that we have a clear ring/engine split and a struct intel_ring, we no longer need the stopgap ringbuf names. Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-16-git-send-email-ch...@chris-wilson.co.uk Reviewed-by:

[Intel-gfx] [PATCH 28/55] drm/i915: Unify legacy/execlists submit_execbuf callbacks

Now that emitting requests is identical between legacy and execlists, we can use the same function to build up the ring for submitting to either engine. (With the exception of i915_switch_contexts(), but in time that will also be handled gracefully.) Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 22/55] drm/i915/lrc: Update function names to match request flow

With adding engine->submit_request, we now have a bunch of functions with similar names used at different stages of the execlist submission. Try a different coat of paint, to hopefully reduce confusion between the requests, intel_engine_cs and the actual execlists submision process.

[Intel-gfx] [PATCH 19/55] drm/i915: Remove intel_ring_get_tail()

Joonas doesn't like the tiny function, especially if I go around making it more complicated and using it elsewhere. To remove that temptation, remove the function! Signed-off-by: Chris Wilson Link:

[Intel-gfx] [PATCH 23/55] drm/i915: Stop passing caller's num_dwords to engine->semaphore.signal()

Rather than pass in the num_dwords that the caller wishes to use after the signal command packet, split the breadcrumb emission into two phases and have both the signal and breadcrumb individiually acquire space on the ring. This makes the interface simpler for the reader, and will simplify for

[Intel-gfx] [PATCH 16/55] drm/i915: Remove obsolete engine->gpu_caches_dirty

Space for flushing the GPU cache prior to completing the request is preallocated and so cannot fail - the GPU caches will always be flushed along with the completed request. This means we no longer have to track whether the GPU cache is dirty between batches like we had to with the

[Intel-gfx] [PATCH 17/55] drm/i915: Simplify request_alloc by returning the allocated request

If is simpler and leads to more readable code through the callstack if the allocation returns the allocated struct through the return value. The importance of this is that it no longer looks like we accidentally allocate requests as side-effect of calling certain functions. Signed-off-by: Chris

[Intel-gfx] [PATCH 15/55] drm/i915: Rename intel_pin_and_map_ring()

For more consistent oop-naming, we would use intel_ring_verb, so pick intel_ring_pin() and intel_ring_unpin(). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [PATCH 06/55] drm/i915: Use engine to refer to the user's BSD intel_engine_cs

This patch transitions the execbuf engine selection away from using the ring nomenclature - though we still refer to the user's incoming selector as their user_ring_id. Signed-off-by: Chris Wilson Link:

[Intel-gfx] [PATCH 13/55] drm/i915: Rename struct intel_ringbuffer to struct intel_ring

The state stored in this struct is not only the information about the buffer object, but the ring used to communicate with the hardware. Using buffer here is overly specific and, for me at least, conflates with the notion of buffer objects themselves. s/struct intel_ringbuffer/struct intel_ring/

[Intel-gfx] [PATCH 21/55] drm/i915: Unify request submission

Move request submission from emit_request into its own common vfunc from i915_add_request(). v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing v3: Rename a few functions to match. Signed-off-by: Chris Wilson Link:

[Intel-gfx] [PATCH 20/55] drm/i915: Convert engine->write_tail to operate on a request

If we rewrite the I915_WRITE_TAIL specialisation for the legacy ringbuffer as submitting the request onto the ringbuffer, we can unify the vfunc with both execlists and GuC in the next patch. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH 18/55] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

Both the ->dispatch_execbuffer and ->emit_bb_start callbacks do exactly the same thing, add MI_BATCHBUFFER_START to the request's ringbuffer - we need only one vfunc. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [PATCH 04/55] drm/i915: Only drop the batch-pool's object reference

The obj->batch_pool_link is only inspected when traversing the batch pool list and when on the batch pool list the object is referenced. Thus when freeing the batch pool list, we only need to unreference the object and do not have to worry about the obj->batch_pool_link. Signed-off-by: Chris

[Intel-gfx] [PATCH 10/55] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

Both perform the same actions with more or less indirection, so just unify the code. v2: Add back a few intel_engine_cs locals Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Link:

[Intel-gfx] [PATCH 08/55] drm/i915: Remove stray intel_engine_cs ring identifiers from i915_gem.c

A few places we use ring when referring to the struct intel_engine_cs. An anachronism we are pruning out. Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-9-git-send-email-ch...@chris-wilson.co.uk ---

[Intel-gfx] [PATCH 09/55] drm/i915: Update a couple of hangcheck comments to talk about engines

We still have lots of comments that refer to the old ring when we mean struct intel_engine_cs and its hardware correspondence. This patch fixes an instance inside hangcheck to talk about engines. Signed-off-by: Chris Wilson Link:

[Intel-gfx] [PATCH 07/55] drm/i915: Avoid using intel_engine_cs *ring for GPU error capture

Inside the error capture itself, we refer to not only the hardware engine, its ringbuffer but also the capture state. Finding clear names for each whilst avoiding mixing ring/intel_engine_cs is tricky. As a compromise we keep using ering for the error capture. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 05/55] drm/i915/cmdparser: Remove stray intel_engine_cs *ring

When we refer to intel_engine_cs, we want to use engine so as not to confuse ourselves about ringbuffers. v2: Rename all the functions as well, as well as a few more stray comments. v3: Split the really long error message strings Signed-off-by: Chris Wilson Link:

[Intel-gfx] [PATCH 01/55] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling()

Since intel_engine_enable_signaling() is now only called via fence_enable_sw_signaling(), we can rely on it to provide serialisation and run-once for us and so make ourselves slightly simpler. Signed-off-by: Chris Wilson Link:

[Intel-gfx] [PATCH 02/55] drm/i915: Prefer list_first_entry_or_null

list_first_entry_or_null() can generate better code than using if (!list_empty()) {ptr = list_first_entry()) ..., so put it to use. Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-3-git-send-email-ch...@chris-wilson.co.uk

[Intel-gfx] [PATCH 03/55] drm/i915: Only clear the client pointer when tearing down the file

Upon release of the file (i.e. the user calls close(fd)), we decouple all objects from the client list so that we don't chase the dangling file_priv. As we always inspect file_priv first, we only need to nullify that pointer and can safely ignore the list_head. Signed-off-by: Chris Wilson

[Intel-gfx] Fix the vma leak

Long, long ago vma were found to exist after the parent ppgtt had ceased. They still do. This series fixes the leak by introducing vma activity tracking, with this a vma for one client does not stall another client and we can track when each client's vm are idle independently. -Chris

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: avoid "may be used uninitialised" warnings

== Series Details == Series: drm/i915: avoid "may be used uninitialised" warnings URL : https://patchwork.freedesktop.org/series/10243/ State : warning == Summary == Series 10243v1 drm/i915: avoid "may be used uninitialised" warnings

Re: [Intel-gfx] [PATCH] drm/i915: avoid "may be used uninitialised" warnings

On Mon, Jul 25, 2016 at 05:29:45PM +0100, Dave Gordon wrote: > gcc is getting false positives in its detection of uninitialised values. > Specifically it thinks 'gtt_entry' can be used in a WARN_ON() macro > without previously being assigned (the assigment is inside a conditional > loop), bu

[Intel-gfx] [PATCH] drm/i915: avoid "may be used uninitialised" warnings

gcc is getting false positives in its detection of uninitialised values. Specifically it thinks 'gtt_entry' can be used in a WARN_ON() macro without previously being assigned (the assigment is inside a conditional loop), bu actually the WARN_ON() can only be reached if the assignment has also been

Re: [Intel-gfx] [PATCH v6 05/10] drm: Read DP branch device id

On Wed, Jul 06, 2016 at 02:04:49PM +0300, Mika Kahola wrote: > Read DisplayPort branch device id string. Reviewed-by: Jim Bride > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/drm_dp_helper.c | 12 >

Re: [Intel-gfx] [PATCH v6 07/10] drm: Read DP branch device SW revision

On Wed, Jul 06, 2016 at 02:04:51PM +0300, Mika Kahola wrote: > SW revision is mandatory field for DisplayPort branch > devices. This is defined in DPCD register field 0x50A. Reviewed-by: Jim Bride > > Signed-off-by: Mika Kahola > --- >

Re: [Intel-gfx] [PATCH v6 04/10] drm: Helper to read max bits per component

On Wed, Jul 06, 2016 at 02:04:48PM +0300, Mika Kahola wrote: > Helper routine to read out maximum supported bits per > component for DisplayPort legay converters. > > v2: Return early if detailed port cap info is not available. > Replace if-else ladder with switch-case (Ville) Reviewed-by:

Re: [Intel-gfx] [PATCH v6 03/10] drm: Helper to read max clock rate

On Wed, Jul 06, 2016 at 02:04:47PM +0300, Mika Kahola wrote: > Helper routine to read out maximum supported pixel rate > for DisplayPort legay VGA converter or TMDS clock rate > for other digital legacy converters. The helper returns > clock rate in kHz. > > v2: Return early if detailed port cap

Re: [Intel-gfx] [PATCH v6 02/10] drm: Drop VGA from bpc definitions

On Wed, Jul 06, 2016 at 02:04:46PM +0300, Mika Kahola wrote: > Drop "VGA" from bits per component definitions as these > are also used by other standards such as DVI, HDMI, > DP++. Reviewed-by: Jim Bride > > Signed-off-by: Mika Kahola > --- >

Re: [Intel-gfx] [PATCH v6 01/10] drm: Add missing DP downstream port types

On Wed, Jul 06, 2016 at 02:04:45PM +0300, Mika Kahola wrote: > Add missing DisplayPort downstream port types. The introduced > new port types are DP++ and Wireless. Looks good relative to the DP spec. Reviewed-by: Jim Bride > > Signed-off-by: Mika Kahola

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

On Mon, Jul 25, 2016 at 02:46:01PM +0200, Maarten Lankhorst wrote: > Op 25-07-16 om 13:51 schreef Ville Syrjälä: > > On Mon, Jul 25, 2016 at 01:32:45PM +0200, Maarten Lankhorst wrote: > >> Hey, > >> > >> Op 19-07-16 om 18:21 schreef Ville Syrjälä: > >>> On Tue, Jul 19, 2016 at 04:50:49PM +0100,

Re: [Intel-gfx] [PATCH i-g-t v2 05/15] tests/kms: Clean up more users of unassigned pipes.

How about this? tests/kms: Clean up more users of unassigned pipes. Use for_each_pipe_with_valid_output instead. This may increase test time slightly on the affected tests, because now outputs will be tested on every pipe instead of the first pipe. This will increase test coverage to all

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

Op 21-07-16 om 21:23 schreef Lyude: > From: Matt Roper > > When we write watermark values to the hardware, those values are stored > in dev_priv->wm.skl_hw. However with recent watermark changes, the > results structure we're copying from only contains valid watermark

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

Op 25-07-16 om 13:51 schreef Ville Syrjälä: > On Mon, Jul 25, 2016 at 01:32:45PM +0200, Maarten Lankhorst wrote: >> Hey, >> >> Op 19-07-16 om 18:21 schreef Ville Syrjälä: >>> On Tue, Jul 19, 2016 at 04:50:49PM +0100, Chris Wilson wrote: On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

On Mon, Jul 25, 2016 at 01:32:45PM +0200, Maarten Lankhorst wrote: > Hey, > > Op 19-07-16 om 18:21 schreef Ville Syrjälä: > > On Tue, Jul 19, 2016 at 04:50:49PM +0100, Chris Wilson wrote: > >> On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote: > >>> On Tue, Jul 19, 2016 at 05:14:23PM

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

Hey, Op 19-07-16 om 18:21 schreef Ville Syrjälä: > On Tue, Jul 19, 2016 at 04:50:49PM +0100, Chris Wilson wrote: >> On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote: >>> On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote: num_levels should be level+1, not level,

Re: [Intel-gfx] [PATCH v2] drm/i915/cmdparser: Remove stray intel_engine_cs *ring

On Mon, Jul 25, 2016 at 02:01:05PM +0300, Joonas Lahtinen wrote: > On ma, 2016-07-25 at 10:06 +0100, Chris Wilson wrote: > > When we refer to intel_engine_cs, we want to use engine so as not to > > confuse ourselves about ringbuffers. > > > > v2: Rename all the functions as well, as well as a few

Re: [Intel-gfx] [PATCH v2] drm/i915/cmdparser: Remove stray intel_engine_cs *ring

On ma, 2016-07-25 at 10:06 +0100, Chris Wilson wrote: > When we refer to intel_engine_cs, we want to use engine so as not to > confuse ourselves about ringbuffers. > > v2: Rename all the functions as well, as well as a few more stray comments. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Only drop the batch-pool's object reference

On ma, 2016-07-25 at 09:44 +0100, Chris Wilson wrote: > On Mon, Jul 25, 2016 at 11:38:07AM +0300, Joonas Lahtinen wrote: > > > > On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > > > > > > The obj->batch_pool_link is only inspected when traversing the batch > > > pool list and when on the

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?

On ma, 2016-07-25 at 07:39 +, Patchwork wrote: > == Series Details == > > Series: drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_? > URL   : https://patchwork.freedesktop.org/series/10229/ > State : failure > > == Summary == > > Series 10229v1 drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_? >

Re: [Intel-gfx] [PATCH 02/31] drm/i915: Prefer list_first_entry_or_null

On ma, 2016-07-25 at 09:03 +0100, Chris Wilson wrote: > On Mon, Jul 25, 2016 at 10:55:24AM +0300, Joonas Lahtinen wrote: > > > > On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > > > > > > list_first_entry_or_null() can generate better code than using > > > if (!list_empty()) {ptr =

Re: [Intel-gfx] [PATCH 28/31] drm/i915: Refactor golden render state emission to unconfuse gcc

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > + so.obj = i915_gem_object_create(>i915->drm, 4096); > + if (IS_ERR(so.obj)) > + return PTR_ERR(so.obj); I remember earlier discussion about having GPU_PAGE_SIZE, did that ever go anywhere? Nor related to this patch

Re: [Intel-gfx] [PATCH 26/31] drm/i915/ringbuffer: Specialise SNB+ request emission for semaphores

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > As gen6_emit_request() only differs from i9xx_emit_request() when > semaphores are enabled, only use the specialised vfunc in that scenario. > > v2: Reorder semaphore init so as to keep engine->emit_request default > vfunc selection compact.

Re: [Intel-gfx] [PATCH 24/31] drm/i915: Stop passing caller's num_dwords to engine->semaphore.signal()

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > Rather than pass in the num_dwords that the caller wishes to use after > the signal command packet, split the breadcrumb emission into two phases > and have both the signal and breadcrumb individiually acquire space on > the ring. This makes

Re: [Intel-gfx] [PATCH 23/31] drm/i915/lrc: Update function names to match request flow

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > With adding engine->submit_request, we now have a bunch of functions > with similar names used at different stages of the execlist submission. > Try a different coat of paint, to hopefully reduce confusion between the > requests,

Re: [Intel-gfx] [PATCH 22/31] drm/i915: Unify request submission

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > Move request submission from emit_request into its own common vfunc > from i915_add_request(). > > v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing > v3: Rename a few functions to match. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 20/31] drm/i915: Remove intel_ring_get_tail()

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > Joonas doesn't like the tiny function, especially if I go around making > it more complicated and using it elsewhere. To remove that temptation, > remove the function! > Reviewed-by: Joonas Lahtinen >

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [01/31] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling() (rev2)

== Series Details == Series: series starting with [01/31] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling() (rev2) URL : https://patchwork.freedesktop.org/series/10230/ State : success == Summary == Series 10230v2 Series without cover letter

Re: [Intel-gfx] [PATCH 17/31] drm/i915: Remove obsolete engine->gpu_caches_dirty

On Mon, Jul 25, 2016 at 12:14:44PM +0300, Joonas Lahtinen wrote: > On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > > Space for flushing the GPU cache prior to completing the request is > > preallocated and so cannot fail. > > Patch title and commit message have some disconnect. Could you

Re: [Intel-gfx] [PATCH 18/31] drm/i915: Simplify request_alloc by returning the allocated request

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > If is simpler and leads to more readable code through the callstack if > the allocation returns the allocated struct through the return value. > > The importance of this is that it no longer looks like we accidentally > allocate requests as

Re: [Intel-gfx] [PATCH 17/31] drm/i915: Remove obsolete engine->gpu_caches_dirty

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > Space for flushing the GPU cache prior to completing the request is > preallocated and so cannot fail. Patch title and commit message have some disconnect. Could you explain in a bit more detail what made gpu_caches_dirty obsolete? Also,

Re: [Intel-gfx] [PATCH 12/31] drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs

On Mon, Jul 25, 2016 at 11:49:45AM +0300, Joonas Lahtinen wrote: > On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > > Having ringbuf->ring point to an engine is confusing, so rename it once > > again to ring->engine. > > > > Signed-off-by: Chris Wilson > > I

[Intel-gfx] [PATCH v2] drm/i915/cmdparser: Remove stray intel_engine_cs *ring

When we refer to intel_engine_cs, we want to use engine so as not to confuse ourselves about ringbuffers. v2: Rename all the functions as well, as well as a few more stray comments. Signed-off-by: Chris Wilson Link:

Re: [Intel-gfx] [PATCH 15/31] drm/i915: Rename residual ringbuf parameters

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > Now that we have a clear ring/engine split and a struct intel_ring, we > no longer need the stopgap ringbuf names. +1 vote for squashing related renames, should be make picking them later easier, unless there is huge pieces of code in

Re: [Intel-gfx] [PATCH 12/31] drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > Having ringbuf->ring point to an engine is confusing, so rename it once > again to ring->engine. > > Signed-off-by: Chris Wilson I still do not see a connection between commit message and content, so you could

Re: [Intel-gfx] [PATCH 08/31] drm/i915: Remove stray intel_engine_cs ring identifiers from i915_gem.c

On Mon, Jul 25, 2016 at 11:45:42AM +0300, Joonas Lahtinen wrote: > On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > > A few places we use ring when referring to the struct intel_engine_cs. An > > anachronism we are pruning out. > > > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 09/31] drm/i915: Update a couple of hangcheck comments to talk about engines

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > We still have lots of comments that refer to the old ring when we mean > struct intel_engine_cs and its hardware correspondence. This patch fixes > an instance inside hangcheck to talk about engines. > These could be squashed down a bit

Re: [Intel-gfx] [PATCH 08/31] drm/i915: Remove stray intel_engine_cs ring identifiers from i915_gem.c

On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > A few places we use ring when referring to the struct intel_engine_cs. An > anachronism we are pruning out. > > Signed-off-by: Chris Wilson > --- >  drivers/gpu/drm/i915/i915_gem.c | 24 >  

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Only drop the batch-pool's object reference

On Mon, Jul 25, 2016 at 11:38:07AM +0300, Joonas Lahtinen wrote: > On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > > The obj->batch_pool_link is only inspected when traversing the batch > > pool list and when on the batch pool list the object is referenced. Thus > > when freeing the batch

  1   2   >