Re: [Intel-gfx] [PATCH] drm/i915: Keep ring-active_list and ring-requests_list consistent
On Thu, Mar 19, 2015 at 06:37:28PM +0100, Daniel Vetter wrote: On Wed, Mar 18, 2015 at 06:19:22PM +, Chris Wilson wrote: WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140() WARN_ON(!list_empty(vm-active_list)) How does this come about - we call gpu_idle before this seems to blow up, so all requests should be completed? Honestly, I couldn't figure it out either. I had an epiphany when I saw that we could now have an empty request list but non-empty active list added a test to detect when that happens and shouted eureka when the WARN fired. I could trigger the WARN in evict_vm pretty reliably, but not since this patch. It could just be masking another bug. And I don't think we can blame this on racy seqno signalling, since gpu_idle does all the waiting already ... Identified by updating WATCH_LISTS: [drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230() WARN_ON(i915_verify_lists(ring-dev)) Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: John Harrison john.c.harri...@intel.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Since we've just discussed this on irc: Doesn't this now enshrine that every bo needs to hold a full request? I'm not following. The bo hold a reference to requests, so we know we can iterate the ring-request_list and the ring-active_list independently. There is a challenge in doing the execbuf with as few kref as possible, but there is also the question of whether this particular function should go back to the previous behaviour of batching the completion evaluation for all requests such that they are evaluated consistently. One way without killing the abstraction entirely would be to evaluate the i915_request_complete() only for the request_list and then use the cached completion value for the active_list. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc is being disabled
-Original Message-
From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
Sent: Thursday, March 19, 2015 12:52 AM
To: Konduru, Chandra
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc
is
being disabled
On Thu, 2015-03-19 at 00:12 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 04/19] drm/i915: Allocate a crtc_state also when the
crtc is being disabled
For consistency, allocate a new crtc_state for a crtc that is being
disabled.
Previously only the enabled value of the current state would change.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 36
+
---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b61e3f6..62b9021 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11188,14 +11188,21 @@ intel_modeset_compute_config(struct
drm_crtc *crtc,
unsigned *prepare_pipes,
unsigned *disable_pipes)
{
+ struct drm_device *dev = crtc-dev;
struct intel_crtc_state *pipe_config = NULL;
+ struct intel_crtc *intel_crtc;
int ret = 0;
intel_modeset_affected_pipes(crtc, modeset_pipes,
prepare_pipes, disable_pipes);
- if ((*modeset_pipes) == 0)
- return NULL;
+ for_each_intel_crtc_masked(dev, *disable_pipes, intel_crtc) {
+ pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
+ if (IS_ERR(pipe_config))
+ return pipe_config;
+
+ pipe_config-base.enable = false;
+ }
/*
* Note this needs changes when we start tracking multiple modes
@@ -
11203,18 +11210,25 @@ intel_modeset_compute_config(struct drm_crtc
*crtc,
* (i.e. one pipe_config for each crtc) rather than just the one
* for this crtc.
*/
- ret = intel_modeset_pipe_config(crtc, fb, mode, state);
- if (ret)
- return ERR_PTR(ret);
+ for_each_intel_crtc_masked(dev, *modeset_pipes, intel_crtc) {
+ /* FIXME: For now we still expect modeset_pipes has at most
+ * one bit set. */
+ if (WARN_ON(intel_crtc-base != crtc))
+ continue;
- pipe_config = intel_atomic_get_crtc_state(state, to_intel_crtc(crtc));
- if (IS_ERR(pipe_config))
- return pipe_config;
+ ret = intel_modeset_pipe_config(crtc, fb, mode, state);
+ if (ret)
+ return ERR_PTR(ret);
+
+ pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
+ if (IS_ERR(pipe_config))
+ return pipe_config;
- intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,
-[modeset]);
+ intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,
+[modeset]);
+ }
- return pipe_config;
+ return intel_atomic_get_crtc_state(state, to_intel_crtc(crtc));
}
Instead of calling 3 separate intel_atomic_get_crtc_state() Can you
have something like:
intel_modeset_compute_config()
{
pipe_config = intel_atomic_get_crtc_state(state, crtc);
for each disabled pipe {
use pipe_config;
}
for each mode_set pipe {
use pipe_config;
}
return pipe_config;
}
Or the way currently done is to cover where disable_pipes != modeset_pipes?
By the way, when can it happen?
Yep, disable_pipes can be different than modeset_pipes if we the mode set
steals a connector. For instance, we could have pipe A driving
HDMI-1 and then mode set to pipe B to drive HDMI-1. Pipe B will steal the
encoder from pipe A, and cause it to be disable. In that case disable_pipes
will
have the bit for pipe A set, while modeset_pipes will have the bit for pipe B
set.
1)
Consider two simple scenarios:
Case1: User code moving HDMI from A to B:
drmModeSetCrtc(crtcA, HDMI);
drmModeSetCrtc(crtcB, HDMI); /* moving HDMI to pipe B */
Case2: User code turning off HDMI:
drmModeSetCrtc(crtcA, HDMI);
drmModeSetCrtc(crtcA, disable);
In both cases, driver will be disabling crtc for pipe A.
In case 1, there is no associated crtc_state or compute commit but
directly triggering crtc_disable(crtcA).
In case 2, there is associated crtc_state and associated compute and setmode
calls crtc_disable(crtcA);
Won't this cause trouble for low level functions (disable clocks, connectors,
encoders, planes etc. etc...)
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Split the batch pool by engine
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote: Oh right, I got it, but not sure I like it that much. I don't think batch pool implementation is well enough decoupled from the users. batch pool Splitting it this way actually improves decoupling. Well in a way at least where when we talk about LRU ordering, it depends on retiring working properly and that is not obvious from code layout and module separation. I've lost you. The list is in LRU submission order. With this split, the list is both in LRU submission and LRU retirememnt order. That the two are not the same originally is not a fault of retiring not working properly, but that the hardware is split into different units and timelines. And then with this me move traversal inefficiency to possible more resource use. Would it be better to fix the cause rather than symptoms? Is it feasible? What would be the downside of retiring all rings before submission? Not really. Inefficient userspace is inefficient. All we want to be sure is that one abusive client doesn't cause a DoS on another, whilst making sure that good clients are not penalized. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Implement inter-engine read-read optimisations
Currently, we only track the last request globally across all engines.
This prevents us from issuing concurrent read requests on e.g. the RCS
and BCS engines (or more likely the render and media engines). Without
semaphores, we incur costly stalls as we synchronise between rings -
greatly impacting the current performance of Broadwell versus Haswell in
certain workloads (like video decode). With the introduction of
reference counted requests, it is much easier to track the last request
per ring, as well as the last global write request so that we can
optimise inter-engine read read requests (as well as better optimise
certain CPU waits).
v2: Fix inverted readonly condition for nonblocking waits.
v3: Handle non-continguous engine array after waits
v4: Rebase, tidy, rewrite ring list debugging
Benchmark: igt/gem_read_read_speed
hsw:gt3e (with semaphores):
Before: Time to read-read 1024k:275.794µs
After: Time to read-read 1024k:123.260µs
hsw:gt3e (w/o semaphores):
Before: Time to read-read 1024k:230.433µs
After: Time to read-read 1024k:124.593µs
bdw-u (w/o semaphores): Before After
Time to read-read 1x1:26.274µs 10.350µs
Time to read-read 128x128:40.097µs 21.366µs
Time to read-read 256x256:77.087µs 42.608µs
Time to read-read 512x512: 281.999µs 181.155µs
Time to read-read 1024x1024:1196.141µs 1118.223µs
Time to read-read 2048x2048:5639.072µs 5225.837µs
Time to read-read 4096x4096: 22401.662µs21137.067µs
Time to read-read 8192x8192: 89617.735µs85637.681µs
Testcase: igt/gem_concurrent_blit (read-read and friends)
Cc: Lionel Landwerlin lionel.g.landwer...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +-
drivers/gpu/drm/i915/i915_drv.h | 11 +-
drivers/gpu/drm/i915/i915_gem.c | 427 +++-
drivers/gpu/drm/i915/i915_gem_context.c | 2 -
drivers/gpu/drm/i915/i915_gem_debug.c | 100 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +-
drivers/gpu/drm/i915/intel_display.c| 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
8 files changed, 321 insertions(+), 259 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7ef6295438e9..5cea9a9c1cb9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -120,10 +120,13 @@ static inline const char *get_global_flag(struct
drm_i915_gem_object *obj)
static void
describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *dev_priv = to_i915(obj-base.dev);
+ struct intel_engine_cs *ring;
struct i915_vma *vma;
int pin_count = 0;
+ int i;
- seq_printf(m, %pK: %s%s%s%s %8zdKiB %02x %02x %x %x %x%s%s%s,
+ seq_printf(m, %pK: %s%s%s%s %8zdKiB %02x %02x [ ,
obj-base,
obj-active ? * : ,
get_pin_flag(obj),
@@ -131,8 +134,11 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
get_global_flag(obj),
obj-base.size / 1024,
obj-base.read_domains,
- obj-base.write_domain,
- i915_gem_request_get_seqno(obj-last_read_req),
+ obj-base.write_domain);
+ for_each_ring(ring, dev_priv, i)
+ seq_printf(m, %x ,
+
i915_gem_request_get_seqno(obj-last_read_req[i]));
+ seq_printf(m, ] %x %x%s%s%s,
i915_gem_request_get_seqno(obj-last_write_req),
i915_gem_request_get_seqno(obj-last_fenced_req),
i915_cache_level_str(to_i915(obj-base.dev),
obj-cache_level),
@@ -169,9 +175,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
*t = '\0';
seq_printf(m, (%s mappable), s);
}
- if (obj-last_read_req != NULL)
+ if (obj-last_write_req != NULL)
seq_printf(m, (%s),
- i915_gem_request_get_ring(obj-last_read_req)-name);
+
i915_gem_request_get_ring(obj-last_write_req)-name);
if (obj-frontbuffer_bits)
seq_printf(m, (frontbuffer: 0x%03x), obj-frontbuffer_bits);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 819503e6c3d4..4436c1ca247d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -498,7 +498,7 @@ struct drm_i915_error_state {
struct drm_i915_error_buffer {
u32 size;
u32 name;
- u32 rseqno, wseqno;
+ u32 rseqno[I915_NUM_RINGS], wseqno;
u32 gtt_offset;
u32 read_domains;
u32 write_domain;
@@ -1903,7
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Track page table reload need
Michel Thierry michel.thie...@intel.com writes:
From: Ben Widawsky benjamin.widaw...@intel.com
This patch was formerly known as, Force pd restore when PDEs change,
gen6-7. I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object is mapped
into the current address space. The GPU does not snoop the new mapping
so we must do the gen specific action to reload the page tables.
GEN8 and GEN7 do differ in the way they load page tables for the RCS.
GEN8 does so with the context restore, while GEN7 requires the proper
load commands in the command streamer. Non-render is similar for both.
Caveat for GEN7
The docs say you cannot change the PDEs of a currently running context.
We never map new PDEs of a running context, and expect them to be
present - so I think this is okay. (We can unmap, but this should also
be okay since we only unmap unreferenced objects that the GPU shouldn't
be tryingto va-pa xlate.) The MI_SET_CONTEXT command does have a flag
to signal that even if the context is the same, force a reload. It's
unclear exactly what this does, but I have a hunch it's the right thing
to do.
The logic assumes that we always emit a context switch after mapping new
PDEs, and before we submit a batch. This is the case today, and has been
the case since the inception of hardware contexts. A note in the comment
let's the user know.
It's not just for gen8. If the current context has mappings change, we
need a context reload to switch
v2: Rebased after ppgtt clean up patches. Split the warning for aliasing
and true ppgtt options. And do not break aliasing ppgtt, where to-ppgtt
is always null.
v3: Invalidate PPGTT TLBs inside alloc_va_range.
v4: Rename ppgtt_invalidate_tlbs to mark_tlbs_dirty and move
pd_dirty_rings from i915_address_space to i915_hw_ppgtt. Fixes when
neither ctx-ppgtt and aliasing_ppgtt exist.
v5: Removed references to teardown_va_range.
v6: Updated needs_pd_load_pre/post.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+)
---
drivers/gpu/drm/i915/i915_gem_context.c| 26 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++
drivers/gpu/drm/i915/i915_gem_gtt.c| 11 +++
drivers/gpu/drm/i915/i915_gem_gtt.h| 1 +
4 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b6ea85d..9197ff4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -573,8 +573,20 @@ static inline bool should_skip_switch(struct
intel_engine_cs *ring,
struct intel_context *from,
struct intel_context *to)
{
- if (from == to !to-remap_slice)
- return true;
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
+
+ if (to-remap_slice)
+ return false;
+
+ if (to-ppgtt) {
+ if (from == to !test_bit(ring-id,
+ to-ppgtt-pd_dirty_rings))
+ return true;
+ } else if (dev_priv-mm.aliasing_ppgtt) {
+ if (from == to !test_bit(ring-id,
+ dev_priv-mm.aliasing_ppgtt-pd_dirty_rings))
+ return true;
+ }
return false;
}
@@ -610,10 +622,7 @@ needs_pd_load_post(struct intel_engine_cs *ring, struct
intel_context *to)
if (ring != dev_priv-ring[RCS])
return false;
- if (!to-legacy_hw_ctx.initialized)
- return true;
-
- if (i915_gem_context_is_default(to))
+ if (to-ppgtt-pd_dirty_rings)
if (to-ppgtt-pd_dirty_rings) ?
return true;
return false;
@@ -664,6 +673,9 @@ static int do_switch(struct intel_engine_cs *ring,
ret = to-ppgtt-switch_mm(to-ppgtt, ring);
if (ret)
goto unpin_out;
+
+ /* Doing a PD load always reloads the page dirs */
+ clear_bit(ring-id, to-ppgtt-pd_dirty_rings);
}
if (ring != dev_priv-ring[RCS]) {
@@ -696,6 +708,8 @@ static int do_switch(struct intel_engine_cs *ring,
if (!to-legacy_hw_ctx.initialized || i915_gem_context_is_default(to))
hw_flags |= MI_RESTORE_INHIBIT;
+ else if (to-ppgtt test_and_clear_bit(ring-id,
to-ppgtt-pd_dirty_rings))
+ hw_flags |= MI_FORCE_RESTORE;
ret = mi_set_context(ring, to, hw_flags);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index dc10bc4..fd0241a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1187,6 +1187,13 @@ i915_gem_ringbuffer_submission(struct drm_device *dev,
struct drm_file
[Intel-gfx] [PATCH 2/3] drm/i915: Send out the full AUX address
From: Ville Syrjälä ville.syrj...@linux.intel.com AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 3967af1..637dd53 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -942,8 +942,9 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) size_t txsize, rxsize; int ret; - txbuf[0] = msg-request 4; - txbuf[1] = msg-address 8; + txbuf[0] = (msg-request 4) | + ((msg-address 16) 0xf); + txbuf[1] = (msg-address 8) 0xff; txbuf[2] = msg-address 0xff; txbuf[3] = msg-size - 1; -- 2.0.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/radeon: Send out the full AUX address
From: Ville Syrjälä ville.syrj...@linux.intel.com
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/radeon/atombios_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8d74de8..7a59a41 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -171,8 +171,9 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
tx_buf[0] = msg-address 0xff;
- tx_buf[1] = msg-address 8;
- tx_buf[2] = msg-request 4;
+ tx_buf[1] = (msg-address 8) 0xff;
+ tx_buf[2] = (msg-request 4) |
+ ((msg-address 16) 0xf);
tx_buf[3] = msg-size ? (msg-size - 1) : 0;
switch (msg-request ~DP_AUX_I2C_MOT) {
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/dp: Print the number of bytes processed for aux nacks
From: Ville Syrjälä ville.syrj...@linux.intel.com When doing a native or i2c aux write the sink will indicate the number of bytes written even if it the nacks the transfer. When we receive a nack we just return an error upwards, but it might still be interesting to see how many bytes made it before the nack. So include that information in the debug messages. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_dp_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index d5368ea..d7c73bd 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -462,7 +462,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) break; case DP_AUX_NATIVE_REPLY_NACK: - DRM_DEBUG_KMS(native nack\n); + DRM_DEBUG_KMS(native nack (%d)\n, ret); return -EREMOTEIO; case DP_AUX_NATIVE_REPLY_DEFER: @@ -493,7 +493,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) return ret; case DP_AUX_I2C_REPLY_NACK: - DRM_DEBUG_KMS(I2C nack\n); + DRM_DEBUG_KMS(I2C nack (%d)\n, ret); aux-i2c_nack_count++; return -EREMOTEIO; -- 2.0.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv
From: Deepak S deepa...@linux.intel.com Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some of the baytrail systems :(. Switching back to legacy mode rps. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012 Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_irq.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 6d8340d..7bbdede 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) INIT_WORK(dev_priv-l3_parity.error_work, ivybridge_parity_work); /* Let's track the enabled rps events */ - if (IS_VALLEYVIEW(dev_priv) !IS_CHERRYVIEW(dev_priv)) - /* WaGsvRC0ResidencyMethod:vlv */ - dev_priv-pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; - else - dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; + dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; INIT_DELAYED_WORK(dev_priv-gpu_error.hangcheck_work, i915_hangcheck_elapsed); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave - Backporting a couple of plane related fixes from drm-next to v4.0. BR, Jani. The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda: Linux 4.0-rc4 (2015-03-15 17:38:20 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-03-19 for you to fetch changes up to 7f0801e566cc78315e5dc383bf3c3b5b5b436048: drm/i915: Make sure the primary plane is enabled before reading out the fb state (2015-03-18 10:09:05 +0200) Damien Lespiau (1): drm/i915: Make sure the primary plane is enabled before reading out the fb state Xi Ruoyao (1): drm/i915: Ensure plane-state-fb stays in sync with plane-fb drivers/gpu/drm/i915/intel_display.c | 32 1 file changed, 28 insertions(+), 4 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kerneldoc for i915_gem_shrinker.c
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5995 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 272/272 271/272 ILK 301/301 301/301 SNB 303/303 303/303 IVB 342/342 342/342 BYT 287/287 287/287 HSW 362/362 362/362 BDW 308/308 308/308 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gem_userptr_blits_coherency-unsync PASS(1) CRASH(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/19] drm/i915: Copy the staged connector config to the legacy atomic state
On Thu, 2015-03-19 at 00:38 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 07/19] drm/i915: Copy the staged connector config to the
legacy atomic state
With this in place, we can start converting pieces of the modeset code to
look at
the connector atomic state instead of the staged config.
v2: Handle the load detect staged config changes too. (Ander)
Remove unnecessary blank line. (Daniel)
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 52
+++-
1 file changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index abdbd0c..6465f6d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8805,6 +8805,7 @@ bool intel_get_load_detect_pipe(struct
drm_connector *connector,
struct drm_framebuffer *fb;
struct drm_mode_config *config = dev-mode_config;
struct drm_atomic_state *state = NULL;
+ struct drm_connector_state *connector_state;
int ret, i = -1;
DRM_DEBUG_KMS([CONNECTOR:%d:%s], [ENCODER:%d:%s]\n, @@
-8892,6 +8893,15 @@ retry:
state-acquire_ctx = ctx;
+ connector_state = drm_atomic_get_connector_state(state, connector);
+ if (IS_ERR(connector_state)) {
+ ret = PTR_ERR(connector_state);
+ goto fail;
+ }
+
+ connector_state-crtc = crtc;
+ connector_state-best_encoder = intel_encoder-base;
+
if (!mode)
mode = load_detect_mode;
@@ -8957,6 +8967,7 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
struct drm_crtc *crtc = encoder-crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_atomic_state *state;
+ struct drm_connector_state *connector_state;
DRM_DEBUG_KMS([CONNECTOR:%d:%s], [ENCODER:%d:%s]\n,
connector-base.id, connector-name, @@ -8964,17
+8975,23 @@ void intel_release_load_detect_pipe(struct drm_connector
*connector,
if (old-load_detect_temp) {
state = drm_atomic_state_alloc(dev);
- if (!state) {
- DRM_DEBUG_KMS(can't release load detect pipe\n);
- return;
- }
+ if (!state)
+ goto fail;
Is the above deletion of lines from code added by another patch in this
series or
from a different series? May be you can squash them into one.
That was added in patch 3, the one that adds the drm_atomic_state
parameter to intel_set_mode(). I chose to do it that way in order to not
complicate that patch unnecessarily. It wasn't possible to convert each
different call to intel_set_mode() separately, since that would create a
state of breakage that prevents bisecting.
So the approach I found most reasonable was to just add the state
parameter in patch number 3, and leave the proper population of the
atomic state to a separate patch. The main idea was to simplify the
review process.
state-acquire_ctx = ctx;
+ connector_state = drm_atomic_get_connector_state(state,
connector);
+ if (IS_ERR(connector_state))
+ goto fail;
+
to_intel_connector(connector)-new_encoder = NULL;
intel_encoder-new_crtc = NULL;
intel_crtc-new_enabled = false;
intel_crtc-new_config = NULL;
+
+ connector_state-best_encoder = NULL;
+ connector_state-crtc = NULL;
+
intel_set_mode(crtc, NULL, 0, 0, NULL, state);
drm_atomic_state_free(state);
@@ -8990,6 +9007,11 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
/* Switch crtc and encoder back off if necessary */
if (old-dpms_mode != DRM_MODE_DPMS_ON)
connector-funcs-dpms(connector, old-dpms_mode);
+
+ return;
+fail:
+ DRM_DEBUG_KMS(Couldn't release load detect pipe.\n);
+ drm_atomic_state_free(state);
}
Learning while reviewing connector/encoder side of handling.
But I think someone also should look at the encoder/connector side or
atomic handling.
I think Daniel already did a high level review of this. Perhaps he could
do it again for v2 of this patch.
Ander
static int i9xx_pll_refclk(struct drm_device *dev, @@ -11646,9 +11668,11 @@
intel_set_config_compute_mode_changes(struct drm_mode_set *set, static int
intel_modeset_stage_output_state(struct drm_device *dev,
struct drm_mode_set *set,
-struct intel_set_config *config)
+struct
Re: [Intel-gfx] [PATCH 08/19] drm/i915: Don't use encoder-new_crtc in intel_modeset_pipe_config()
On Thu, 2015-03-19 at 00:44 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 08/19] drm/i915: Don't use encoder-new_crtc in
intel_modeset_pipe_config()
Move towards atomic by using the legacy modeset's drm_atomic_state instead.
v2: Move call to drm_atomic_add_affected_connectors() to
intel_modeset_compute_config(). (Daniel)
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6465f6d..1609628 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10435,8 +10435,11 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc-dev;
struct intel_encoder *encoder;
+ struct intel_connector *connector;
+ struct drm_connector_state *connector_state;
struct intel_crtc_state *pipe_config;
int plane_bpp, ret = -EINVAL;
+ int i;
bool retry = true;
if (!check_encoder_cloning(to_intel_crtc(crtc))) { @@ -10510,11
+10513,17 @@ encoder_retry:
* adjust it according to limitations or connector properties, and also
* a chance to reject the mode entirely.
*/
- for_each_intel_encoder(dev, encoder) {
+ for (i = 0; i state-num_connector; i++) {
+ connector = to_intel_connector(state-connectors[i]);
+ if (!connector)
+ continue;
- if (encoder-new_crtc-base != crtc)
+ connector_state = state-connector_states[i];
+ if (connector_state-crtc != crtc)
continue;
+ encoder = to_intel_encoder(connector_state-best_encoder);
+
if (!(encoder-compute_config(encoder, pipe_config))) {
DRM_DEBUG_KMS(Encoder config failure\n);
goto fail;
@@ -11238,6 +11247,10 @@ intel_modeset_compute_config(struct drm_crtc
*crtc,
struct intel_crtc *intel_crtc;
int ret = 0;
+ ret = drm_atomic_add_affected_connectors(state, crtc);
If the current transaction is started by DRM core, above operation
will be added by core, right?
And when we move to full atomic_modeset, then above needs
to be deleted?
That call is done in drm_atomic_helper_check_modeset(), so after the
conversion, we won't need this call there. But calling it twice doesn't
have any ill-effects, so we can leave it there until this is all sorted
out.
Ander
+ if (ret)
+ return ERR_PTR(ret);
+
intel_modeset_affected_pipes(crtc, modeset_pipes,
prepare_pipes, disable_pipes);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc is being disabled
On Thu, 2015-03-19 at 00:12 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc is
being disabled
For consistency, allocate a new crtc_state for a crtc that is being
disabled.
Previously only the enabled value of the current state would change.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 36 +
---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b61e3f6..62b9021 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11188,14 +11188,21 @@ intel_modeset_compute_config(struct drm_crtc
*crtc,
unsigned *prepare_pipes,
unsigned *disable_pipes)
{
+ struct drm_device *dev = crtc-dev;
struct intel_crtc_state *pipe_config = NULL;
+ struct intel_crtc *intel_crtc;
int ret = 0;
intel_modeset_affected_pipes(crtc, modeset_pipes,
prepare_pipes, disable_pipes);
- if ((*modeset_pipes) == 0)
- return NULL;
+ for_each_intel_crtc_masked(dev, *disable_pipes, intel_crtc) {
+ pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
+ if (IS_ERR(pipe_config))
+ return pipe_config;
+
+ pipe_config-base.enable = false;
+ }
/*
* Note this needs changes when we start tracking multiple modes @@ -
11203,18 +11210,25 @@ intel_modeset_compute_config(struct drm_crtc *crtc,
* (i.e. one pipe_config for each crtc) rather than just the one
* for this crtc.
*/
- ret = intel_modeset_pipe_config(crtc, fb, mode, state);
- if (ret)
- return ERR_PTR(ret);
+ for_each_intel_crtc_masked(dev, *modeset_pipes, intel_crtc) {
+ /* FIXME: For now we still expect modeset_pipes has at most
+* one bit set. */
+ if (WARN_ON(intel_crtc-base != crtc))
+ continue;
- pipe_config = intel_atomic_get_crtc_state(state, to_intel_crtc(crtc));
- if (IS_ERR(pipe_config))
- return pipe_config;
+ ret = intel_modeset_pipe_config(crtc, fb, mode, state);
+ if (ret)
+ return ERR_PTR(ret);
+
+ pipe_config = intel_atomic_get_crtc_state(state, intel_crtc);
+ if (IS_ERR(pipe_config))
+ return pipe_config;
- intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,
- [modeset]);
+ intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,
+ [modeset]);
+ }
- return pipe_config;
+ return intel_atomic_get_crtc_state(state, to_intel_crtc(crtc));
}
Instead of calling 3 separate intel_atomic_get_crtc_state()
Can you have something like:
intel_modeset_compute_config()
{
pipe_config = intel_atomic_get_crtc_state(state, crtc);
for each disabled pipe {
use pipe_config;
}
for each mode_set pipe {
use pipe_config;
}
return pipe_config;
}
Or the way currently done is to cover where disable_pipes != modeset_pipes?
By the way, when can it happen?
Yep, disable_pipes can be different than modeset_pipes if we the mode
set steals a connector. For instance, we could have pipe A driving
HDMI-1 and then mode set to pipe B to drive HDMI-1. Pipe B will steal
the encoder from pipe A, and cause it to be disable. In that case
disable_pipes will have the bit for pipe A set, while modeset_pipes will
have the bit for pipe B set.
Ander
static int __intel_set_mode_setup_plls(struct drm_device *dev,
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Send out the full AUX address
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/i915/intel_dp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 3967af1..637dd53 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -942,8 +942,9 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) size_t txsize, rxsize; int ret; - txbuf[0] = msg-request 4; - txbuf[1] = msg-address 8; + txbuf[0] = (msg-request 4) | + ((msg-address 16) 0xf); + txbuf[1] = (msg-address 8) 0xff; txbuf[2] = msg-address 0xff; txbuf[3] = msg-size - 1; -- 2.0.5 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Allocate a drm_atomic_state for the legacy modeset code
On Wed, 2015-03-18 at 23:57 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Wednesday, March 18, 2015 12:57 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH v4] drm/i915: Allocate a drm_atomic_state for the legacy
modeset code
For the atomic conversion, the mode set paths need to be changed to rely on
an
atomic state instead of using the staged config. By using an atomic state
for the
legacy code, we will be able to convert the code base in small chunks.
v2: Squash patch that adds stat argument to intel_set_mode(). (Ander)
Make every caller of intel_set_mode() allocate state. (Daniel)
Call drm_atomic_state_clear() in set config's error path. (Daniel)
v3: Copy staged config to atomic state in force restore path. (Ander)
v4: Don't update -new_config for disabled pipes in __intel_set_mode(),
since it is expected to be NULL in that case. (Ander)
Can you clarify why it is expected to be NULL?
This is part of the sanity checking implemented when the
intel_crtc-new_config pointer was introduced. If I understand
correctly, the idea was to reduce the usage of that pointer to only the
brief moment when it pointed at something different than the current
config. That way, if some piece of code relied on that pointer outside
of modeset, it would be easier to catch that bug.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 200 +-
-
1 file changed, 165 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8458bf5..ce35647 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -83,7 +83,8 @@ static void ironlake_pch_clock_get(struct intel_crtc
*crtc,
struct intel_crtc_state *pipe_config);
static int intel_set_mode(struct drm_crtc *crtc, struct drm_display_mode
*mode,
- int x, int y, struct drm_framebuffer *old_fb);
+ int x, int y, struct drm_framebuffer *old_fb,
+ struct drm_atomic_state *state);
static int intel_framebuffer_init(struct drm_device *dev,
struct intel_framebuffer *ifb,
struct drm_mode_fb_cmd2 *mode_cmd, @@
-8802,6 +8803,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
struct drm_device *dev = encoder-dev;
struct drm_framebuffer *fb;
struct drm_mode_config *config = dev-mode_config;
+ struct drm_atomic_state *state = NULL;
int ret, i = -1;
DRM_DEBUG_KMS([CONNECTOR:%d:%s], [ENCODER:%d:%s]\n, @@
-8883,6 +8885,12 @@ retry:
old-load_detect_temp = true;
old-release_fb = NULL;
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return false;
+
+ state-acquire_ctx = ctx;
+
if (!mode)
mode = load_detect_mode;
@@ -8905,7 +8913,7 @@ retry:
goto fail;
}
- if (intel_set_mode(crtc, mode, 0, 0, fb)) {
+ if (intel_set_mode(crtc, mode, 0, 0, fb, state)) {
DRM_DEBUG_KMS(failed to set mode on load-detect pipe\n);
if (old-release_fb)
old-release_fb-funcs-destroy(old-release_fb);
@@ -8924,6 +8932,11 @@ retry:
else
intel_crtc-new_config = NULL;
fail_unlock:
+ if (state) {
+ drm_atomic_state_free(state);
+ state = NULL;
+ }
+
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
goto retry;
@@ -8936,22 +8949,34 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
struct intel_load_detect_pipe *old,
struct drm_modeset_acquire_ctx *ctx) {
+ struct drm_device *dev = connector-dev;
struct intel_encoder *intel_encoder =
intel_attached_encoder(connector);
struct drm_encoder *encoder = intel_encoder-base;
struct drm_crtc *crtc = encoder-crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_atomic_state *state;
DRM_DEBUG_KMS([CONNECTOR:%d:%s], [ENCODER:%d:%s]\n,
connector-base.id, connector-name,
encoder-base.id, encoder-name);
if (old-load_detect_temp) {
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ DRM_DEBUG_KMS(can't release load detect pipe\n);
+ return;
+ }
+
+ state-acquire_ctx = ctx;
+
to_intel_connector(connector)-new_encoder = NULL;
intel_encoder-new_crtc = NULL;
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Stop rings before cleaning up on reset
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5989 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 268/268 268/268 ILK 303/303 303/303 SNB 283/283 283/283 IVB -1 343/343 342/343 BYT 287/287 287/287 HSW 363/363 363/363 BDW 308/308 308/308 -Detailed- Platform Testdrm-intel-nightly Series Applied *IVB igt_gem_userptr_blits_minor-unsync-normal PASS(2) DMESG_WARN(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Split the batch pool by engine
On 03/18/2015 05:33 PM, Tvrtko Ursulin wrote:
On 03/18/2015 05:27 PM, Chris Wilson wrote:
On Wed, Mar 18, 2015 at 04:51:58PM +, Tvrtko Ursulin wrote:
On 03/09/2015 09:55 AM, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 21f3356cc0ab..1287abf55b84 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -96,8 +96,9 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool
*pool,
list_for_each_entry_safe(tmp, next,
pool-cache_list, batch_pool_list) {
+/* The batches are strictly LRU ordered */
if (tmp-active)
-continue;
+break;
This hunk would be a better fit for 2/6, correct?
No. The explanation is given by the comment + changelog.
I don't see this patch introducing this strict LRU ordering, rather it
was there before this patch. Am I missing something? If I am not, then I
see this hunk as a better fit with Tidy batch pool logic, than Split
the batch pool by engine.
Oh right, I got it, but not sure I like it that much. I don't think
batch pool implementation is well enough decoupled from the users. Well
in a way at least where when we talk about LRU ordering, it depends on
retiring working properly and that is not obvious from code layout and
module separation.
And then with this me move traversal inefficiency to possible more
resource use. Would it be better to fix the cause rather than symptoms?
Is it feasible? What would be the downside of retiring all rings before
submission?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/dp: Print the number of bytes processed for aux nacks
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com When doing a native or i2c aux write the sink will indicate the number of bytes written even if it the nacks the transfer. When we receive a nack we just return an error upwards, but it might still be interesting to see how many bytes made it before the nack. So include that information in the debug messages. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_dp_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index d5368ea..d7c73bd 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -462,7 +462,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) break; case DP_AUX_NATIVE_REPLY_NACK: - DRM_DEBUG_KMS(native nack\n); + DRM_DEBUG_KMS(native nack (%d)\n, ret); I guess it would be useful to print the full length too, so you know if it was a short write or not. BR, Jani. return -EREMOTEIO; case DP_AUX_NATIVE_REPLY_DEFER: @@ -493,7 +493,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) return ret; case DP_AUX_I2C_REPLY_NACK: - DRM_DEBUG_KMS(I2C nack\n); + DRM_DEBUG_KMS(I2C nack (%d)\n, ret); aux-i2c_nack_count++; return -EREMOTEIO; -- 2.0.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests
On Tue, Mar 17, 2015 at 05:22:08PM +0200, Jani Nikula wrote:
On Fri, 13 Mar 2015, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
when we continue to poll for the completion of the request.
As I said IRL, it's a bit unfortunate that setting and resetting of
DP_AUX_I2C_WRITE_STATUS_UPDATE happen at different levels of the
abstraction. But I can live with that.
We also have another problem with reporting short writes in i915,
hopefully fixed by [1]. Before that gets fixed, can't really r-b.
BR,
Jani.
[1]
http://mid.gmane.org/1426605534-5780-1-git-send-email-jani.nik...@intel.com
BTW I notice now that radeon seems to have that same problem. I won't
try to fix that, so just a FYI for the radeon folks...
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_dp_helper.c | 41
+
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c
b/drivers/gpu/drm/drm_dp_helper.c
index d5368ea..4db81a6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -422,6 +422,25 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter
*adapter)
I2C_FUNC_10BIT_ADDR;
}
+static void drm_dp_i2c_msg_set_request(struct drm_dp_aux_msg *msg,
+ const struct i2c_msg *i2c_msg)
+{
+ msg-request = (i2c_msg-flags I2C_M_RD) ?
+ DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
+ msg-request |= DP_AUX_I2C_MOT;
+}
+
+static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
+{
+ /*
+* In case of i2c defer or short i2c ack reply to a write,
+* we need to switch to WRITE_STATUS_UPDATE to drain the
+* rest of the message
+*/
+ if ((msg-request ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE)
+ msg-request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
+}
+
/*
* Transfer a single I2C-over-AUX message and handle various error
conditions,
* retrying the transaction as appropriate. It is assumed that the
@@ -490,6 +509,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
* Both native ACK and I2C ACK replies received. We
* can assume the transfer was successful.
*/
+ if (ret != msg-size)
+ drm_dp_i2c_msg_write_status_update(msg);
return ret;
case DP_AUX_I2C_REPLY_NACK:
@@ -501,6 +522,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
DRM_DEBUG_KMS(I2C defer\n);
aux-i2c_defer_count++;
usleep_range(400, 500);
+ drm_dp_i2c_msg_write_status_update(msg);
continue;
default:
@@ -566,10 +588,7 @@ static int drm_dp_i2c_xfer(struct i2c_adapter
*adapter, struct i2c_msg *msgs,
for (i = 0; i num; i++) {
msg.address = msgs[i].addr;
- msg.request = (msgs[i].flags I2C_M_RD) ?
- DP_AUX_I2C_READ :
- DP_AUX_I2C_WRITE;
- msg.request |= DP_AUX_I2C_MOT;
+ drm_dp_i2c_msg_set_request(msg, msgs[i]);
/* Send a bare address packet to start the transaction.
* Zero sized messages specify an address only (bare
* address) transaction.
@@ -577,6 +596,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter
*adapter, struct i2c_msg *msgs,
msg.buffer = NULL;
msg.size = 0;
err = drm_dp_i2c_do_msg(aux, msg);
+
+ /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+ drm_dp_i2c_msg_set_request(msg, msgs[i]);
+
if (err 0)
break;
/* We want each transaction to be as large as possible, but
@@ -589,6 +615,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter
*adapter, struct i2c_msg *msgs,
msg.size = min(transfer_size, msgs[i].len - j);
err = drm_dp_i2c_drain_msg(aux, msg);
+
+ /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+ drm_dp_i2c_msg_set_request(msg, msgs[i]);
+
if (err 0)
break;
transfer_size = err;
--
2.0.5
___
dri-devel mailing list
Re: [Intel-gfx] [Beignet] Preventing zero GPU virtual address allocation
On Thu, Mar 19, 2015 at 03:22:42AM +, Song, Ruiling wrote: Yeah, MAP_FIXED sounds a bit more ambitious and though I think it would work for OCL 2.0 pointer sharing, it's a little different than we were planning. To summarize, we have three possible approaches, each with its own problems: 1) simple patch to avoid binding at address 0 in PPGTT: does impact the ABI (though generally not in a harmful way), and may not be possible with aliasing PPGTT with e.g. framebuffers bound at offset 0 2) exposing PIN_BIAS to userspace Would allow userspace to avoid pinning any buffers at offset 0 at execbuf time, but still has the problem with previously bound buffers and aliasing PPGTT 3) MAP_FIXED interface Flexible approach allowing userspace to manage its own virtual memory, but still has the same issues with aliasing PPGTT, and with shared contexts, which would have to negotiate between libraries how to handle the zero page For (1) and (2) the kernel pieces are really already in place, the main thing we need is a new flag to userspace to indicate behavior. I'd prefer (1) with a context creation flag to indicate don't bind at 0. Execbuf would try to honor this, and userspace could check if any buffers ended up at 0 in the aliasing PPGTT case by checking the resulting offsets following the call. I expect in most cases this would be fine. It should be pretty easy to extend Ruiling's patch to use a context flag to determine the behavior; is that something you can do? Any objections to this approach? I am ok with adding a context flag to indicate don't bind at 0. Any objections from others? The patch is not from me, it is from David. I am not familiar with KMD. David, could you help on this patch? Yup, assuming, of course, that such an approach is acceptable. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Fallback to using unmappable memory for scanout
The existing ABI says that scanouts are pinned into the mappable region
so that legacy clients (e.g. old Xorg or plymouthd) can write directly
into the scanout through a GTT mapping. However if the surface does not
fit into the mappable region, we are better off just trying to fit it
anywhere and hoping for the best. (Any userspace that is cappable of
using ginormous scanouts is also likely not to rely on pure GTT
updates.) In the future, there may even be a kernel mediated method for
the legacy clients.
v2: Skip fence pinning when not mappable.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Satyanantha, Rama Gopal M rama.gopal.m.satyanan...@intel.com
Cc: Deepak S deepa...@linux.intel.com
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/i915/intel_display.c | 23 +--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9e498e0bbf22..9a1de848e450 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4034,10 +4034,15 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
/* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
-* always use map_and_fenceable for all scanout buffers.
+* always use map_and_fenceable for all scanout buffers. However,
+* it may simply be too big to fit into mappable, in which case
+* put it anyway and hope that userspace can cope (but always first
+* try to preserve the existing ABI).
*/
ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE);
if (ret)
+ ret = i915_gem_obj_ggtt_pin(obj, alignment, 0);
+ if (ret)
goto err_unpin_display;
i915_gem_object_flush_cpu_write_domain(obj);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d621ebecd33e..628aace63b43 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2308,16 +2308,18 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
if (ret)
goto err_interruptible;
- /* Install a fence for tiled scan-out. Pre-i965 always needs a
-* fence, whereas 965+ only requires a fence if using
-* framebuffer compression. For simplicity, we always install
-* a fence as the cost is not that onerous.
-*/
- ret = i915_gem_object_get_fence(obj);
- if (ret)
- goto err_unpin;
+ if (obj-map_and_fenceable) {
+ /* Install a fence for tiled scan-out. Pre-i965 always needs a
+* fence, whereas 965+ only requires a fence if using
+* framebuffer compression. For simplicity, we always, when
+* possible, install a fence as the cost is not that onerous.
+*/
+ ret = i915_gem_object_get_fence(obj);
+ if (ret)
+ goto err_unpin;
- i915_gem_object_pin_fence(obj);
+ i915_gem_object_pin_fence(obj);
+ }
dev_priv-mm.interruptible = true;
intel_runtime_pm_put(dev_priv);
@@ -2335,7 +2337,8 @@ static void intel_unpin_fb_obj(struct drm_i915_gem_object
*obj)
{
WARN_ON(!mutex_is_locked(obj-base.dev-struct_mutex));
- i915_gem_object_unpin_fence(obj);
+ if (obj-map_and_fenceable)
+ i915_gem_object_unpin_fence(obj);
i915_gem_object_unpin_from_display_plane(obj);
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some of the baytrail systems :(. Switching back to legacy mode rps. Is there any way to identify either what systems it's OK to use on, or to identif what Baytrail systems it isn't OK to use on? Just reverting this completely seems overly broad if it's possible to tell the difference between working and non-working systems. Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Split the batch pool by engine
On 03/19/2015 10:06 AM, Chris Wilson wrote: On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote: Oh right, I got it, but not sure I like it that much. I don't think batch pool implementation is well enough decoupled from the users. batch pool Splitting it this way actually improves decoupling. Of the resulting system yes, of the actual modules no in my opinion. Well in a way at least where when we talk about LRU ordering, it depends on retiring working properly and that is not obvious from code layout and module separation. I've lost you. The list is in LRU submission order. With this split, the list is both in LRU submission and LRU retirememnt order. That the two are not the same originally is not a fault of retiring not working properly, but that the hardware is split into different units and timelines. And then with this me move traversal inefficiency to possible more resource use. Would it be better to fix the cause rather than symptoms? Is it feasible? What would be the downside of retiring all rings before submission? Not really. Inefficient userspace is inefficient. All we want to be sure is that one abusive client doesn't cause a DoS on another, whilst making sure that good clients are not penalized. Not sure to which of my question your not really was the answer. I understood that this is about the completed work which hasn't been retired due the latter only happening on submission to the same ring, or with too low frequency from retire work handler. If this is true, could we just not do a retire pass on all rings on any submission? Otherwise, how do per ring pools help abusive and good client on the same ring? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/dp: Print the number of bytes processed for aux nacks
From: Ville Syrjälä ville.syrj...@linux.intel.com When doing a native or i2c aux write the sink will indicate the number of bytes written even if it the nacks the transfer. When we receive a nack we just return an error upwards, but it might still be interesting to see how many bytes made it before the nack. So include that information in the debug messages. v2: Also print the message size (Jani) Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_dp_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index d5368ea..71dcbc6 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -462,7 +462,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) break; case DP_AUX_NATIVE_REPLY_NACK: - DRM_DEBUG_KMS(native nack\n); + DRM_DEBUG_KMS(native nack (result=%d, size=%zu)\n, ret, msg-size); return -EREMOTEIO; case DP_AUX_NATIVE_REPLY_DEFER: @@ -493,7 +493,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) return ret; case DP_AUX_I2C_REPLY_NACK: - DRM_DEBUG_KMS(I2C nack\n); + DRM_DEBUG_KMS(I2C nack (result=%d, size=%zu\n, ret, msg-size); aux-i2c_nack_count++; return -EREMOTEIO; -- 2.0.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Split the batch pool by engine
On Thu, Mar 19, 2015 at 11:39:16AM +, Tvrtko Ursulin wrote: On 03/19/2015 10:06 AM, Chris Wilson wrote: On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote: Well in a way at least where when we talk about LRU ordering, it depends on retiring working properly and that is not obvious from code layout and module separation. I've lost you. The list is in LRU submission order. With this split, the list is both in LRU submission and LRU retirememnt order. That the two are not the same originally is not a fault of retiring not working properly, but that the hardware is split into different units and timelines. And then with this me move traversal inefficiency to possible more resource use. Would it be better to fix the cause rather than symptoms? Is it feasible? What would be the downside of retiring all rings before submission? Not really. Inefficient userspace is inefficient. All we want to be sure is that one abusive client doesn't cause a DoS on another, whilst making sure that good clients are not penalized. Not sure to which of my question your not really was the answer. We do fix the cause later, and I've amended the throttling in mesa to prevent a reoccurrence. So I was thinking of why we only retire on the current ring. I understood that this is about the completed work which hasn't been retired due the latter only happening on submission to the same ring, or with too low frequency from retire work handler. If this is true, could we just not do a retire pass on all rings on any submission? No. The problem is that rings retire out of order. So a global LRU submission list is not strictly separated between inactive and active objects (in contrast to the per-engine list where it is true). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/dp: Print the number of bytes processed for aux nacks
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com When doing a native or i2c aux write the sink will indicate the number of bytes written even if it the nacks the transfer. When we receive a nack we just return an error upwards, but it might still be interesting to see how many bytes made it before the nack. So include that information in the debug messages. v2: Also print the message size (Jani) Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/drm_dp_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index d5368ea..71dcbc6 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -462,7 +462,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) break; case DP_AUX_NATIVE_REPLY_NACK: - DRM_DEBUG_KMS(native nack\n); + DRM_DEBUG_KMS(native nack (result=%d, size=%zu)\n, ret, msg-size); return -EREMOTEIO; case DP_AUX_NATIVE_REPLY_DEFER: @@ -493,7 +493,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) return ret; case DP_AUX_I2C_REPLY_NACK: - DRM_DEBUG_KMS(I2C nack\n); + DRM_DEBUG_KMS(I2C nack (result=%d, size=%zu\n, ret, msg-size); aux-i2c_nack_count++; return -EREMOTEIO; -- 2.0.5 -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 52/59] drm/i915: Remove the now obsolete intel_ring_get_request()
From: John Harrison john.c.harri...@intel.com
Much of the driver has now been converted to passing requests around instead of
rings/ringbufs/contexts. Thus the function for retreiving the request from a
ring (i.e. the OLR) is no longer used and can be removed.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.h |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 365b98d..3002338 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -433,13 +433,6 @@ static inline u32 intel_ring_get_tail(struct
intel_ringbuffer *ringbuf)
return ringbuf-tail;
}
-static inline struct drm_i915_gem_request *
-intel_ring_get_request(struct intel_engine_cs *ring)
-{
- BUG_ON(ring-outstanding_lazy_request == NULL);
- return ring-outstanding_lazy_request;
-}
-
#define MIN_SPACE_FOR_ADD_REQUEST 128
int legacy_ring_reserved_space_reserve(struct drm_i915_gem_request *request);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 37/59] drm/i915: Update flush_all_caches() to take request structures
From: John Harrison john.c.harri...@intel.com
Updated the *_ring_flush_all_caches() functions to take requests instead of
rings or ringbuf/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
drivers/gpu/drm/i915/intel_lrc.c| 11 +--
drivers/gpu/drm/i915/intel_lrc.h|3 +--
drivers/gpu/drm/i915/intel_ringbuffer.c |7 ---
drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
5 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e56658..95ed3a8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2363,9 +2363,9 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
*/
if (flush_caches) {
if (i915.enable_execlists)
- ret = logical_ring_flush_all_caches(ringbuf,
request-ctx);
+ ret = logical_ring_flush_all_caches(request);
else
- ret = intel_ring_flush_all_caches(ring);
+ ret = intel_ring_flush_all_caches(request);
/* Not allowed to fail! */
WARN_ON(ret);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b2f03b9..fd80af5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -995,16 +995,15 @@ void intel_logical_ring_stop(struct intel_engine_cs *ring)
I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
}
-int logical_ring_flush_all_caches(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx)
+int logical_ring_flush_all_caches(struct drm_i915_gem_request *req)
{
- struct intel_engine_cs *ring = ringbuf-ring;
+ struct intel_engine_cs *ring = req-ring;
int ret;
if (!ring-gpu_caches_dirty)
return 0;
- ret = ring-emit_flush(ringbuf, ctx, 0, I915_GEM_GPU_DOMAINS);
+ ret = ring-emit_flush(req-ringbuf, req-ctx, 0, I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
@@ -1069,7 +1068,7 @@ static int intel_logical_ring_workarounds_emit(struct
drm_i915_gem_request *req)
return 0;
ring-gpu_caches_dirty = true;
- ret = logical_ring_flush_all_caches(ringbuf, req-ctx);
+ ret = logical_ring_flush_all_caches(req);
if (ret)
return ret;
@@ -1087,7 +1086,7 @@ static int intel_logical_ring_workarounds_emit(struct
drm_i915_gem_request *req)
intel_logical_ring_advance(ringbuf);
ring-gpu_caches_dirty = true;
- ret = logical_ring_flush_all_caches(ringbuf, req-ctx);
+ ret = logical_ring_flush_all_caches(req);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index bf137c4..044c0e5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -41,8 +41,7 @@ void intel_logical_ring_stop(struct intel_engine_cs *ring);
void intel_logical_ring_cleanup(struct intel_engine_cs *ring);
int intel_logical_rings_init(struct drm_device *dev);
-int logical_ring_flush_all_caches(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx);
+int logical_ring_flush_all_caches(struct drm_i915_gem_request *req);
/**
* intel_logical_ring_advance() - advance the ringbuffer tail
* @ringbuf: Ringbuffer to advance.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2c4f45c..b7646b7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -715,7 +715,7 @@ static int intel_ring_workarounds_emit(struct
drm_i915_gem_request *req)
return 0;
ring-gpu_caches_dirty = true;
- ret = intel_ring_flush_all_caches(ring);
+ ret = intel_ring_flush_all_caches(req);
if (ret)
return ret;
@@ -733,7 +733,7 @@ static int intel_ring_workarounds_emit(struct
drm_i915_gem_request *req)
intel_ring_advance(ring);
ring-gpu_caches_dirty = true;
- ret = intel_ring_flush_all_caches(ring);
+ ret = intel_ring_flush_all_caches(req);
if (ret)
return ret;
@@ -2871,8 +2871,9 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
}
int
-intel_ring_flush_all_caches(struct intel_engine_cs *ring)
+intel_ring_flush_all_caches(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
if (!ring-gpu_caches_dirty)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index bc79aa3..2d059d1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++
[Intel-gfx] [PATCH 24/59] drm/i915: Update do_switch() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated do_switch() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
v2: Removed some overzealous req- dereferencing.
---
drivers/gpu/drm/i915/i915_gem_context.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 26d5816..78e9c9c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -560,9 +560,10 @@ mi_set_context(struct intel_engine_cs *ring,
return ret;
}
-static int do_switch(struct intel_engine_cs *ring,
-struct intel_context *to)
+static int do_switch(struct drm_i915_gem_request *req)
{
+ struct intel_context *to = req-ctx;
+ struct intel_engine_cs *ring = req-ring;
struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct intel_context *from = ring-last_context;
u32 hw_flags = 0;
@@ -726,7 +727,7 @@ int i915_switch_context(struct drm_i915_gem_request *req)
return 0;
}
- return do_switch(req-ring, req-ctx);
+ return do_switch(req);
}
static bool contexts_enabled(struct drm_device *dev)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 44/59] drm/i915: Update ring-dispatch_execbuffer() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the various ring-dispatch_execbuffer() implementations to take a
request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
drivers/gpu/drm/i915/i915_gem_render_state.c |3 +--
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 --
drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e58e88b..cb24ca7 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1317,14 +1317,14 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
if (ret)
goto error;
- ret = ring-dispatch_execbuffer(ring,
+ ret = ring-dispatch_execbuffer(params-request,
exec_start, exec_len,
params-dispatch_flags);
if (ret)
goto error;
}
} else {
- ret = ring-dispatch_execbuffer(ring,
+ ret = ring-dispatch_execbuffer(params-request,
exec_start, exec_len,
params-dispatch_flags);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index e04cda4..a0201fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -164,8 +164,7 @@ int i915_gem_render_state_init(struct drm_i915_gem_request
*req)
if (so.rodata == NULL)
return 0;
- ret = req-ring-dispatch_execbuffer(req-ring,
-so.ggtt_offset,
+ ret = req-ring-dispatch_execbuffer(req, so.ggtt_offset,
so.rodata-batch_items * 4,
I915_DISPATCH_SECURE);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 0e55baf..77d357f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1711,10 +1711,11 @@ gen8_ring_put_irq(struct intel_engine_cs *ring)
}
static int
-i965_dispatch_execbuffer(struct intel_engine_cs *ring,
+i965_dispatch_execbuffer(struct drm_i915_gem_request *req,
u64 offset, u32 length,
unsigned dispatch_flags)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
ret = intel_ring_begin(ring, 2);
@@ -1737,10 +1738,11 @@ i965_dispatch_execbuffer(struct intel_engine_cs *ring,
#define I830_TLB_ENTRIES (2)
#define I830_WA_SIZE max(I830_TLB_ENTRIES*4096, I830_BATCH_LIMIT)
static int
-i830_dispatch_execbuffer(struct intel_engine_cs *ring,
+i830_dispatch_execbuffer(struct drm_i915_gem_request *req,
u64 offset, u32 len,
unsigned dispatch_flags)
{
+ struct intel_engine_cs *ring = req-ring;
u32 cs_offset = ring-scratch.gtt_offset;
int ret;
@@ -1799,10 +1801,11 @@ i830_dispatch_execbuffer(struct intel_engine_cs *ring,
}
static int
-i915_dispatch_execbuffer(struct intel_engine_cs *ring,
+i915_dispatch_execbuffer(struct drm_i915_gem_request *req,
u64 offset, u32 len,
unsigned dispatch_flags)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
ret = intel_ring_begin(ring, 2);
@@ -2402,10 +2405,11 @@ static int gen6_bsd_ring_flush(struct
drm_i915_gem_request *req,
}
static int
-gen8_ring_dispatch_execbuffer(struct intel_engine_cs *ring,
+gen8_ring_dispatch_execbuffer(struct drm_i915_gem_request *req,
u64 offset, u32 len,
unsigned dispatch_flags)
{
+ struct intel_engine_cs *ring = req-ring;
bool ppgtt = USES_PPGTT(ring-dev)
!(dispatch_flags I915_DISPATCH_SECURE);
int ret;
@@ -2425,10 +2429,11 @@ gen8_ring_dispatch_execbuffer(struct intel_engine_cs
*ring,
}
static int
-hsw_ring_dispatch_execbuffer(struct intel_engine_cs *ring,
+hsw_ring_dispatch_execbuffer(struct drm_i915_gem_request *req,
u64 offset, u32 len,
unsigned dispatch_flags)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
ret = intel_ring_begin(ring, 2);
@@ -2447,10 +2452,11 @@ hsw_ring_dispatch_execbuffer(struct intel_engine_cs
*ring,
}
static
[Intel-gfx] [PATCH 29/59] drm/i915: Update overlay code to do explicit request management
From: John Harrison john.c.harri...@intel.com
The overlay update code path to do explicit request creation and submission
rather than relying on the OLR to do the right thing.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_overlay.c | 56 +-
1 file changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index ce7797c..090fedd 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -209,17 +209,15 @@ static void intel_overlay_unmap_regs(struct intel_overlay
*overlay,
}
static int intel_overlay_do_wait_request(struct intel_overlay *overlay,
+struct drm_i915_gem_request *req,
void (*tail)(struct intel_overlay *))
{
struct drm_device *dev = overlay-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_engine_cs *ring = dev_priv-ring[RCS];
int ret;
BUG_ON(overlay-last_flip_req);
- i915_gem_request_assign(overlay-last_flip_req,
-ring-outstanding_lazy_request);
- i915_add_request(ring);
+ i915_gem_request_assign(overlay-last_flip_req, req);
+ i915_add_request(req-ring);
overlay-flip_tail = tail;
ret = i915_wait_request(overlay-last_flip_req);
@@ -237,6 +235,7 @@ static int intel_overlay_on(struct intel_overlay *overlay)
struct drm_device *dev = overlay-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_engine_cs *ring = dev_priv-ring[RCS];
+ struct drm_i915_gem_request *req;
int ret;
BUG_ON(overlay-active);
@@ -244,17 +243,23 @@ static int intel_overlay_on(struct intel_overlay *overlay)
WARN_ON(IS_I830(dev) !(dev_priv-quirks QUIRK_PIPEA_FORCE));
- ret = intel_ring_begin(ring, 4);
+ ret = i915_gem_request_alloc(ring, ring-default_context, req);
if (ret)
return ret;
+ ret = intel_ring_begin(ring, 4);
+ if (ret) {
+ i915_gem_request_cancel(req);
+ return ret;
+ }
+
intel_ring_emit(ring, MI_OVERLAY_FLIP | MI_OVERLAY_ON);
intel_ring_emit(ring, overlay-flip_addr | OFC_UPDATE);
intel_ring_emit(ring, MI_WAIT_FOR_EVENT | MI_WAIT_FOR_OVERLAY_FLIP);
intel_ring_emit(ring, MI_NOOP);
intel_ring_advance(ring);
- return intel_overlay_do_wait_request(overlay, NULL);
+ return intel_overlay_do_wait_request(overlay, req, NULL);
}
/* overlay needs to be enabled in OCMD reg */
@@ -264,6 +269,7 @@ static int intel_overlay_continue(struct intel_overlay
*overlay,
struct drm_device *dev = overlay-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_engine_cs *ring = dev_priv-ring[RCS];
+ struct drm_i915_gem_request *req;
u32 flip_addr = overlay-flip_addr;
u32 tmp;
int ret;
@@ -278,18 +284,23 @@ static int intel_overlay_continue(struct intel_overlay
*overlay,
if (tmp (1 17))
DRM_DEBUG(overlay underrun, DOVSTA: %x\n, tmp);
- ret = intel_ring_begin(ring, 2);
+ ret = i915_gem_request_alloc(ring, ring-default_context, req);
if (ret)
return ret;
+ ret = intel_ring_begin(ring, 2);
+ if (ret) {
+ i915_gem_request_cancel(req);
+ return ret;
+ }
+
intel_ring_emit(ring, MI_OVERLAY_FLIP | MI_OVERLAY_CONTINUE);
intel_ring_emit(ring, flip_addr);
intel_ring_advance(ring);
WARN_ON(overlay-last_flip_req);
- i915_gem_request_assign(overlay-last_flip_req,
-ring-outstanding_lazy_request);
- i915_add_request(ring);
+ i915_gem_request_assign(overlay-last_flip_req, req);
+ i915_add_request(req-ring);
return 0;
}
@@ -326,6 +337,7 @@ static int intel_overlay_off(struct intel_overlay *overlay)
struct drm_device *dev = overlay-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_engine_cs *ring = dev_priv-ring[RCS];
+ struct drm_i915_gem_request *req;
u32 flip_addr = overlay-flip_addr;
int ret;
@@ -337,10 +349,16 @@ static int intel_overlay_off(struct intel_overlay
*overlay)
* of the hw. Do it in both cases */
flip_addr |= OFC_UPDATE;
- ret = intel_ring_begin(ring, 6);
+ ret = i915_gem_request_alloc(ring, ring-default_context, req);
if (ret)
return ret;
+ ret = intel_ring_begin(ring, 6);
+ if (ret) {
+ i915_gem_request_cancel(req);
+ return ret;
+ }
+
/* wait for overlay to go idle */
intel_ring_emit(ring, MI_OVERLAY_FLIP |
[Intel-gfx] [PATCH 39/59] drm/i915: Update ring-flush() to take a requests structure
From: John Harrison john.c.harri...@intel.com
Udpated the various ring-flush() functions to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c |6 +++---
drivers/gpu/drm/i915/i915_trace.h | 14 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 34 +++
drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
5 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 35116d3..2c94c88 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -493,7 +493,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32
hw_flags)
* itlb_before_ctx_switch.
*/
if (IS_GEN6(ring-dev)) {
- ret = ring-flush(ring, I915_GEM_GPU_DOMAINS, 0);
+ ret = ring-flush(req, I915_GEM_GPU_DOMAINS, 0);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 96fd8e0..5822429 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -885,7 +885,7 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
int ret;
/* NB: TLBs must be flushed and invalidated before a switch */
- ret = ring-flush(ring, I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
+ ret = ring-flush(req, I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
@@ -922,7 +922,7 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
int ret;
/* NB: TLBs must be flushed and invalidated before a switch */
- ret = ring-flush(ring, I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
+ ret = ring-flush(req, I915_GEM_GPU_DOMAINS, I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
@@ -940,7 +940,7 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
/* XXX: RCS is the only one to auto invalidate the TLBs? */
if (ring-id != RCS) {
- ret = ring-flush(ring, I915_GEM_GPU_DOMAINS,
I915_GEM_GPU_DOMAINS);
+ ret = ring-flush(req, I915_GEM_GPU_DOMAINS,
I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index f004d3d..f044e29 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -377,25 +377,27 @@ TRACE_EVENT(i915_gem_ring_dispatch,
);
TRACE_EVENT(i915_gem_ring_flush,
- TP_PROTO(struct intel_engine_cs *ring, u32 invalidate, u32 flush),
- TP_ARGS(ring, invalidate, flush),
+ TP_PROTO(struct drm_i915_gem_request *req, u32 invalidate, u32
flush),
+ TP_ARGS(req, invalidate, flush),
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, ring)
+__field(u32, uniq)
__field(u32, invalidate)
__field(u32, flush)
),
TP_fast_assign(
- __entry-dev = ring-dev-primary-index;
- __entry-ring = ring-id;
+ __entry-dev = req-ring-dev-primary-index;
+ __entry-ring = req-ring-id;
+ __entry-uniq = req-uniq;
__entry-invalidate = invalidate;
__entry-flush = flush;
),
- TP_printk(dev=%u, ring=%x, invalidate=%04x, flush=%04x,
- __entry-dev, __entry-ring,
+ TP_printk(dev=%u, ring=%x, request=%u, invalidate=%04x,
flush=%04x,
+ __entry-dev, __entry-ring, __entry-uniq,
__entry-invalidate, __entry-flush)
);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b7646b7..a29fa40 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -91,10 +91,11 @@ static void __intel_ring_advance(struct intel_engine_cs
*ring)
}
static int
-gen2_render_ring_flush(struct intel_engine_cs *ring,
+gen2_render_ring_flush(struct drm_i915_gem_request *req,
u32 invalidate_domains,
u32 flush_domains)
{
+ struct intel_engine_cs *ring = req-ring;
u32 cmd;
int ret;
@@ -117,10 +118,11 @@ gen2_render_ring_flush(struct intel_engine_cs *ring,
}
static int
-gen4_render_ring_flush(struct intel_engine_cs *ring,
+gen4_render_ring_flush(struct drm_i915_gem_request *req,
[Intel-gfx] [PATCH 31/59] drm/i915: Update add_request() to take a request structure
From: John Harrison john.c.harri...@intel.com
Now that all callers of i915_add_request() have a request pointer to hand, it is
possible to update the add request function to take a request pointer rather
than pulling it out of the OLR.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 10 +-
drivers/gpu/drm/i915/i915_gem.c| 22 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
drivers/gpu/drm/i915/intel_overlay.c |4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c|3 ++-
7 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1fd59bc..7e0a095 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2751,14 +2751,14 @@ void i915_gem_init_swizzling(struct drm_device *dev);
void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_suspend(struct drm_device *dev);
-void __i915_add_request(struct intel_engine_cs *ring,
+void __i915_add_request(struct drm_i915_gem_request *req,
struct drm_file *file,
struct drm_i915_gem_object *batch_obj,
bool flush_caches);
-#define i915_add_request(ring) \
- __i915_add_request(ring, NULL, NULL, true)
-#define i915_add_request_no_flush(ring) \
- __i915_add_request(ring, NULL, NULL, false)
+#define i915_add_request(req) \
+ __i915_add_request(req, NULL, NULL, true)
+#define i915_add_request_no_flush(req) \
+ __i915_add_request(req, NULL, NULL, false)
int __i915_wait_request(struct drm_i915_gem_request *req,
unsigned reset_counter,
bool interruptible,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9114071..9f615bf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1162,7 +1162,7 @@ i915_gem_check_olr(struct drm_i915_gem_request *req)
WARN_ON(!mutex_is_locked(req-ring-dev-struct_mutex));
if (req == req-ring-outstanding_lazy_request)
- i915_add_request(req-ring);
+ i915_add_request(req);
return 0;
}
@@ -2327,25 +2327,25 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
* request is not being tracked for completion but the work itself is
* going to happen on the hardware. This would be a Bad Thing(tm).
*/
-void __i915_add_request(struct intel_engine_cs *ring,
+void __i915_add_request(struct drm_i915_gem_request *request,
struct drm_file *file,
struct drm_i915_gem_object *obj,
bool flush_caches)
{
- struct drm_i915_private *dev_priv = ring-dev-dev_private;
- struct drm_i915_gem_request *request;
+ struct intel_engine_cs *ring;
+ struct drm_i915_private *dev_priv;
struct intel_ringbuffer *ringbuf;
u32 request_start;
int ret;
- request = ring-outstanding_lazy_request;
if (WARN_ON(request == NULL))
return;
- if (i915.enable_execlists) {
- ringbuf = request-ctx-engine[ring-id].ringbuf;
- } else
- ringbuf = ring-buffer;
+ ring = request-ring;
+ dev_priv = ring-dev-dev_private;
+ ringbuf = request-ringbuf;
+
+ WARN_ON(request != ring-outstanding_lazy_request);
/*
* To ensure that this call will not fail, space for it's emissions
@@ -3137,7 +3137,7 @@ int i915_gpu_idle(struct drm_device *dev)
return ret;
}
- i915_add_request_no_flush(req-ring);
+ i915_add_request_no_flush(req);
}
WARN_ON(ring-outstanding_lazy_request);
@@ -4942,7 +4942,7 @@ i915_gem_init_hw(struct drm_device *dev)
goto out;
}
- i915_add_request_no_flush(ring);
+ i915_add_request_no_flush(req);
}
out:
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1978f9c..af4718d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1060,7 +1060,7 @@ i915_gem_execbuffer_retire_commands(struct
i915_execbuffer_params *params)
params-ring-gpu_caches_dirty = true;
/* Add a breadcrumb for the completion of the batch buffer */
- __i915_add_request(params-ring, params-file, params-batch_obj, true);
+ __i915_add_request(params-request, params-file, params-batch_obj,
true);
}
static int
diff
[Intel-gfx] [PATCH 48/59] drm/i915: Update cacheline_align() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated intel_ring_cacheline_align() to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_display.c|2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c |3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5236e59..277c73a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9605,7 +9605,7 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
* then do the cacheline alignment, and finally emit the
* MI_DISPLAY_FLIP.
*/
- ret = intel_ring_cacheline_align(ring);
+ ret = intel_ring_cacheline_align(req);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 10cb242..9cbc4ef 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2290,8 +2290,9 @@ int intel_ring_begin(struct intel_engine_cs *ring,
}
/* Align the ring tail to a cacheline boundary */
-int intel_ring_cacheline_align(struct intel_engine_cs *ring)
+int intel_ring_cacheline_align(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
int num_dwords = (ring-buffer-tail (CACHELINE_BYTES - 1)) /
sizeof(uint32_t);
int ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 1af00b2..e353531 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -392,7 +392,7 @@ void intel_cleanup_ring_buffer(struct intel_engine_cs
*ring);
int intel_ring_alloc_request_extras(struct drm_i915_gem_request *request);
int __must_check intel_ring_begin(struct intel_engine_cs *ring, int n);
-int __must_check intel_ring_cacheline_align(struct intel_engine_cs *ring);
+int __must_check intel_ring_cacheline_align(struct drm_i915_gem_request *req);
static inline void intel_ring_emit(struct intel_engine_cs *ring,
u32 data)
{
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 53/59] drm/i915: Remove the now obsolete 'outstanding_lazy_request'
From: John Harrison john.c.harri...@intel.com
The outstanding_lazy_request is no longer used anywhere in the driver.
Everything that was looking at it now has a request explicitly passed in from on
high. Everything that was relying upon it behind the scenes is now explicitly
creating/passing/submitting it's own private request. Thus the OLR can be
removed.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c| 16 ++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 +---
drivers/gpu/drm/i915/intel_lrc.c |1 -
drivers/gpu/drm/i915/intel_ringbuffer.c|8
drivers/gpu/drm/i915/intel_ringbuffer.h|4
5 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fe2de21..9ff9bda 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1161,9 +1161,6 @@ i915_gem_check_olr(struct drm_i915_gem_request *req)
{
WARN_ON(!mutex_is_locked(req-ring-dev-struct_mutex));
- if (req == req-ring-outstanding_lazy_request)
- i915_add_request(req);
-
return 0;
}
@@ -2344,8 +2341,6 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
dev_priv = ring-dev-dev_private;
ringbuf = request-ringbuf;
- WARN_ON(request != ring-outstanding_lazy_request);
-
/*
* To ensure that this call will not fail, space for it's emissions
* should already have been reserved in the ring buffer. Let the ring
@@ -2412,7 +2407,6 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
}
trace_i915_gem_request_add(request);
- ring-outstanding_lazy_request = NULL;
i915_queue_hangcheck(ring-dev);
@@ -2526,8 +2520,7 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
if (!req_out)
return -EINVAL;
- if ((*req_out = ring-outstanding_lazy_request) != NULL)
- return 0;
+ *req_out = NULL;
request = kzalloc(sizeof(*request), GFP_KERNEL);
if (request == NULL)
@@ -2576,7 +2569,7 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
return ret;
}
- *req_out = ring-outstanding_lazy_request = request;
+ *req_out = request;
return 0;
}
@@ -2671,9 +2664,6 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
i915_gem_free_request(request);
}
-
- /* This may not have been flushed before the reset, so clean it now */
- i915_gem_request_assign(ring-outstanding_lazy_request, NULL);
}
void i915_gem_restore_fences(struct drm_device *dev)
@@ -3131,8 +3121,6 @@ int i915_gpu_idle(struct drm_device *dev)
i915_add_request_no_flush(req);
}
- WARN_ON(ring-outstanding_lazy_request);
-
ret = intel_ring_idle(ring);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9345db8..c512979 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1638,10 +1638,8 @@ err:
* must be freed again. If it was submitted then it is being tracked
* on the active request list and no clean up is required here.
*/
- if (ret params-request) {
+ if (ret params-request)
i915_gem_request_cancel(params-request);
- ring-outstanding_lazy_request = NULL;
- }
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8cb34c6..60bcf9a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1384,7 +1384,6 @@ void intel_logical_ring_cleanup(struct intel_engine_cs
*ring)
intel_logical_ring_stop(ring);
WARN_ON((I915_READ_MODE(ring) MODE_IDLE) == 0);
- i915_gem_request_assign(ring-outstanding_lazy_request, NULL);
if (ring-cleanup)
ring-cleanup(ring);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c7dcabd..c5752c4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2051,7 +2051,6 @@ void intel_cleanup_ring_buffer(struct intel_engine_cs
*ring)
intel_unpin_ringbuffer_obj(ringbuf);
intel_destroy_ringbuffer_obj(ringbuf);
- i915_gem_request_assign(ring-outstanding_lazy_request, NULL);
if (ring-cleanup)
ring-cleanup(ring);
@@ -2182,11 +2181,6 @@ int intel_ring_idle(struct intel_engine_cs *ring)
{
struct drm_i915_gem_request *req;
- /* We need to add any requests required to flush the objects and ring */
-
[Intel-gfx] [PATCH 51/59] drm/i915: Add *_ring_begin() to request allocation
From: John Harrison john.c.harri...@intel.com
Now that the *_ring_begin() functions no longer call the request allocation
code, it is finally safe for the request allocation code to call *_ring_begin().
This is important to guarantee that the space reserved for the subsequent
i915_add_request() call does actually get reserved.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 16
drivers/gpu/drm/i915/intel_lrc.c| 15 +++
drivers/gpu/drm/i915/intel_lrc.h|1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 28 +---
drivers/gpu/drm/i915/intel_ringbuffer.h |3 ++-
5 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b047693..fe2de21 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2561,19 +2561,11 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
* i915_add_request() call can't fail. Note that the reserve may need
* to be redone if the request is not actually submitted straight
* away, e.g. because a GPU scheduler has deferred it.
-*
-* Note further that this call merely notes the reserve request. A
-* subsequent call to *_ring_begin() is required to actually ensure
-* that the reservation is available. Without the begin, if the
-* request creator immediately submitted the request without adding
-* any commands to it then there might not actually be sufficient
-* room for the submission commands. Unfortunately, the current
-* *_ring_begin() implementations potentially call back here to
-* i915_gem_request_alloc(). Thus calling _begin() here would lead to
-* infinite recursion! Until that back call path is removed, it is
-* necessary to do a manual _begin() outside.
*/
- ret = intel_ring_reserved_space_reserve(request-ringbuf,
MIN_SPACE_FOR_ADD_REQUEST);
+ if (i915.enable_execlists)
+ ret = logical_ring_reserved_space_reserve(request);
+ else
+ ret = legacy_ring_reserved_space_reserve(request);
if (ret) {
/*
* At this point, the request is fully allocated even if not
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c16d726..8cb34c6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -829,6 +829,21 @@ static int intel_logical_ring_begin(struct
drm_i915_gem_request *req,
return 0;
}
+int logical_ring_reserved_space_reserve(struct drm_i915_gem_request *request)
+{
+ /*
+* The first call merely notes the reserve request and is common for
+* all back ends. The subsequent localised _begin() call actually
+* ensures that the reservation is available. Without the begin, if
+* the request creator immediately submitted the request without
+* adding any commands to it then there might not actually be
+* sufficient room for the submission commands.
+*/
+ intel_ring_reserved_space_reserve(request-ringbuf,
MIN_SPACE_FOR_ADD_REQUEST);
+
+ return intel_logical_ring_begin(request, 0);
+}
+
/**
* execlists_submission() - submit a batchbuffer for execution, Execlists style
* @dev: DRM device.
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 044c0e5..905a83e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -37,6 +37,7 @@
/* Logical Rings */
int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request);
+int logical_ring_reserved_space_reserve(struct drm_i915_gem_request *request);
void intel_logical_ring_stop(struct intel_engine_cs *ring);
void intel_logical_ring_cleanup(struct intel_engine_cs *ring);
int intel_logical_rings_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6f198df..c7dcabd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2205,21 +2205,27 @@ int intel_ring_alloc_request_extras(struct
drm_i915_gem_request *request)
return 0;
}
-int intel_ring_reserved_space_reserve(struct intel_ringbuffer *ringbuf, int
size)
+int legacy_ring_reserved_space_reserve(struct drm_i915_gem_request *request)
{
- /* NB: Until request management is fully tidied up and the OLR is
-* removed, there are too many ways for get false hits on this
-* anti-recursion check! */
- /*WARN_ON(ringbuf-reserved_size);*/
+ /*
+* The first call merely notes the reserve request and is common for
+* all back ends. The subsequent localised _begin() call actually
+* ensures that the reservation is available.
[Intel-gfx] [PATCH 41/59] drm/i915: Update ring-emit_flush() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the various ring-emit_flush() implementations to take a request instead
of a ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 17 -
drivers/gpu/drm/i915/intel_ringbuffer.h |3 +--
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fd80af5..ba49f50 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -569,8 +569,7 @@ static int logical_ring_invalidate_all_caches(struct
drm_i915_gem_request *req)
if (ring-gpu_caches_dirty)
flush_domains = I915_GEM_GPU_DOMAINS;
- ret = ring-emit_flush(req-ringbuf, req-ctx,
- I915_GEM_GPU_DOMAINS, flush_domains);
+ ret = ring-emit_flush(req, I915_GEM_GPU_DOMAINS, flush_domains);
if (ret)
return ret;
@@ -1003,7 +1002,7 @@ int logical_ring_flush_all_caches(struct
drm_i915_gem_request *req)
if (!ring-gpu_caches_dirty)
return 0;
- ret = ring-emit_flush(req-ringbuf, req-ctx, 0, I915_GEM_GPU_DOMAINS);
+ ret = ring-emit_flush(req, 0, I915_GEM_GPU_DOMAINS);
if (ret)
return ret;
@@ -1201,18 +1200,18 @@ static void gen8_logical_ring_put_irq(struct
intel_engine_cs *ring)
spin_unlock_irqrestore(dev_priv-irq_lock, flags);
}
-static int gen8_emit_flush(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx,
+static int gen8_emit_flush(struct drm_i915_gem_request *request,
u32 invalidate_domains,
u32 unused)
{
+ struct intel_ringbuffer *ringbuf = request-ringbuf;
struct intel_engine_cs *ring = ringbuf-ring;
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t cmd;
int ret;
- ret = intel_logical_ring_begin(ringbuf, ctx, 4);
+ ret = intel_logical_ring_begin(ringbuf, request-ctx, 4);
if (ret)
return ret;
@@ -1242,11 +1241,11 @@ static int gen8_emit_flush(struct intel_ringbuffer
*ringbuf,
return 0;
}
-static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx,
+static int gen8_emit_flush_render(struct drm_i915_gem_request *request,
u32 invalidate_domains,
u32 flush_domains)
{
+ struct intel_ringbuffer *ringbuf = request-ringbuf;
struct intel_engine_cs *ring = ringbuf-ring;
u32 scratch_addr = ring-scratch.gtt_offset + 2 * CACHELINE_BYTES;
u32 flags = 0;
@@ -1270,7 +1269,7 @@ static int gen8_emit_flush_render(struct intel_ringbuffer
*ringbuf,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
}
- ret = intel_logical_ring_begin(ringbuf, ctx, 6);
+ ret = intel_logical_ring_begin(ringbuf, request-ctx, 6);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 55f6f35..94182de 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -238,8 +238,7 @@ struct intel_engine_cs {
u32 irq_keep_mask; /* bitmask for interrupts that should
not be masked */
int (*emit_request)(struct intel_ringbuffer *ringbuf,
struct drm_i915_gem_request *request);
- int (*emit_flush)(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx,
+ int (*emit_flush)(struct drm_i915_gem_request *request,
u32 invalidate_domains,
u32 flush_domains);
int (*emit_bb_start)(struct intel_ringbuffer *ringbuf,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 58/59] drm/i915: Remove the now obsolete 'i915_gem_check_olr()'
From: John Harrison john.c.harri...@intel.com
As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 28
2 files changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 764ee4f..0a68dbc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2713,7 +2713,6 @@ bool i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_requests_ring(struct intel_engine_cs *ring);
int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible);
-int __must_check i915_gem_check_olr(struct drm_i915_gem_request *req);
static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ecdae34..acb824c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1153,17 +1153,6 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
return 0;
}
-/*
- * Compare arbitrary request against outstanding lazy request. Emit on match.
- */
-int
-i915_gem_check_olr(struct drm_i915_gem_request *req)
-{
- WARN_ON(!mutex_is_locked(req-ring-dev-struct_mutex));
-
- return 0;
-}
-
static void fake_irq(unsigned long data)
{
wake_up_process((struct task_struct *)data);
@@ -1338,10 +1327,6 @@ i915_wait_request(struct drm_i915_gem_request *req)
if (ret)
return ret;
- ret = i915_gem_check_olr(req);
- if (ret)
- return ret;
-
reset_counter = atomic_read(dev_priv-gpu_error.reset_counter);
i915_gem_request_reference(req);
ret = __i915_wait_request(req, reset_counter,
@@ -1415,10 +1400,6 @@ i915_gem_object_wait_rendering__nonblocking(struct
drm_i915_gem_object *obj,
if (ret)
return ret;
- ret = i915_gem_check_olr(req);
- if (ret)
- return ret;
-
reset_counter = atomic_read(dev_priv-gpu_error.reset_counter);
i915_gem_request_reference(req);
mutex_unlock(dev-struct_mutex);
@@ -2852,15 +2833,10 @@ static int
i915_gem_object_flush_active(struct drm_i915_gem_object *obj)
{
struct intel_engine_cs *ring;
- int ret;
if (obj-active) {
ring = i915_gem_request_get_ring(obj-last_read_req);
- ret = i915_gem_check_olr(obj-last_read_req);
- if (ret)
- return ret;
-
i915_gem_retire_requests_ring(ring);
}
@@ -2997,10 +2973,6 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
return ret;
}
- ret = i915_gem_check_olr(obj-last_read_req);
- if (ret)
- return ret;
-
trace_i915_gem_ring_sync_to(*to_req, from, obj-last_read_req);
ret = to-semaphore.sync_to(*to_req, from, seqno);
if (!ret)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/59] drm/i915: Moved the for_each_ring loop outside of i915_gem_context_enable()
From: John Harrison john.c.harri...@intel.com
The start of day context initialisation code in i915_gem_context_enable() loops
over each ring and calls the legacy switch context or the execlist init context
code as appropriate.
This patch moves the ring looping out of that function in to the top level
caller i915_gem_init_hw(). This means the a single pass can be made over all
rings doing the PPGTT, L3 remap and context initialisation of each ring
altogether.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c | 17 +---
drivers/gpu/drm/i915/i915_gem_context.c | 32 +++
3 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4bcb43f..cc957d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2889,7 +2889,7 @@ int __must_check i915_gem_context_init(struct drm_device
*dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
-int i915_gem_context_enable(struct drm_i915_private *dev_priv);
+int i915_gem_context_enable(struct intel_engine_cs *ring);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct intel_engine_cs *ring,
struct intel_context *to);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 683fc80..29568c4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4883,6 +4883,8 @@ i915_gem_init_hw(struct drm_device *dev)
*/
init_unused_rings(dev);
+ BUG_ON(!dev_priv-ring[RCS].default_context);
+
ret = i915_ppgtt_init_hw(dev);
if (ret) {
DRM_ERROR(PPGTT enable HW failed %d\n, ret);
@@ -4898,6 +4900,8 @@ i915_gem_init_hw(struct drm_device *dev)
/* Now it is safe to go back round and do everything else: */
for_each_ring(ring, dev_priv, i) {
+ WARN_ON(!ring-default_context);
+
if (ring-id == RCS) {
for (i = 0; i NUM_L3_SLICES(dev); i++)
i915_gem_l3_remap(ring, i);
@@ -4909,14 +4913,13 @@ i915_gem_init_hw(struct drm_device *dev)
i915_gem_cleanup_ringbuffer(dev);
goto out;
}
- }
- ret = i915_gem_context_enable(dev_priv);
- if (ret ret != -EIO) {
- DRM_ERROR(Context enable failed %d\n, ret);
- i915_gem_cleanup_ringbuffer(dev);
-
- goto out;
+ ret = i915_gem_context_enable(ring);
+ if (ret ret != -EIO) {
+ DRM_ERROR(Context enable ring #%d failed %d\n, i,
ret);
+ i915_gem_cleanup_ringbuffer(dev);
+ goto out;
+ }
}
out:
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 70346b0..f51faad 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -407,32 +407,22 @@ void i915_gem_context_fini(struct drm_device *dev)
i915_gem_context_unreference(dctx);
}
-int i915_gem_context_enable(struct drm_i915_private *dev_priv)
+int i915_gem_context_enable(struct intel_engine_cs *ring)
{
- struct intel_engine_cs *ring;
- int ret, i;
-
- BUG_ON(!dev_priv-ring[RCS].default_context);
+ int ret;
if (i915.enable_execlists) {
- for_each_ring(ring, dev_priv, i) {
- if (ring-init_context) {
- ret = ring-init_context(ring,
- ring-default_context);
- if (ret) {
- DRM_ERROR(ring init context: %d\n,
- ret);
- return ret;
- }
- }
- }
+ if (ring-init_context == NULL)
+ return 0;
+ ret = ring-init_context(ring, ring-default_context);
} else
- for_each_ring(ring, dev_priv, i) {
- ret = i915_switch_context(ring, ring-default_context);
- if (ret)
- return ret;
- }
+ ret = i915_switch_context(ring, ring-default_context);
+
+ if (ret) {
+ DRM_ERROR(ring init context: %d\n, ret);
+ return ret;
+ }
return 0;
}
--
1.7.9.5
[Intel-gfx] [PATCH 54/59] drm/i915: Move the request/file and request/pid association to creation time
From: John Harrison john.c.harri...@intel.com
In _i915_add_request(), the request is associated with a userland client.
Specifically it is linked to the 'file' structure and the current user process
is recorded. One problem here is that the current user process is not
necessarily the same as when the request was submitted to the driver. This is
especially true when the GPU scheduler arrives and decouples driver submission
from hardware submission. Note also that it is only in the case where the add
request comes from an execbuff call that there is a client to associate. Any
other add request call is kernel only so does not need to do it.
This patch moves the client association into a separate function. This is then
called from the execbuffer code path itself at a sensible time. It also removes
the now redundant 'file' pointer from the add request parameter list.
An extra cleanup of the client association is also added to the request clean up
code for the eventuality where the request is killed after association but
before being submitted (e.g. due to out of memory error somewhere). Once the
submission has happened, the request is on the request list and the regular
request list removal will clear the association. Note that this still needs to
happen at this point in time because the request might be kept floating around
much longer (due to someone holding a reference count) and the client should not
be worrying about this request after it has been retired.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|8 +++--
drivers/gpu/drm/i915/i915_gem.c| 53
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +++-
3 files changed, 48 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 839c185..764ee4f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2127,6 +2127,9 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
void i915_gem_request_free(struct kref *req_ref);
+void i915_gem_request_remove_from_client(struct drm_i915_gem_request *request);
+int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
+ struct drm_file *file);
static inline uint32_t
i915_gem_request_get_seqno(struct drm_i915_gem_request *req)
@@ -2752,13 +2755,12 @@ void i915_gem_cleanup_ringbuffer(struct drm_device
*dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_suspend(struct drm_device *dev);
void __i915_add_request(struct drm_i915_gem_request *req,
- struct drm_file *file,
struct drm_i915_gem_object *batch_obj,
bool flush_caches);
#define i915_add_request(req) \
- __i915_add_request(req, NULL, NULL, true)
+ __i915_add_request(req, NULL, true)
#define i915_add_request_no_flush(req) \
- __i915_add_request(req, NULL, NULL, false)
+ __i915_add_request(req, NULL, false)
int __i915_wait_request(struct drm_i915_gem_request *req,
unsigned reset_counter,
bool interruptible,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ff9bda..ecdae34 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2324,7 +2324,6 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
* going to happen on the hardware. This would be a Bad Thing(tm).
*/
void __i915_add_request(struct drm_i915_gem_request *request,
- struct drm_file *file,
struct drm_i915_gem_object *obj,
bool flush_caches)
{
@@ -2392,19 +2391,6 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
request-emitted_jiffies = jiffies;
list_add_tail(request-list, ring-request_list);
- request-file_priv = NULL;
-
- if (file) {
- struct drm_i915_file_private *file_priv = file-driver_priv;
-
- spin_lock(file_priv-mm.lock);
- request-file_priv = file_priv;
- list_add_tail(request-client_list,
- file_priv-mm.request_list);
- spin_unlock(file_priv-mm.lock);
-
- request-pid = get_pid(task_pid(current));
- }
trace_i915_gem_request_add(request);
@@ -2420,7 +2406,34 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
intel_ring_reserved_space_end(ringbuf);
}
-static inline void
+int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
+ struct drm_file *file)
+{
+ struct drm_i915_private *dev_private;
+ struct drm_i915_file_private
[Intel-gfx] [PATCH 55/59] drm/i915: Remove fallback poll for ring buffer space
From: John Harrison john.c.harri...@intel.com
When the ring buffer is full, the driver finds an outstanding request that will
free up sufficient space for the current operation and waits for it to complete.
If no such request can be found, there is a fall back path of just polling until
sufficient space is available.
This path should not be required any more. It is a hangover from the bad days of
OLR such that it was possible for the ring to be completely filled without ever
having submitted a request. This can no longer happen as requests are now
submitted in a timely manner. Hence the entire polling path is obsolete. As it
also causes headaches in LRC land due to nesting faked requests, it is being
removed entirely.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 65 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 62 +++--
2 files changed, 13 insertions(+), 114 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 60bcf9a..f21f449 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -622,8 +622,9 @@ int intel_logical_ring_alloc_request_extras(struct
drm_i915_gem_request *request
return 0;
}
-static int logical_ring_wait_request(struct intel_ringbuffer *ringbuf,
-int bytes)
+static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf,
+ struct intel_context *ctx,
+ int bytes)
{
struct intel_engine_cs *ring = ringbuf-ring;
struct drm_i915_gem_request *request;
@@ -652,8 +653,11 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
break;
}
- if (request-list == ring-request_list)
+ /* It should always be possible to find a suitable request! */
+ if (request-list == ring-request_list) {
+ WARN_ON(true);
return -ENOSPC;
+ }
ret = i915_wait_request(request);
if (ret)
@@ -663,7 +667,7 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
WARN_ON(intel_ring_space(ringbuf) new_space);
- return intel_ring_space(ringbuf) = bytes ? 0 : -ENOSPC;
+ return 0;
}
/*
@@ -690,59 +694,6 @@ intel_logical_ring_advance_and_submit(struct
intel_ringbuffer *ringbuf,
execlists_context_queue(ring, ctx, ringbuf-tail, request);
}
-static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx,
- int bytes)
-{
- struct intel_engine_cs *ring = ringbuf-ring;
- struct drm_device *dev = ring-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- unsigned long end;
- int ret;
-
- /* The whole point of reserving space is to not wait! */
- WARN_ON(ringbuf-reserved_in_use);
-
- ret = logical_ring_wait_request(ringbuf, bytes);
- if (ret != -ENOSPC)
- return ret;
-
- /* Force the context submission in case we have been skipping it */
- intel_logical_ring_advance_and_submit(ringbuf, ctx, NULL);
-
- /* With GEM the hangcheck timer should kick us out of the loop,
-* leaving it early runs the risk of corrupting GEM state (due
-* to running on almost untested codepaths). But on resume
-* timers don't work yet, so prevent a complete hang in that
-* case by choosing an insanely large timeout. */
- end = jiffies + 60 * HZ;
-
- ret = 0;
- do {
- if (intel_ring_space(ringbuf) = bytes)
- break;
-
- msleep(1);
-
- if (dev_priv-mm.interruptible signal_pending(current)) {
- ret = -ERESTARTSYS;
- break;
- }
-
- ret = i915_gem_check_wedge(dev_priv-gpu_error,
- dev_priv-mm.interruptible);
- if (ret)
- break;
-
- if (time_after(jiffies, end)) {
- ret = -EBUSY;
- break;
- }
- } while (1);
-
- return ret;
-}
-
static int logical_ring_wrap_buffer(struct intel_ringbuffer *ringbuf,
struct intel_context *ctx)
{
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c5752c4..6099fce 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2063,7 +2063,7 @@ void intel_cleanup_ring_buffer(struct intel_engine_cs
*ring)
ring-buffer = NULL;
}
-static int intel_ring_wait_request(struct intel_engine_cs *ring, int n)
+static int ring_wait_for_space(struct
[Intel-gfx] [PATCH 33/59] drm/i915: Update l3_remap to take a request structure
From: John Harrison john.c.harri...@intel.com
Converted i915_gem_l3_remap() to take a request structure instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c |5 +++--
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d50f41..839c185 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2746,7 +2746,7 @@ int __must_check i915_gem_object_finish_gpu(struct
drm_i915_gem_object *obj);
int __must_check i915_gem_init(struct drm_device *dev);
int i915_gem_init_rings(struct drm_device *dev);
int __must_check i915_gem_init_hw(struct drm_device *dev);
-int i915_gem_l3_remap(struct intel_engine_cs *ring, int slice);
+int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice);
void i915_gem_init_swizzling(struct drm_device *dev);
void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d8f4f3d..0e56658 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4699,8 +4699,9 @@ err:
return ret;
}
-int i915_gem_l3_remap(struct intel_engine_cs *ring, int slice)
+int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice)
{
+ struct intel_engine_cs *ring = req-ring;
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
u32 reg_base = GEN7_L3LOG_BASE + (slice * 0x200);
@@ -4922,7 +4923,7 @@ i915_gem_init_hw(struct drm_device *dev)
if (ring-id == RCS) {
for (i = 0; i NUM_L3_SLICES(dev); i++)
- i915_gem_l3_remap(ring, i);
+ i915_gem_l3_remap(req, i);
}
ret = i915_ppgtt_init_ring(req);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 815b691..4ae3a3d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -640,7 +640,7 @@ static int do_switch(struct drm_i915_gem_request *req)
if (!(to-remap_slice (1i)))
continue;
- ret = i915_gem_l3_remap(ring, i);
+ ret = i915_gem_l3_remap(req, i);
/* If it failed, try again next round */
if (ret)
DRM_DEBUG_DRIVER(L3 remapping failed\n);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 25/59] drm/i915: Update deferred context creation to do explicit request management
From: John Harrison john.c.harri...@intel.com
In execlist mode, context initialisation is deferred until first use of the
given context. This is because execlist mode has many more contexts than legacy
mode and many are never actually used. Previously, the initialisation commands
were written to the ring and tagged with some random request structure via the
OLR. This seemed to be causing a null pointer deference bug under certain
circumstances (BZ:88865).
This patch adds explicit request creation and submission to the deferred
initialisation code path. Thus removing any reliance on or randomness caused by
the OLR.
Note that it should be possible to move the deferred context creation until even
later - when the context is actually switched to rather than when it is merely
validated. This would allow the initialisation to be done within the request of
the work that is wanting to use the context. Hence, the extra request that is
created, used and retired just for the context init could be removed completely.
However, this is left for a follow up patch.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b430e51..c77a74b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1949,13 +1949,22 @@ int intel_lr_context_deferred_create(struct
intel_context *ctx,
lrc_setup_hardware_status_page(ring, ctx_obj);
else if (ring-id == RCS !ctx-rcs_initialized) {
if (ring-init_context) {
- ret = ring-init_context(ring, ctx);
+ struct drm_i915_gem_request *req;
+
+ ret = i915_gem_request_alloc(ring, ctx, req);
+ if (ret)
+ return ret;
+
+ ret = ring-init_context(req-ring, ctx);
if (ret) {
DRM_ERROR(ring init context: %d\n, ret);
+ i915_gem_request_cancel(req);
ctx-engine[ring-id].ringbuf = NULL;
ctx-engine[ring-id].state = NULL;
goto error;
}
+
+ i915_add_request_no_flush(req-ring);
}
ctx-rcs_initialized = true;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 30/59] drm/i915: Update queue_flip() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the display page flip code to do explicit request creation and
submission rather than relying on the OLR and just hoping that the request
actually gets submitted at some random point.
The sequence is now to create a request, queue the work to the ring, assign the
known request to the flip queue work item then actually submit the work and post
the request.
Note that every single flip function used to finish with
'__intel_ring_advance(ring);'. However, immediately after they return there is
now an add request call which will do the advance anyway. Thus the many
duplicate advance calls have been removed.
v2: Updated commit message with comment about advance removal.
v3: The request can now be allocated by the _sync() code earlier on. Thus the
page flip path does not necessarily need to allocate a new request, it may be
able to re-use one.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/intel_display.c| 33 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c |2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h |1 -
4 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 55d82a7..1fd59bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -574,7 +574,7 @@ struct drm_i915_display_funcs {
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj,
- struct intel_engine_cs *ring,
+ struct drm_i915_gem_request *req,
uint32_t flags);
void (*update_primary_plane)(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c71c523..c39cd34 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9418,9 +9418,10 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj,
-struct intel_engine_cs *ring,
+struct drm_i915_gem_request *req,
uint32_t flags)
{
+ struct intel_engine_cs *ring = req-ring;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
u32 flip_mask;
int ret;
@@ -9445,7 +9446,6 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
intel_ring_emit(ring, 0); /* aux display base address, unused */
intel_mark_page_flip_active(intel_crtc);
- __intel_ring_advance(ring);
return 0;
}
@@ -9453,9 +9453,10 @@ static int intel_gen3_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj,
-struct intel_engine_cs *ring,
+struct drm_i915_gem_request *req,
uint32_t flags)
{
+ struct intel_engine_cs *ring = req-ring;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
u32 flip_mask;
int ret;
@@ -9477,7 +9478,6 @@ static int intel_gen3_queue_flip(struct drm_device *dev,
intel_ring_emit(ring, MI_NOOP);
intel_mark_page_flip_active(intel_crtc);
- __intel_ring_advance(ring);
return 0;
}
@@ -9485,9 +9485,10 @@ static int intel_gen4_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj,
-struct intel_engine_cs *ring,
+struct drm_i915_gem_request *req,
uint32_t flags)
{
+ struct intel_engine_cs *ring = req-ring;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
uint32_t pf, pipesrc;
@@ -9516,7 +9517,6 @@ static int intel_gen4_queue_flip(struct drm_device *dev,
intel_ring_emit(ring, pf | pipesrc);
intel_mark_page_flip_active(intel_crtc);
- __intel_ring_advance(ring);
return 0;
}
@@ -9524,9 +9524,10 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_i915_gem_object
[Intel-gfx] [PATCH 47/59] drm/i915: Update ring-signal() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the various ring-signal() implementations to take a request instead of
a ring. This removes their reliance on the OLR to obtain the seqno value that
should be used for the signal.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2de43c8..10cb242 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1122,10 +1122,11 @@ static void render_ring_cleanup(struct intel_engine_cs
*ring)
intel_fini_pipe_control(ring);
}
-static int gen8_rcs_signal(struct intel_engine_cs *signaller,
+static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req,
unsigned int num_dwords)
{
#define MBOX_UPDATE_DWORDS 8
+ struct intel_engine_cs *signaller = signaller_req-ring;
struct drm_device *dev = signaller-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_engine_cs *waiter;
@@ -1145,8 +1146,7 @@ static int gen8_rcs_signal(struct intel_engine_cs
*signaller,
if (gtt_offset == MI_SEMAPHORE_SYNC_INVALID)
continue;
- seqno = i915_gem_request_get_seqno(
- signaller-outstanding_lazy_request);
+ seqno = i915_gem_request_get_seqno(signaller_req);
intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6));
intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB |
PIPE_CONTROL_QW_WRITE |
@@ -1163,10 +1163,11 @@ static int gen8_rcs_signal(struct intel_engine_cs
*signaller,
return 0;
}
-static int gen8_xcs_signal(struct intel_engine_cs *signaller,
+static int gen8_xcs_signal(struct drm_i915_gem_request *signaller_req,
unsigned int num_dwords)
{
#define MBOX_UPDATE_DWORDS 6
+ struct intel_engine_cs *signaller = signaller_req-ring;
struct drm_device *dev = signaller-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_engine_cs *waiter;
@@ -1186,8 +1187,7 @@ static int gen8_xcs_signal(struct intel_engine_cs
*signaller,
if (gtt_offset == MI_SEMAPHORE_SYNC_INVALID)
continue;
- seqno = i915_gem_request_get_seqno(
- signaller-outstanding_lazy_request);
+ seqno = i915_gem_request_get_seqno(signaller_req);
intel_ring_emit(signaller, (MI_FLUSH_DW + 1) |
MI_FLUSH_DW_OP_STOREDW);
intel_ring_emit(signaller, lower_32_bits(gtt_offset) |
@@ -1202,9 +1202,10 @@ static int gen8_xcs_signal(struct intel_engine_cs
*signaller,
return 0;
}
-static int gen6_signal(struct intel_engine_cs *signaller,
+static int gen6_signal(struct drm_i915_gem_request *signaller_req,
unsigned int num_dwords)
{
+ struct intel_engine_cs *signaller = signaller_req-ring;
struct drm_device *dev = signaller-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_engine_cs *useless;
@@ -1222,8 +1223,7 @@ static int gen6_signal(struct intel_engine_cs *signaller,
for_each_ring(useless, dev_priv, i) {
u32 mbox_reg = signaller-semaphore.mbox.signal[i];
if (mbox_reg != GEN6_NOSYNC) {
- u32 seqno = i915_gem_request_get_seqno(
- signaller-outstanding_lazy_request);
+ u32 seqno = i915_gem_request_get_seqno(signaller_req);
intel_ring_emit(signaller, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit(signaller, mbox_reg);
intel_ring_emit(signaller, seqno);
@@ -1252,7 +1252,7 @@ gen6_add_request(struct drm_i915_gem_request *req)
int ret;
if (ring-semaphore.signal)
- ret = ring-semaphore.signal(ring, 4);
+ ret = ring-semaphore.signal(req, 4);
else
ret = intel_ring_begin(ring, 4);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 1107f82..1af00b2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -225,7 +225,7 @@ struct intel_engine_cs {
int (*sync_to)(struct drm_i915_gem_request *to_req,
struct intel_engine_cs *from,
u32 seqno);
- int (*signal)(struct intel_engine_cs *signaller,
[Intel-gfx] [PATCH 43/59] drm/i915: Update ring-emit_request() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the ring-emit_request() implementation to take a request instead of a
ringbuf/request pair. Also removed it's use of the OLR for obtaining the
request's seqno.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c|7 +++
drivers/gpu/drm/i915/intel_ringbuffer.h |3 +--
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dd5c1d8..881c6ea 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2378,7 +2378,7 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
request-postfix = intel_ring_get_tail(ringbuf);
if (i915.enable_execlists)
- ret = ring-emit_request(ringbuf, request);
+ ret = ring-emit_request(request);
else
ret = ring-add_request(request);
/* Not allowed to fail! */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ba49f50..24a4816 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1294,9 +1294,9 @@ static void gen8_set_seqno(struct intel_engine_cs *ring,
u32 seqno)
intel_write_status_page(ring, I915_GEM_HWS_INDEX, seqno);
}
-static int gen8_emit_request(struct intel_ringbuffer *ringbuf,
-struct drm_i915_gem_request *request)
+static int gen8_emit_request(struct drm_i915_gem_request *request)
{
+ struct intel_ringbuffer *ringbuf = request-ringbuf;
struct intel_engine_cs *ring = ringbuf-ring;
u32 cmd;
int ret;
@@ -1313,8 +1313,7 @@ static int gen8_emit_request(struct intel_ringbuffer
*ringbuf,
(ring-status_page.gfx_addr +
(I915_GEM_HWS_INDEX
MI_STORE_DWORD_INDEX_SHIFT)));
intel_logical_ring_emit(ringbuf, 0);
- intel_logical_ring_emit(ringbuf,
- i915_gem_request_get_seqno(ring-outstanding_lazy_request));
+ intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
intel_logical_ring_emit(ringbuf, MI_NOOP);
intel_logical_ring_advance_and_submit(ringbuf, request-ctx, request);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 9641634..87f3b60 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -236,8 +236,7 @@ struct intel_engine_cs {
struct list_head execlist_retired_req_list;
u8 next_context_status_buffer;
u32 irq_keep_mask; /* bitmask for interrupts that should
not be masked */
- int (*emit_request)(struct intel_ringbuffer *ringbuf,
- struct drm_i915_gem_request *request);
+ int (*emit_request)(struct drm_i915_gem_request *request);
int (*emit_flush)(struct drm_i915_gem_request *request,
u32 invalidate_domains,
u32 flush_domains);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 46/59] drm/i915: Update ring-sync_to() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the ring-sync_to() implementations to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
drivers/gpu/drm/i915/i915_trace.h | 14 --
drivers/gpu/drm/i915/intel_ringbuffer.c |6 --
drivers/gpu/drm/i915/intel_ringbuffer.h |4 ++--
4 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 881c6ea..7304290 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3003,8 +3003,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (ret)
return ret;
- trace_i915_gem_ring_sync_to(from, to, obj-last_read_req);
- ret = to-semaphore.sync_to(to, from, seqno);
+ trace_i915_gem_ring_sync_to(*to_req, from, obj-last_read_req);
+ ret = to-semaphore.sync_to(*to_req, from, seqno);
if (!ret)
/* We use last_read_req because sync_to()
* might have just caused seqno wrap under
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index f044e29..8ca536c 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -326,29 +326,31 @@ TRACE_EVENT(i915_gem_evict_vm,
);
TRACE_EVENT(i915_gem_ring_sync_to,
- TP_PROTO(struct intel_engine_cs *from,
-struct intel_engine_cs *to,
+ TP_PROTO(struct drm_i915_gem_request *to_req,
+struct intel_engine_cs *from,
struct drm_i915_gem_request *req),
- TP_ARGS(from, to, req),
+ TP_ARGS(to_req, from, req),
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, sync_from)
__field(u32, sync_to)
+__field(u32, uniq_to)
__field(u32, seqno)
),
TP_fast_assign(
__entry-dev = from-dev-primary-index;
__entry-sync_from = from-id;
- __entry-sync_to = to-id;
+ __entry-sync_to = to_req-ring-id;
+ __entry-uniq_to = to_req-uniq;
__entry-seqno = i915_gem_request_get_seqno(req);
),
- TP_printk(dev=%u, sync-from=%u, sync-to=%u, seqno=%u,
+ TP_printk(dev=%u, sync-from=%u, sync-to=%u, seqno=%u, to_uniq=%u,
__entry-dev,
__entry-sync_from, __entry-sync_to,
- __entry-seqno)
+ __entry-seqno, __entry-uniq_to)
);
TRACE_EVENT(i915_gem_ring_dispatch,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 77d357f..2de43c8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1284,10 +1284,11 @@ static inline bool i915_gem_has_seqno_wrapped(struct
drm_device *dev,
*/
static int
-gen8_ring_sync(struct intel_engine_cs *waiter,
+gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
struct intel_engine_cs *signaller,
u32 seqno)
{
+ struct intel_engine_cs *waiter = waiter_req-ring;
struct drm_i915_private *dev_priv = waiter-dev-dev_private;
int ret;
@@ -1309,10 +1310,11 @@ gen8_ring_sync(struct intel_engine_cs *waiter,
}
static int
-gen6_ring_sync(struct intel_engine_cs *waiter,
+gen6_ring_sync(struct drm_i915_gem_request *waiter_req,
struct intel_engine_cs *signaller,
u32 seqno)
{
+ struct intel_engine_cs *waiter = waiter_req-ring;
u32 dw1 = MI_SEMAPHORE_MBOX |
MI_SEMAPHORE_COMPARE |
MI_SEMAPHORE_REGISTER;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2d1d8a6..1107f82 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -222,8 +222,8 @@ struct intel_engine_cs {
};
/* AKA wait() */
- int (*sync_to)(struct intel_engine_cs *ring,
- struct intel_engine_cs *to,
+ int (*sync_to)(struct drm_i915_gem_request *to_req,
+ struct intel_engine_cs *from,
u32 seqno);
int (*signal)(struct intel_engine_cs *signaller,
/* num_dwords needed by caller */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 16/59] drm/i915: Add flag to i915_add_request() to skip the cache flush
From: John Harrison john.c.harri...@intel.com
In order to explcitly track all GPU work (and completely remove the outstanding
lazy request), it is necessary to add extra i915_add_request() calls to various
places. Some of these do not need the implicit cache flush done as part of the
standard batch buffer submission process.
This patch adds a flag to _add_request() to specify whether the flush is
required or not.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |7 +--
drivers/gpu/drm/i915/i915_gem.c | 17 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/i915_gem_render_state.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
5 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d3b718e..4bcb43f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2751,9 +2751,12 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_suspend(struct drm_device *dev);
void __i915_add_request(struct intel_engine_cs *ring,
struct drm_file *file,
- struct drm_i915_gem_object *batch_obj);
+ struct drm_i915_gem_object *batch_obj,
+ bool flush_caches);
#define i915_add_request(ring) \
- __i915_add_request(ring, NULL, NULL)
+ __i915_add_request(ring, NULL, NULL, true)
+#define i915_add_request_no_flush(ring) \
+ __i915_add_request(ring, NULL, NULL, false)
int __i915_wait_request(struct drm_i915_gem_request *req,
unsigned reset_counter,
bool interruptible,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9a335d5..f143d15 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2329,7 +2329,8 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
*/
void __i915_add_request(struct intel_engine_cs *ring,
struct drm_file *file,
- struct drm_i915_gem_object *obj)
+ struct drm_i915_gem_object *obj,
+ bool flush_caches)
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *request;
@@ -2361,12 +2362,14 @@ void __i915_add_request(struct intel_engine_cs *ring,
* is that the flush _must_ happen before the next request, no matter
* what.
*/
- if (i915.enable_execlists)
- ret = logical_ring_flush_all_caches(ringbuf, request-ctx);
- else
- ret = intel_ring_flush_all_caches(ring);
- /* Not allowed to fail! */
- WARN_ON(ret);
+ if (flush_caches) {
+ if (i915.enable_execlists)
+ ret = logical_ring_flush_all_caches(ringbuf,
request-ctx);
+ else
+ ret = intel_ring_flush_all_caches(ring);
+ /* Not allowed to fail! */
+ WARN_ON(ret);
+ }
/* Record the position of the start of the request so that
* should we detect the updated seqno part-way through the
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3173550..c0be7d7 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1060,7 +1060,7 @@ i915_gem_execbuffer_retire_commands(struct
i915_execbuffer_params *params)
params-ring-gpu_caches_dirty = true;
/* Add a breadcrumb for the completion of the batch buffer */
- __i915_add_request(params-ring, params-file, params-batch_obj);
+ __i915_add_request(params-ring, params-file, params-batch_obj, true);
}
static int
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index ce4788f..4418616 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -173,7 +173,7 @@ int i915_gem_render_state_init(struct intel_engine_cs *ring)
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
- __i915_add_request(ring, NULL, so.obj);
+ __i915_add_request(ring, NULL, so.obj, true);
/* __i915_add_request moves object to inactive if it fails */
out:
i915_gem_render_state_fini(so);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8c69f88..4922725 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1350,7 +1350,7 @@ static int intel_lr_context_render_state_init(struct
intel_engine_cs *ring,
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
- __i915_add_request(ring, file, so.obj);
+
[Intel-gfx] [PATCH 18/59] drm/i915: Split i915_ppgtt_init_hw() in half - generic and per ring
From: John Harrison john.c.harri...@intel.com
The i915_gem_init_hw() function calls a bunch of smaller initialisation
functions. Multiple of which have generic sections and per ring sections. This
means multiple passes are done over the rings. Each pass writes data to the ring
which floats around in that ring's OLR until some random point in the future
when an add_request() is done by some random other piece of code.
This patch breaks i915_ppgtt_init_hw() in two with the per ring initialisation
now being done in i915_ppgtt_init_ring(). The ring looping is now done at the
top level in i915_gem_init_hw().
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 25 +++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +++-
drivers/gpu/drm/i915/i915_gem_gtt.h |1 +
3 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8677293..683fc80 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4883,19 +4883,32 @@ i915_gem_init_hw(struct drm_device *dev)
*/
init_unused_rings(dev);
+ ret = i915_ppgtt_init_hw(dev);
+ if (ret) {
+ DRM_ERROR(PPGTT enable HW failed %d\n, ret);
+ goto out;
+ }
+
+ /* Need to do basic initialisation of all rings first: */
for_each_ring(ring, dev_priv, i) {
ret = ring-init_hw(ring);
if (ret)
goto out;
}
- for (i = 0; i NUM_L3_SLICES(dev); i++)
- i915_gem_l3_remap(dev_priv-ring[RCS], i);
+ /* Now it is safe to go back round and do everything else: */
+ for_each_ring(ring, dev_priv, i) {
+ if (ring-id == RCS) {
+ for (i = 0; i NUM_L3_SLICES(dev); i++)
+ i915_gem_l3_remap(ring, i);
+ }
- ret = i915_ppgtt_init_hw(dev);
- if (ret ret != -EIO) {
- DRM_ERROR(PPGTT enable failed %d\n, ret);
- i915_gem_cleanup_ringbuffer(dev);
+ ret = i915_ppgtt_init_ring(ring);
+ if (ret ret != -EIO) {
+ DRM_ERROR(PPGTT enable ring #%d failed %d\n, i, ret);
+ i915_gem_cleanup_ringbuffer(dev);
+ goto out;
+ }
}
ret = i915_gem_context_enable(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d8ff1a8..83076d7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1280,11 +1280,6 @@ int i915_ppgtt_init(struct drm_device *dev, struct
i915_hw_ppgtt *ppgtt)
int i915_ppgtt_init_hw(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_engine_cs *ring;
- struct i915_hw_ppgtt *ppgtt = dev_priv-mm.aliasing_ppgtt;
- int i, ret = 0;
-
/* In the case of execlists, PPGTT is enabled by the context descriptor
* and the PDPs are contained within the context itself. We don't
* need to do anything here. */
@@ -1303,16 +1298,23 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else
MISSING_CASE(INTEL_INFO(dev)-gen);
- if (ppgtt) {
- for_each_ring(ring, dev_priv, i) {
- ret = ppgtt-switch_mm(ppgtt, ring);
- if (ret != 0)
- return ret;
- }
- }
+ return 0;
+}
- return ret;
+int i915_ppgtt_init_ring(struct intel_engine_cs *ring)
+{
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
+ struct i915_hw_ppgtt *ppgtt = dev_priv-mm.aliasing_ppgtt;
+
+ if (i915.enable_execlists)
+ return 0;
+
+ if (!ppgtt)
+ return 0;
+
+ return ppgtt-switch_mm(ppgtt, ring);
}
+
struct i915_hw_ppgtt *
i915_ppgtt_create(struct drm_device *dev, struct drm_i915_file_private *fpriv)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c9e93f5..2941fbb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -311,6 +311,7 @@ void i915_global_gtt_cleanup(struct drm_device *dev);
int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt);
int i915_ppgtt_init_hw(struct drm_device *dev);
+int i915_ppgtt_init_ring(struct intel_engine_cs *ring);
void i915_ppgtt_release(struct kref *kref);
struct i915_hw_ppgtt *i915_ppgtt_create(struct drm_device *dev,
struct drm_i915_file_private *fpriv);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/59] drm/i915: Don't tag kernel batches as user batches
From: John Harrison john.c.harri...@intel.com The render state initialisation code does an explicit i915_add_request() call to commit the init commands. It was passing in the initialisation batch buffer to add_request() as the batch object parameter. However, the batch object entry in the request structure (which is all that parameter is used for) is meant for keeping track of user generated batch buffers for blame tagging during GPU hangs. This patch clears the batch object parameter so that kernel generated batch buffers are not tagged as being user generated. For: VIZ-5115 Signed-off-by: John Harrison john.c.harri...@intel.com --- drivers/gpu/drm/i915/i915_gem_render_state.c |2 +- drivers/gpu/drm/i915/intel_lrc.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c b/drivers/gpu/drm/i915/i915_gem_render_state.c index 4418616..a32a4b9 100644 --- a/drivers/gpu/drm/i915/i915_gem_render_state.c +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c @@ -173,7 +173,7 @@ int i915_gem_render_state_init(struct intel_engine_cs *ring) i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring); - __i915_add_request(ring, NULL, so.obj, true); + __i915_add_request(ring, NULL, NULL, true); /* __i915_add_request moves object to inactive if it fails */ out: i915_gem_render_state_fini(so); diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 4922725..f24ab0c 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1350,7 +1350,7 @@ static int intel_lr_context_render_state_init(struct intel_engine_cs *ring, i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring); - __i915_add_request(ring, file, so.obj, true); + __i915_add_request(ring, file, NULL, true); /* intel_logical_ring_add_request moves object to inactive if it * fails */ out: -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 32/59] drm/i915: Update [vma|object]_move_to_active() to take request structures
From: John Harrison john.c.harri...@intel.com
Now that everything above has been converted to use request structures, it is
possible to update the lower level move_to_active() functions to be request
based as well.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c | 17 -
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/i915_gem_render_state.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
6 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7e0a095..3d50f41 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2668,7 +2668,7 @@ int i915_gem_object_sync(struct drm_i915_gem_object *obj,
struct intel_engine_cs *to,
struct drm_i915_gem_request **to_req);
void i915_vma_move_to_active(struct i915_vma *vma,
-struct intel_engine_cs *ring);
+struct drm_i915_gem_request *req);
int i915_gem_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9f615bf..d8f4f3d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2180,17 +2180,16 @@ i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
static void
i915_gem_object_move_to_active(struct drm_i915_gem_object *obj,
- struct intel_engine_cs *ring)
+ struct drm_i915_gem_request *req)
{
- struct drm_i915_gem_request *req;
- struct intel_engine_cs *old_ring;
+ struct intel_engine_cs *new_ring, *old_ring;
- BUG_ON(ring == NULL);
+ BUG_ON(req == NULL);
- req = intel_ring_get_request(ring);
+ new_ring = i915_gem_request_get_ring(req);
old_ring = i915_gem_request_get_ring(obj-last_read_req);
- if (old_ring != ring obj-last_write_req) {
+ if (old_ring != new_ring obj-last_write_req) {
/* Keep the request relative to the current ring */
i915_gem_request_assign(obj-last_write_req, req);
}
@@ -2201,16 +2200,16 @@ i915_gem_object_move_to_active(struct
drm_i915_gem_object *obj,
obj-active = 1;
}
- list_move_tail(obj-ring_list, ring-active_list);
+ list_move_tail(obj-ring_list, new_ring-active_list);
i915_gem_request_assign(obj-last_read_req, req);
}
void i915_vma_move_to_active(struct i915_vma *vma,
-struct intel_engine_cs *ring)
+struct drm_i915_gem_request *req)
{
list_move_tail(vma-mm_list, vma-vm-active_list);
- return i915_gem_object_move_to_active(vma-obj, ring);
+ return i915_gem_object_move_to_active(vma-obj, req);
}
static void
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 75b9d78..815b691 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -656,7 +656,7 @@ static int do_switch(struct drm_i915_gem_request *req)
*/
if (from != NULL) {
from-legacy_hw_ctx.rcs_state-base.read_domains =
I915_GEM_DOMAIN_INSTRUCTION;
-
i915_vma_move_to_active(i915_gem_obj_to_ggtt(from-legacy_hw_ctx.rcs_state),
ring);
+
i915_vma_move_to_active(i915_gem_obj_to_ggtt(from-legacy_hw_ctx.rcs_state),
req);
/* As long as MI_SET_CONTEXT is serializing, ie. it flushes the
* whole damn pipeline, we don't need to explicitly mark the
* object dirty. The only exception is that the context must be
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index af4718d..fac5966 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1030,7 +1030,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas,
obj-base.pending_read_domains |=
obj-base.read_domains;
obj-base.read_domains = obj-base.pending_read_domains;
- i915_vma_move_to_active(vma, ring);
+ i915_vma_move_to_active(vma, req);
if (obj-base.write_domain) {
obj-dirty = 1;
i915_gem_request_assign(obj-last_write_req, req);
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 6598f9b..e04cda4 100644
---
[Intel-gfx] [PATCH 56/59] drm/i915: Remove 'faked' request from LRC submission
From: John Harrison john.c.harri...@intel.com
The LRC submission code requires a request for tracking purposes. It does not
actually require that request to 'complete' it simply uses it for keeping hold
of reference counts on contexts and such like.
Previously, the fall back path of polling for space in the ring would start by
submitting any outstanding work that was sat in the buffer. This submission was
not done as part of the request that that work was owned by because that would
lead to complications with the request being submitted twice. Instead, a null
request structure was passed in to the submit call and a fake one was created.
That fall back path has long since been obsoleted and has now been removed. Thus
there is never any need to fake up a request structure. This patch removes that
code. A couple of sanity check warnings are added as well, just in case.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f21f449..82190ad 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -507,23 +507,11 @@ static int execlists_context_queue(struct intel_engine_cs
*ring,
if (to != ring-default_context)
intel_lr_context_pin(ring, to);
- if (!request) {
- /*
-* If there isn't a request associated with this submission,
-* create one as a temporary holder.
-*/
- request = kzalloc(sizeof(*request), GFP_KERNEL);
- if (request == NULL)
- return -ENOMEM;
- request-ring = ring;
- request-ctx = to;
- kref_init(request-ref);
- request-uniq = dev_priv-request_uniq++;
- i915_gem_context_reference(request-ctx);
- } else {
- i915_gem_request_reference(request);
- WARN_ON(to != request-ctx);
- }
+ WARN_ON(!request);
+ WARN_ON(to != request-ctx);
+
+ i915_gem_request_reference(request);
+
request-tail = tail;
intel_runtime_pm_get(dev_priv);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 35/59] drm/i915: Update a bunch of execbuffer helpers to take request structures
From: John Harrison john.c.harri...@intel.com
Updated *_ring_invalidate_all_caches(), i915_reset_gen7_sol_offsets() and
i915_emit_box() to take request structures instead of ring or ringbuf/context
pairs.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 +++-
drivers/gpu/drm/i915/intel_lrc.c |9 -
drivers/gpu/drm/i915/intel_ringbuffer.c|3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h|2 +-
4 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index fac5966..e58e88b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -921,7 +921,7 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request
*req,
/* Unconditionally invalidate gpu caches and ensure that we do flush
* any residual writes from the previous batch.
*/
- return intel_ring_invalidate_all_caches(req-ring);
+ return intel_ring_invalidate_all_caches(req);
}
static bool
@@ -1065,8 +1065,9 @@ i915_gem_execbuffer_retire_commands(struct
i915_execbuffer_params *params)
static int
i915_reset_gen7_sol_offsets(struct drm_device *dev,
- struct intel_engine_cs *ring)
+ struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
struct drm_i915_private *dev_priv = dev-dev_private;
int ret, i;
@@ -1091,10 +1092,11 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
}
static int
-i915_emit_box(struct intel_engine_cs *ring,
+i915_emit_box(struct drm_i915_gem_request *req,
struct drm_clip_rect *box,
int DR1, int DR4)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
if (box-y2 = box-y1 || box-x2 = box-x1 ||
@@ -1299,7 +1301,7 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
}
if (args-flags I915_EXEC_GEN7_SOL_RESET) {
- ret = i915_reset_gen7_sol_offsets(params-dev, ring);
+ ret = i915_reset_gen7_sol_offsets(params-dev, params-request);
if (ret)
goto error;
}
@@ -1310,7 +1312,7 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
if (cliprects) {
for (i = 0; i args-num_cliprects; i++) {
- ret = i915_emit_box(ring, cliprects[i],
+ ret = i915_emit_box(params-request, cliprects[i],
args-DR1, args-DR4);
if (ret)
goto error;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5481514..917a76c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -559,10 +559,9 @@ static int execlists_context_queue(struct intel_engine_cs
*ring,
return 0;
}
-static int logical_ring_invalidate_all_caches(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx)
+static int logical_ring_invalidate_all_caches(struct drm_i915_gem_request *req)
{
- struct intel_engine_cs *ring = ringbuf-ring;
+ struct intel_engine_cs *ring = req-ring;
uint32_t flush_domains;
int ret;
@@ -570,7 +569,7 @@ static int logical_ring_invalidate_all_caches(struct
intel_ringbuffer *ringbuf,
if (ring-gpu_caches_dirty)
flush_domains = I915_GEM_GPU_DOMAINS;
- ret = ring-emit_flush(ringbuf, ctx,
+ ret = ring-emit_flush(req-ringbuf, req-ctx,
I915_GEM_GPU_DOMAINS, flush_domains);
if (ret)
return ret;
@@ -606,7 +605,7 @@ static int execlists_move_to_gpu(struct
drm_i915_gem_request *req,
/* Unconditionally invalidate gpu caches and ensure that we do flush
* any residual writes from the previous batch.
*/
- return logical_ring_invalidate_all_caches(req-ringbuf, req-ctx);
+ return logical_ring_invalidate_all_caches(req);
}
int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index dba1d88..84885f2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2889,8 +2889,9 @@ intel_ring_flush_all_caches(struct intel_engine_cs *ring)
}
int
-intel_ring_invalidate_all_caches(struct intel_engine_cs *ring)
+intel_ring_invalidate_all_caches(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
uint32_t flush_domains;
int ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
[Intel-gfx] [PATCH 27/59] drm/i915: Update render_state_init() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the two render_state_init() functions to take a request pointer instead
of a ring. This removes their reliance on the OLR.
v2: Rebased to newer tree.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_render_state.h |2 +-
drivers/gpu/drm/i915/intel_lrc.c | 18 --
drivers/gpu/drm/i915/intel_ringbuffer.c |2 +-
4 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index a07b4ee..6598f9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -152,26 +152,26 @@ int i915_gem_render_state_prepare(struct intel_engine_cs
*ring,
return 0;
}
-int i915_gem_render_state_init(struct intel_engine_cs *ring)
+int i915_gem_render_state_init(struct drm_i915_gem_request *req)
{
struct render_state so;
int ret;
- ret = i915_gem_render_state_prepare(ring, so);
+ ret = i915_gem_render_state_prepare(req-ring, so);
if (ret)
return ret;
if (so.rodata == NULL)
return 0;
- ret = ring-dispatch_execbuffer(ring,
- so.ggtt_offset,
- so.rodata-batch_items * 4,
- I915_DISPATCH_SECURE);
+ ret = req-ring-dispatch_execbuffer(req-ring,
+so.ggtt_offset,
+so.rodata-batch_items * 4,
+I915_DISPATCH_SECURE);
if (ret)
goto out;
- i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
+ i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), req-ring);
out:
i915_gem_render_state_fini(so);
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.h
b/drivers/gpu/drm/i915/i915_gem_render_state.h
index c44961e..7aa7372 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.h
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.h
@@ -39,7 +39,7 @@ struct render_state {
int gen;
};
-int i915_gem_render_state_init(struct intel_engine_cs *ring);
+int i915_gem_render_state_init(struct drm_i915_gem_request *req);
void i915_gem_render_state_fini(struct render_state *so);
int i915_gem_render_state_prepare(struct intel_engine_cs *ring,
struct render_state *so);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 46df37c..0480ad4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1325,28 +1325,26 @@ static int gen8_emit_request(struct intel_ringbuffer
*ringbuf,
return 0;
}
-static int intel_lr_context_render_state_init(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+static int intel_lr_context_render_state_init(struct drm_i915_gem_request *req)
{
- struct intel_ringbuffer *ringbuf = ctx-engine[ring-id].ringbuf;
struct render_state so;
int ret;
- ret = i915_gem_render_state_prepare(ring, so);
+ ret = i915_gem_render_state_prepare(req-ring, so);
if (ret)
return ret;
if (so.rodata == NULL)
return 0;
- ret = ring-emit_bb_start(ringbuf,
- ctx,
- so.ggtt_offset,
- I915_DISPATCH_SECURE);
+ ret = req-ring-emit_bb_start(req-ringbuf,
+ req-ctx,
+ so.ggtt_offset,
+ I915_DISPATCH_SECURE);
if (ret)
goto out;
- i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
+ i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), req-ring);
out:
i915_gem_render_state_fini(so);
@@ -1361,7 +1359,7 @@ static int gen8_init_rcs_context(struct
drm_i915_gem_request *req)
if (ret)
return ret;
- return intel_lr_context_render_state_init(req-ring, req-ctx);
+ return intel_lr_context_render_state_init(req);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index f36d00d..291920e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -750,7 +750,7 @@ static int intel_rcs_ctx_init(struct drm_i915_gem_request
*req)
if (ret != 0)
return ret;
- ret = i915_gem_render_state_init(req-ring);
+ ret = i915_gem_render_state_init(req);
if (ret)
DRM_ERROR(init render state: %d\n, ret);
[Intel-gfx] [PATCH 28/59] drm/i915: Update i915_gem_object_sync() to take a request structure
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
v2: Much more complex patch to share a single request between the sync and the
page flip. The _sync() function now supports lazy allocation of the request
structure. That is, if one is passed in then that will be used. If one is not,
then a request will be allocated and passed back out. Note that the _sync() code
does not necessarily require a request. Thus one will only be created until
certain situations. The reason the lazy allocation must be done within the
_sync() code itself is because the decision to need one or not is not really
something that code above can second guess (except in the case where one is
definitely not required because no ring is passed in).
The call chains above _sync() now support passing a request through which most
callers passing in NULL and assuming that no request will be required (because
they also pass in NULL for the ring and therefore can't be generating any ring
code).
The exeception is intel_crtc_page_flip() which now supports having a request
returned from _sync(). If one is, then that request is shared by the page flip
(if the page flip is of a type to need a request). If _sync() does not generate
a request but the page flip does need one, then the page flip path will create
it's own request.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|6 --
drivers/gpu/drm/i915/i915_gem.c| 19 ---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/intel_display.c | 17 -
drivers/gpu/drm/i915/intel_drv.h |3 ++-
drivers/gpu/drm/i915/intel_fbdev.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
drivers/gpu/drm/i915/intel_overlay.c |2 +-
8 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca070d3..55d82a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2665,7 +2665,8 @@ static inline void i915_gem_object_unpin_pages(struct
drm_i915_gem_object *obj)
int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
int i915_gem_object_sync(struct drm_i915_gem_object *obj,
-struct intel_engine_cs *to);
+struct intel_engine_cs *to,
+struct drm_i915_gem_request **to_req);
void i915_vma_move_to_active(struct i915_vma *vma,
struct intel_engine_cs *ring);
int i915_gem_dumb_create(struct drm_file *file_priv,
@@ -2773,7 +2774,8 @@ i915_gem_object_set_to_cpu_domain(struct
drm_i915_gem_object *obj, bool write);
int __must_check
i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
u32 alignment,
-struct intel_engine_cs *pipelined);
+struct intel_engine_cs *pipelined,
+struct drm_i915_gem_request
**pipelined_request);
void i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj);
int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
int align);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0a25461..9114071 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2957,6 +2957,9 @@ out:
*
* @obj: object which may be in use on another ring.
* @to: ring we wish to use the object on. May be NULL.
+ * @to_req: request we wish to use the object for. May be NULL.
+ * This will be allocated and returned if a request is
+ * required but not passed in.
*
* This code is meant to abstract object synchronization with the GPU.
* Calling with NULL implies synchronizing the object with the CPU
@@ -2966,7 +2969,8 @@ out:
*/
int
i915_gem_object_sync(struct drm_i915_gem_object *obj,
-struct intel_engine_cs *to)
+struct intel_engine_cs *to,
+struct drm_i915_gem_request **to_req)
{
struct intel_engine_cs *from;
u32 seqno;
@@ -2980,6 +2984,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (to == NULL || !i915_semaphore_is_enabled(obj-base.dev))
return i915_gem_object_wait_rendering(obj, false);
+ WARN_ON(!to_req);
+
idx = intel_ring_sync_index(from, to);
seqno = i915_gem_request_get_seqno(obj-last_read_req);
@@ -2988,6 +2994,12 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (seqno = from-semaphore.sync_seqno[idx])
return 0;
+ if (*to_req == NULL) {
+
[Intel-gfx] [PATCH 36/59] drm/i915: Update workarounds_emit() to take request structures
From: John Harrison john.c.harri...@intel.com
Updated the *_ring_workarounds_emit() functions to take requests instead of
ring/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 917a76c..b2f03b9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1056,11 +1056,11 @@ void intel_lr_context_unpin(struct intel_engine_cs
*ring,
}
}
-static int intel_logical_ring_workarounds_emit(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+static int intel_logical_ring_workarounds_emit(struct drm_i915_gem_request
*req)
{
int ret, i;
- struct intel_ringbuffer *ringbuf = ctx-engine[ring-id].ringbuf;
+ struct intel_engine_cs *ring = req-ring;
+ struct intel_ringbuffer *ringbuf = req-ringbuf;
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct i915_workarounds *w = dev_priv-workarounds;
@@ -1069,11 +1069,11 @@ static int intel_logical_ring_workarounds_emit(struct
intel_engine_cs *ring,
return 0;
ring-gpu_caches_dirty = true;
- ret = logical_ring_flush_all_caches(ringbuf, ctx);
+ ret = logical_ring_flush_all_caches(ringbuf, req-ctx);
if (ret)
return ret;
- ret = intel_logical_ring_begin(ringbuf, ctx, w-count * 2 + 2);
+ ret = intel_logical_ring_begin(ringbuf, req-ctx, w-count * 2 + 2);
if (ret)
return ret;
@@ -1087,7 +1087,7 @@ static int intel_logical_ring_workarounds_emit(struct
intel_engine_cs *ring,
intel_logical_ring_advance(ringbuf);
ring-gpu_caches_dirty = true;
- ret = logical_ring_flush_all_caches(ringbuf, ctx);
+ ret = logical_ring_flush_all_caches(ringbuf, req-ctx);
if (ret)
return ret;
@@ -1354,7 +1354,7 @@ static int gen8_init_rcs_context(struct
drm_i915_gem_request *req)
{
int ret;
- ret = intel_logical_ring_workarounds_emit(req-ring, req-ctx);
+ ret = intel_logical_ring_workarounds_emit(req);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 84885f2..2c4f45c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -703,10 +703,10 @@ err:
return ret;
}
-static int intel_ring_workarounds_emit(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+static int intel_ring_workarounds_emit(struct drm_i915_gem_request *req)
{
int ret, i;
+ struct intel_engine_cs *ring = req-ring;
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct i915_workarounds *w = dev_priv-workarounds;
@@ -746,7 +746,7 @@ static int intel_rcs_ctx_init(struct drm_i915_gem_request
*req)
{
int ret;
- ret = intel_ring_workarounds_emit(req-ring, req-ctx);
+ ret = intel_ring_workarounds_emit(req);
if (ret != 0)
return ret;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 59/59] drm/i915: Remove the almost obsolete i915_gem_object_flush_active()
From: John Harrison john.c.harri...@intel.com
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less. Now all it does call i915_gem_retire_requests_ring(). Hence it is
pretty much redundant as the two callers could just call retire directly. This
patch makes that change.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 43 +++
1 file changed, 12 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index acb824c..aef4748 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2825,25 +2825,6 @@ i915_gem_idle_work_handler(struct work_struct *work)
}
/**
- * Ensures that an object will eventually get non-busy by flushing any required
- * write domains, emitting any outstanding lazy request and retiring and
- * completed requests.
- */
-static int
-i915_gem_object_flush_active(struct drm_i915_gem_object *obj)
-{
- struct intel_engine_cs *ring;
-
- if (obj-active) {
- ring = i915_gem_request_get_ring(obj-last_read_req);
-
- i915_gem_retire_requests_ring(ring);
- }
-
- return 0;
-}
-
-/**
* i915_gem_wait_ioctl - implements DRM_IOCTL_I915_GEM_WAIT
* @DRM_IOCTL_ARGS: standard ioctl arguments
*
@@ -2888,10 +2869,12 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
return -ENOENT;
}
- /* Need to make sure the object gets inactive eventually. */
- ret = i915_gem_object_flush_active(obj);
- if (ret)
- goto out;
+ /* Make sure the object is not pending cleanup. */
+ if (obj-last_read_req) {
+ struct intel_engine_cs *ring;
+ ring = i915_gem_request_get_ring(obj-last_read_req);
+ i915_gem_retire_requests_ring(ring);
+ }
if (!obj-active || !obj-last_read_req)
goto out;
@@ -4335,19 +4318,17 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
goto unlock;
}
- /* Count all active objects as busy, even if they are currently not used
-* by the gpu. Users of this interface expect objects to eventually
-* become non-busy without any further actions, therefore emit any
-* necessary flushes here.
-*/
- ret = i915_gem_object_flush_active(obj);
-
args-busy = obj-active;
if (obj-last_read_req) {
struct intel_engine_cs *ring;
BUILD_BUG_ON(I915_NUM_RINGS 16);
ring = i915_gem_request_get_ring(obj-last_read_req);
- args-busy |= intel_ring_flag(ring) 16;
+
+ /* Check that the object wasn't simply pending cleanup */
+ i915_gem_retire_requests_ring(ring);
+
+ if (obj-last_read_req)
+ args-busy |= intel_ring_flag(ring) 16;
}
drm_gem_object_unreference(obj-base);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 50/59] drm/i915: Update intel_logical_ring_begin() to take a request structure
From: John Harrison john.c.harri...@intel.com
Now that everything above has been converted to use requests,
intel_logical_ring_begin() can be updated to take a request instead of a
ringbuf/context pair. This also means that it no longer needs to lazily allocate
a request if no-one happens to have done it earlier.
Note that this change makes the execlist signature the same as the legacy
version. Thus the two functions could be merged into a ring-begin() wrapper if
required.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cdbe514..c16d726 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -796,7 +796,7 @@ static int logical_ring_prepare(struct intel_ringbuffer
*ringbuf,
/**
* intel_logical_ring_begin() - prepare the logical ringbuffer to accept some
commands
*
- * @ringbuf: Logical ringbuffer.
+ * @request: The request to start some new work for
* @num_dwords: number of DWORDs that we plan to write to the ringbuffer.
*
* The ringbuffer might not be ready to accept the commands right away (maybe
it needs to
@@ -806,30 +806,26 @@ static int logical_ring_prepare(struct intel_ringbuffer
*ringbuf,
*
* Return: non-zero if the ringbuffer is not ready to be written to.
*/
-static int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx, int num_dwords)
+static int intel_logical_ring_begin(struct drm_i915_gem_request *req,
+ int num_dwords)
{
- struct drm_i915_gem_request *req;
- struct intel_engine_cs *ring = ringbuf-ring;
- struct drm_device *dev = ring-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_private *dev_priv;
int ret;
+ WARN_ON(req == NULL);
+ dev_priv = req-ring-dev-dev_private;
+
ret = i915_gem_check_wedge(dev_priv-gpu_error,
dev_priv-mm.interruptible);
if (ret)
return ret;
- ret = logical_ring_prepare(ringbuf, ctx, num_dwords * sizeof(uint32_t));
- if (ret)
- return ret;
-
- /* Preallocate the olr before touching the ring */
- ret = i915_gem_request_alloc(ring, ctx, req);
+ ret = logical_ring_prepare(req-ringbuf, req-ctx,
+ num_dwords * sizeof(uint32_t));
if (ret)
return ret;
- ringbuf-space -= num_dwords * sizeof(uint32_t);
+ req-ringbuf-space -= num_dwords * sizeof(uint32_t);
return 0;
}
@@ -915,7 +911,7 @@ int intel_execlists_submission(struct
i915_execbuffer_params *params,
if (ring == dev_priv-ring[RCS]
instp_mode != dev_priv-relative_constants_mode) {
- ret = intel_logical_ring_begin(ringbuf, params-ctx, 4);
+ ret = intel_logical_ring_begin(params-request, 4);
if (ret)
return ret;
@@ -1071,7 +1067,7 @@ static int intel_logical_ring_workarounds_emit(struct
drm_i915_gem_request *req)
if (ret)
return ret;
- ret = intel_logical_ring_begin(ringbuf, req-ctx, w-count * 2 + 2);
+ ret = intel_logical_ring_begin(req, w-count * 2 + 2);
if (ret)
return ret;
@@ -1153,7 +1149,7 @@ static int gen8_emit_bb_start(struct drm_i915_gem_request
*req,
bool ppgtt = !(dispatch_flags I915_DISPATCH_SECURE);
int ret;
- ret = intel_logical_ring_begin(ringbuf, req-ctx, 4);
+ ret = intel_logical_ring_begin(req, 4);
if (ret)
return ret;
@@ -1211,7 +1207,7 @@ static int gen8_emit_flush(struct drm_i915_gem_request
*request,
uint32_t cmd;
int ret;
- ret = intel_logical_ring_begin(ringbuf, request-ctx, 4);
+ ret = intel_logical_ring_begin(request, 4);
if (ret)
return ret;
@@ -1269,7 +1265,7 @@ static int gen8_emit_flush_render(struct
drm_i915_gem_request *request,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
}
- ret = intel_logical_ring_begin(ringbuf, request-ctx, 6);
+ ret = intel_logical_ring_begin(request, 6);
if (ret)
return ret;
@@ -1301,7 +1297,7 @@ static int gen8_emit_request(struct drm_i915_gem_request
*request)
u32 cmd;
int ret;
- ret = intel_logical_ring_begin(ringbuf, request-ctx, 6);
+ ret = intel_logical_ring_begin(request, 6);
if (ret)
return ret;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 38/59] drm/i915: Update switch_mm() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the switch_mm() code paths to take a request instead of a ring. This
includes the myriad *_mm_switch functions themselves and a bunch of PDP related
helper functions.
v2: Rebased to newer tree.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ++-
drivers/gpu/drm/i915/i915_gem_gtt.h |2 +-
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f615fca..35116d3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -595,7 +595,7 @@ static int do_switch(struct drm_i915_gem_request *req)
if (to-ppgtt) {
trace_switch_mm(ring, to);
- ret = to-ppgtt-switch_mm(to-ppgtt, ring);
+ ret = to-ppgtt-switch_mm(to-ppgtt, req);
if (ret)
goto unpin_out;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac63572..96fd8e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -374,9 +374,10 @@ static struct i915_page_directory_entry
*alloc_pd_single(void)
}
/* Broadwell Page Directory Pointer Descriptors */
-static int gen8_write_pdp(struct intel_engine_cs *ring, unsigned entry,
- uint64_t val)
+static int gen8_write_pdp(struct drm_i915_gem_request *req, unsigned entry,
+ uint64_t val)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
BUG_ON(entry = 4);
@@ -397,7 +398,7 @@ static int gen8_write_pdp(struct intel_engine_cs *ring,
unsigned entry,
}
static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct intel_engine_cs *ring)
+ struct drm_i915_gem_request *req)
{
int i, ret;
@@ -406,7 +407,7 @@ static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
for (i = used_pd - 1; i = 0; i--) {
dma_addr_t addr = ppgtt-pdp.page_directory[i]-daddr;
- ret = gen8_write_pdp(ring, i, addr);
+ ret = gen8_write_pdp(req, i, addr);
if (ret)
return ret;
}
@@ -878,8 +879,9 @@ static uint32_t get_pd_offset(struct i915_hw_ppgtt *ppgtt)
}
static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
-struct intel_engine_cs *ring)
+struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
/* NB: TLBs must be flushed and invalidated before a switch */
@@ -903,8 +905,9 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
}
static int vgpu_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct intel_engine_cs *ring)
+ struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
struct drm_i915_private *dev_priv = to_i915(ppgtt-base.dev);
I915_WRITE(RING_PP_DIR_DCLV(ring), PP_DIR_DCLV_2G);
@@ -913,8 +916,9 @@ static int vgpu_mm_switch(struct i915_hw_ppgtt *ppgtt,
}
static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct intel_engine_cs *ring)
+ struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
/* NB: TLBs must be flushed and invalidated before a switch */
@@ -945,8 +949,9 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
}
static int gen6_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct intel_engine_cs *ring)
+ struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
struct drm_device *dev = ppgtt-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1312,7 +1317,7 @@ int i915_ppgtt_init_ring(struct drm_i915_gem_request *req)
if (!ppgtt)
return 0;
- return ppgtt-switch_mm(ppgtt, req-ring);
+ return ppgtt-switch_mm(ppgtt, req);
}
struct i915_hw_ppgtt *
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index d4c7184..8490ff5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -300,7 +300,7 @@ struct i915_hw_ppgtt {
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
-struct intel_engine_cs *ring);
+struct drm_i915_gem_request *req);
void (*debug_dump)(struct i915_hw_ppgtt *ppgtt, struct seq_file *m);
};
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 08/59] drm/i915: Set context in request from creation even in legacy mode
From: John Harrison john.c.harri...@intel.com
In execlist mode, the context object pointer is written in to the request
structure (and reference counted) at the point of request creation. In legacy
mode, this only happens inside i915_add_request().
This patch updates the legacy code path to match the execlist version. This
allows all the intermediate code between request creation and request submission
to get at the context object given only a request structure. Thus negating the
need to pass context pointers here, there and everywhere.
v2: Moved the context reference so it does not need to be undone if the
get_seqno() fails.
v3: Fixed execlist mode always hitting a warning about invalid last_contexts
(which don't exist in execlist mode).
v4: Updated for new i915_gem_request_alloc() scheme.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 14 +-
drivers/gpu/drm/i915/intel_lrc.c | 11 ---
drivers/gpu/drm/i915/intel_lrc.h |3 +--
3 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cdf1c9d..f35ac7f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2393,14 +2393,7 @@ void __i915_add_request(struct intel_engine_cs *ring,
*/
request-batch_obj = obj;
- if (!i915.enable_execlists) {
- /* Hold a reference to the current context so that we can
inspect
-* it later in case a hangcheck error event fires.
-*/
- request-ctx = ring-last_context;
- if (request-ctx)
- i915_gem_context_reference(request-ctx);
- }
+ WARN_ON(!i915.enable_execlists (request-ctx != ring-last_context));
request-emitted_jiffies = jiffies;
list_add_tail(request-list, ring-request_list);
@@ -2545,12 +2538,15 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
kref_init(request-ref);
request-ring = ring;
request-uniq = dev_private-request_uniq++;
+ request-ctx = ctx;
+ i915_gem_context_reference(request-ctx);
if (i915.enable_execlists)
- ret = intel_logical_ring_alloc_request_extras(request, ctx);
+ ret = intel_logical_ring_alloc_request_extras(request);
else
ret = intel_ring_alloc_request_extras(request);
if (ret) {
+ i915_gem_context_unreference(request-ctx);
kfree(request);
return ret;
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8d48761..a0ce65b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -611,20 +611,17 @@ static int execlists_move_to_gpu(struct intel_ringbuffer
*ringbuf,
return logical_ring_invalidate_all_caches(ringbuf, ctx);
}
-int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request,
- struct intel_context *ctx)
+int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request)
{
int ret;
- if (ctx != request-ring-default_context) {
- ret = intel_lr_context_pin(request-ring, ctx);
+ if (request-ctx != request-ring-default_context) {
+ ret = intel_lr_context_pin(request-ring, request-ctx);
if (ret)
return ret;
}
- request-ringbuf = ctx-engine[request-ring-id].ringbuf;
- request-ctx = ctx;
- i915_gem_context_reference(request-ctx);
+ request-ringbuf = request-ctx-engine[request-ring-id].ringbuf;
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 04d3a6d..4148de0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -36,8 +36,7 @@
#define RING_CONTEXT_STATUS_PTR(ring) ((ring)-mmio_base+0x3a0)
/* Logical Rings */
-int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request,
- struct intel_context *ctx);
+int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request);
void intel_logical_ring_stop(struct intel_engine_cs *ring);
void intel_logical_ring_cleanup(struct intel_engine_cs *ring);
int intel_logical_rings_init(struct drm_device *dev);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/59] drm/i915: Early alloc request in execbuff
From: John Harrison john.c.harri...@intel.com Start of explicit request management in the execbuffer code path. This patch adds a call to allocate a request structure before all the actual hardware work is done. Thus guaranteeing that all that work is tagged by a known request. At present, nothing further is done with the request, the rest comes later in the series. The only noticable change is that failure to get a request (e.g. due to lack of memory) will be caught earlier in the sequence. It now occurs right at the start before any un-undoable work has been done. v2: Simplified the error handling path. For: VIZ-5115 Signed-off-by: John Harrison john.c.harri...@intel.com --- drivers/gpu/drm/i915/i915_gem_execbuffer.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 1bb237c..2504cfd 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1594,10 +1594,16 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, } else exec_start += i915_gem_obj_offset(batch_obj, vm); + /* Allocate a request for this batch buffer nice and early. */ + ret = i915_gem_request_alloc(ring, ctx); + if (ret) + goto err_batch_unpin; + ret = dev_priv-gt.execbuf_submit(dev, file, ring, ctx, args, eb-vmas, batch_obj, exec_start, dispatch_flags); +err_batch_unpin: /* * FIXME: We crucially rely upon the active tracking for the (ppgtt) * batch vma for correctness. For less ugly and less fragility this @@ -1606,6 +1612,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, */ if (dispatch_flags I915_DISPATCH_SECURE) i915_gem_object_ggtt_unpin(batch_obj); + err: /* the request owns the ref now */ i915_gem_context_unreference(ctx); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/59] Remove the outstanding_lazy_request
From: John Harrison john.c.harri...@intel.com The driver tracks GPU work using request structures. Unfortunately, this tracking is not currently explicit but is done by means of a catch-all request that floats around in the background hoovering up work until it gets submitted. This background request (ring-outstanding_lazy_request or OLR) is created at the point of actually writing to the ring rather than when a particular piece of GPU work is started. This scheme sort of hangs together but causes a number of issues. It can mean that multiple pieces of independent work are lumped together in the same request or that work is not officially submitted until much later than it was created. This patch series completely removes the OLR and explicitly tracks each piece of work with it's own personal request structure from start to submission. The patch set seems to fix the 'gem_ringfill --r render' + ctrl-c straight after boot issue logged as BZ:88865. I haven't done any analysis of that particular issue but the descriptions I've seen appear to blame an inconsistent or mangled OLR. Note also that by the end of this series, a number of differences between the legacy and execlist code paths have been removed. For example add_request() and emit_request() now have the same signature thus could be merged back to a single function pointer. Merging some of these together would also allow the removal of a bunch of 'if(execlists)' tests where the difference is simply to call the legacy function or the execlist one. v2: Rebased to newer nightly tree, fixed up a few minor issues, added two extra patches - one to move the LRC ring begin around in the vein of other recent reshuffles, the other to clean up some issues with i915_add_request(). v3: Large re-work due to feedback from code review. Some patches have been removed, extra ones have been added and others have been changed significantly. It is recommended that all patches are reviewed from scratch rather than assuming only certain ones have changed and need re-inspecting. The exceptions are where the 'reviewed-by' tag has been kept because that patch was not significantly affected. [Patches against drm-intel-nightly tree fetched 18/03/2015] John Harrison (59): drm/i915: Rename 'do_execbuf' to 'execbuf_submit' drm/i915: Make intel_logical_ring_begin() static drm/i915: Move common request allocation code into a common function drm/i915: Fix for ringbuf space wait in LRC mode drm/i915: Reserve ring buffer space for i915_add_request() commands drm/i915: i915_add_request must not fail drm/i915: Early alloc request in execbuff drm/i915: Set context in request from creation even in legacy mode drm/i915: Merged the many do_execbuf() parameters into a structure drm/i915: Simplify i915_gem_execbuffer_retire_commands() parameters drm/i915: Update alloc_request to return the allocated request drm/i915: Add request to execbuf params and add explicit cleanup drm/i915: Update the dispatch tracepoint to use params-request drm/i915: Update move_to_gpu() to take a request structure drm/i915: Update execbuffer_move_to_active() to take a request structure drm/i915: Add flag to i915_add_request() to skip the cache flush drm/i915: Update i915_gpu_idle() to manage its own request drm/i915: Split i915_ppgtt_init_hw() in half - generic and per ring drm/i915: Moved the for_each_ring loop outside of i915_gem_context_enable() drm/i915: Don't tag kernel batches as user batches drm/i915: Add explicit request management to i915_gem_init_hw() drm/i915: Update ppgtt_init_ring() context_enable() to take requests drm/i915: Update i915_switch_context() to take a request structure drm/i915: Update do_switch() to take a request structure drm/i915: Update deferred context creation to do explicit request management drm/i915: Update init_context() to take a request structure drm/i915: Update render_state_init() to take a request structure drm/i915: Update i915_gem_object_sync() to take a request structure drm/i915: Update overlay code to do explicit request management drm/i915: Update queue_flip() to take a request structure drm/i915: Update add_request() to take a request structure drm/i915: Update [vma|object]_move_to_active() to take request structures drm/i915: Update l3_remap to take a request structure drm/i915: Update mi_set_context() to take a request structure drm/i915: Update a bunch of execbuffer helpers to take request structures drm/i915: Update workarounds_emit() to take request structures drm/i915: Update flush_all_caches() to take request structures drm/i915: Update switch_mm() to take a request structure drm/i915: Update ring-flush() to take a requests structure drm/i915: Update some flush helpers to take request structures drm/i915: Update ring-emit_flush() to take a request structure drm/i915: Update ring-add_request() to take a request structure drm/i915: Update ring-emit_request() to take a
[Intel-gfx] [PATCH 09/59] drm/i915: Merged the many do_execbuf() parameters into a structure
From: John Harrison john.c.harri...@intel.com
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplifies the prototype by passing a parameter structure instead.
Changing the parameter set in the future is then simply a matter of
adding/removing items to the structure.
Note that the structure does not contain absolutely everything that is passed
in. This is because the intention is to use this structure more extensively
later in this patch series and more especially in the GPU scheduler that is
coming soon. The latter requires hanging on to the structure as the final
hardware submission can be delayed until long after the execbuf IOCTL has
returned to user land. Thus it is unsafe to put anything in the structure that
is local to the IOCTL call itself - such as the 'args' parameter. All entries
must be copies of data or pointers to structures that are reference counted in
some way and guaranteed to exist for the duration of the batch buffer's life.
v2: Rebased to newer tree and updated for changes to the command parser.
Specifically, a code shuffle has required saving the batch start address in the
params structure.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 28 +++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 61 ++--
drivers/gpu/drm/i915/intel_lrc.c | 26 ++--
drivers/gpu/drm/i915/intel_lrc.h |9 ++--
4 files changed, 71 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b36d4a..6ae99ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1558,6 +1558,17 @@ struct i915_virtual_gpu {
bool active;
};
+struct i915_execbuffer_params {
+ struct drm_device *dev;
+ struct drm_file *file;
+ uint32_tdispatch_flags;
+ uint32_targs_batch_start_offset;
+ uint32_tbatch_obj_vm_offset;
+ struct intel_engine_cs *ring;
+ struct drm_i915_gem_object *batch_obj;
+ struct intel_context*ctx;
+};
+
struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1812,13 +1823,9 @@ struct drm_i915_private {
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct {
- int (*execbuf_submit)(struct drm_device *dev, struct drm_file
*file,
- struct intel_engine_cs *ring,
- struct intel_context *ctx,
+ int (*execbuf_submit)(struct i915_execbuffer_params *params,
struct drm_i915_gem_execbuffer2 *args,
- struct list_head *vmas,
- struct drm_i915_gem_object *batch_obj,
- u64 exec_start, u32 flags);
+ struct list_head *vmas);
int (*init_rings)(struct drm_device *dev);
void (*cleanup_ring)(struct intel_engine_cs *ring);
void (*stop_ring)(struct intel_engine_cs *ring);
@@ -2569,14 +2576,9 @@ void i915_gem_execbuffer_retire_commands(struct
drm_device *dev,
struct drm_file *file,
struct intel_engine_cs *ring,
struct drm_i915_gem_object *obj);
-int i915_gem_ringbuffer_submission(struct drm_device *dev,
- struct drm_file *file,
- struct intel_engine_cs *ring,
- struct intel_context *ctx,
+int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
struct drm_i915_gem_execbuffer2 *args,
- struct list_head *vmas,
- struct drm_i915_gem_object *batch_obj,
- u64 exec_start, u32 flags);
+ struct list_head *vmas);
int i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int i915_gem_execbuffer2(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2504cfd..2fffd99 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1185,17 +1185,15 @@ err:
}
int
-i915_gem_ringbuffer_submission(struct
[Intel-gfx] [PATCH 02/59] drm/i915: Make intel_logical_ring_begin() static
From: John Harrison john.c.harri...@intel.com
The only usage of intel_logical_ring_begin() is within intel_lrc.c so it can be
made static. To avoid a forward declaration at the top of the file, it and bunch
of other functions have been shuffled upwards.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 474 +++---
drivers/gpu/drm/i915/intel_lrc.h |3 -
2 files changed, 237 insertions(+), 240 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fcb074b..cad4300 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -611,6 +611,243 @@ static int execlists_move_to_gpu(struct intel_ringbuffer
*ringbuf,
return logical_ring_invalidate_all_caches(ringbuf, ctx);
}
+static int logical_ring_alloc_request(struct intel_engine_cs *ring,
+ struct intel_context *ctx)
+{
+ struct drm_i915_gem_request *request;
+ struct drm_i915_private *dev_private = ring-dev-dev_private;
+ int ret;
+
+ if (ring-outstanding_lazy_request)
+ return 0;
+
+ request = kzalloc(sizeof(*request), GFP_KERNEL);
+ if (request == NULL)
+ return -ENOMEM;
+
+ if (ctx != ring-default_context) {
+ ret = intel_lr_context_pin(ring, ctx);
+ if (ret) {
+ kfree(request);
+ return ret;
+ }
+ }
+
+ kref_init(request-ref);
+ request-ring = ring;
+ request-uniq = dev_private-request_uniq++;
+
+ ret = i915_gem_get_seqno(ring-dev, request-seqno);
+ if (ret) {
+ intel_lr_context_unpin(ring, ctx);
+ kfree(request);
+ return ret;
+ }
+
+ request-ctx = ctx;
+ i915_gem_context_reference(request-ctx);
+ request-ringbuf = ctx-engine[ring-id].ringbuf;
+
+ ring-outstanding_lazy_request = request;
+ return 0;
+}
+
+static int logical_ring_wait_request(struct intel_ringbuffer *ringbuf,
+int bytes)
+{
+ struct intel_engine_cs *ring = ringbuf-ring;
+ struct drm_i915_gem_request *request;
+ int ret;
+
+ if (intel_ring_space(ringbuf) = bytes)
+ return 0;
+
+ list_for_each_entry(request, ring-request_list, list) {
+ /*
+* The request queue is per-engine, so can contain requests
+* from multiple ringbuffers. Here, we must ignore any that
+* aren't from the ringbuffer we're considering.
+*/
+ struct intel_context *ctx = request-ctx;
+ if (ctx-engine[ring-id].ringbuf != ringbuf)
+ continue;
+
+ /* Would completion of this request free enough space? */
+ if (__intel_ring_space(request-tail, ringbuf-tail,
+ ringbuf-size) = bytes) {
+ break;
+ }
+ }
+
+ if (request-list == ring-request_list)
+ return -ENOSPC;
+
+ ret = i915_wait_request(request);
+ if (ret)
+ return ret;
+
+ i915_gem_retire_requests_ring(ring);
+
+ return intel_ring_space(ringbuf) = bytes ? 0 : -ENOSPC;
+}
+
+/*
+ * intel_logical_ring_advance_and_submit() - advance the tail and submit the
workload
+ * @ringbuf: Logical Ringbuffer to advance.
+ *
+ * The tail is updated in our logical ringbuffer struct, not in the actual
context. What
+ * really happens during submission is that the context and current tail will
be placed
+ * on a queue waiting for the ELSP to be ready to accept a new context
submission. At that
+ * point, the tail *inside* the context is updated and the ELSP written to.
+ */
+static void
+intel_logical_ring_advance_and_submit(struct intel_ringbuffer *ringbuf,
+ struct intel_context *ctx,
+ struct drm_i915_gem_request *request)
+{
+ struct intel_engine_cs *ring = ringbuf-ring;
+
+ intel_logical_ring_advance(ringbuf);
+
+ if (intel_ring_stopped(ring))
+ return;
+
+ execlists_context_queue(ring, ctx, ringbuf-tail, request);
+}
+
+static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf,
+ struct intel_context *ctx,
+ int bytes)
+{
+ struct intel_engine_cs *ring = ringbuf-ring;
+ struct drm_device *dev = ring-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long end;
+ int ret;
+
+ ret = logical_ring_wait_request(ringbuf, bytes);
+ if (ret != -ENOSPC)
+ return ret;
+
+ /* Force the context submission in case we have been skipping it */
+
[Intel-gfx] [PATCH 04/59] drm/i915: Fix for ringbuf space wait in LRC mode
From: John Harrison john.c.harri...@intel.com
The legacy and LRC code paths have an almost identical procedure for waiting for
space in the ring buffer. They both search for a request in the free list that
will advance the tail to a point where sufficient space is available. They then
wait for that request, retire it and recalculate the free space value.
Unfortunately, a bug in the LRC side meant that the resulting free space might
not be as large as expected and indeed, might not be sufficient. This is because
it was testing against the value of request-tail not request-postfix. Whereas,
when a request is retired, ringbuf-tail is updated to req-postfix not
req-tail.
Another significant difference between the two is that the LRC one did not trust
the wait for request to work! It redid the is there enough space available test
and would fail the call if insufficient. Whereas, the legacy version just said
'return 0' - it assumed the preceeding code works. This difference meant that
the LRC version still worked even with the bug - it just fell back to the
polling wait path.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 10 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6504689..1c3834fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -634,7 +634,7 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
{
struct intel_engine_cs *ring = ringbuf-ring;
struct drm_i915_gem_request *request;
- int ret;
+ int ret, new_space;
if (intel_ring_space(ringbuf) = bytes)
return 0;
@@ -650,10 +650,10 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
continue;
/* Would completion of this request free enough space? */
- if (__intel_ring_space(request-tail, ringbuf-tail,
- ringbuf-size) = bytes) {
+ new_space = __intel_ring_space(request-postfix, ringbuf-tail,
+ ringbuf-size);
+ if (new_space = bytes)
break;
- }
}
if (request-list == ring-request_list)
@@ -665,6 +665,8 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
i915_gem_retire_requests_ring(ring);
+ WARN_ON(intel_ring_space(ringbuf) new_space);
+
return intel_ring_space(ringbuf) = bytes ? 0 : -ENOSPC;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 99fb2f0..a26bdf8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2059,16 +2059,16 @@ static int intel_ring_wait_request(struct
intel_engine_cs *ring, int n)
{
struct intel_ringbuffer *ringbuf = ring-buffer;
struct drm_i915_gem_request *request;
- int ret;
+ int ret, new_space;
if (intel_ring_space(ringbuf) = n)
return 0;
list_for_each_entry(request, ring-request_list, list) {
- if (__intel_ring_space(request-postfix, ringbuf-tail,
- ringbuf-size) = n) {
+ new_space = __intel_ring_space(request-postfix, ringbuf-tail,
+ ringbuf-size);
+ if (new_space = n)
break;
- }
}
if (request-list == ring-request_list)
@@ -2080,6 +2080,8 @@ static int intel_ring_wait_request(struct intel_engine_cs
*ring, int n)
i915_gem_retire_requests_ring(ring);
+ WARN_ON(intel_ring_space(ringbuf) new_space);
+
return 0;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/59] drm/i915: Rename 'do_execbuf' to 'execbuf_submit'
From: John Harrison john.c.harri...@intel.com
The submission portion of the execbuffer code path was abstracted into a
function pointer indirection as part of the legacy vs execlist work. The two
implementation functions are called 'i915_gem_ringbuffer_submission' and
'intel_execlists_submission' but the pointer was called 'do_execbuf'. There is
already a 'i915_gem_do_execbuffer' function (which is what calls the pointer
indirection). The name of the pointer is therefore considered to be backwards
and should be changed.
This patch renames it to 'execbuf_submit' which is hopefully a bit clearer.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 14 +++---
drivers/gpu/drm/i915/i915_gem.c|4 ++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +++---
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb38cd1..1a23445 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1812,13 +1812,13 @@ struct drm_i915_private {
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct {
- int (*do_execbuf)(struct drm_device *dev, struct drm_file *file,
- struct intel_engine_cs *ring,
- struct intel_context *ctx,
- struct drm_i915_gem_execbuffer2 *args,
- struct list_head *vmas,
- struct drm_i915_gem_object *batch_obj,
- u64 exec_start, u32 flags);
+ int (*execbuf_submit)(struct drm_device *dev, struct drm_file
*file,
+ struct intel_engine_cs *ring,
+ struct intel_context *ctx,
+ struct drm_i915_gem_execbuffer2 *args,
+ struct list_head *vmas,
+ struct drm_i915_gem_object *batch_obj,
+ u64 exec_start, u32 flags);
int (*init_rings)(struct drm_device *dev);
void (*cleanup_ring)(struct intel_engine_cs *ring);
void (*stop_ring)(struct intel_engine_cs *ring);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 092f25c..51cdfb7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4837,12 +4837,12 @@ int i915_gem_init(struct drm_device *dev)
}
if (!i915.enable_execlists) {
- dev_priv-gt.do_execbuf = i915_gem_ringbuffer_submission;
+ dev_priv-gt.execbuf_submit = i915_gem_ringbuffer_submission;
dev_priv-gt.init_rings = i915_gem_init_rings;
dev_priv-gt.cleanup_ring = intel_cleanup_ring_buffer;
dev_priv-gt.stop_ring = intel_stop_ring_buffer;
} else {
- dev_priv-gt.do_execbuf = intel_execlists_submission;
+ dev_priv-gt.execbuf_submit = intel_execlists_submission;
dev_priv-gt.init_rings = intel_logical_rings_init;
dev_priv-gt.cleanup_ring = intel_logical_ring_cleanup;
dev_priv-gt.stop_ring = intel_logical_ring_stop;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9838d11..38e2178 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1594,9 +1594,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
} else
exec_start += i915_gem_obj_offset(batch_obj, vm);
- ret = dev_priv-gt.do_execbuf(dev, file, ring, ctx, args,
- eb-vmas, batch_obj, exec_start,
- dispatch_flags);
+ ret = dev_priv-gt.execbuf_submit(dev, file, ring, ctx, args,
+ eb-vmas, batch_obj, exec_start,
+ dispatch_flags);
/*
* FIXME: We crucially rely upon the active tracking for the (ppgtt)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/59] drm/i915: Simplify i915_gem_execbuffer_retire_commands() parameters
From: John Harrison john.c.harri...@intel.com
Shrunk the parameter list of i915_gem_execbuffer_retire_commands() to a single
structure as everything it requires is available in the execbuff_params object.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|5 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12
drivers/gpu/drm/i915/intel_lrc.c |2 +-
3 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6ae99ce..e2d5790 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2572,10 +2572,7 @@ int i915_gem_sw_finish_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv);
void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
struct intel_engine_cs *ring);
-void i915_gem_execbuffer_retire_commands(struct drm_device *dev,
-struct drm_file *file,
-struct intel_engine_cs *ring,
-struct drm_i915_gem_object *obj);
+void i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params
*params);
int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
struct drm_i915_gem_execbuffer2 *args,
struct list_head *vmas);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2fffd99..f9da0ad 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1054,16 +1054,13 @@ i915_gem_execbuffer_move_to_active(struct list_head
*vmas,
}
void
-i915_gem_execbuffer_retire_commands(struct drm_device *dev,
- struct drm_file *file,
- struct intel_engine_cs *ring,
- struct drm_i915_gem_object *obj)
+i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params *params)
{
/* Unconditionally force add_request to emit a full flush. */
- ring-gpu_caches_dirty = true;
+ params-ring-gpu_caches_dirty = true;
/* Add a breadcrumb for the completion of the batch buffer */
- __i915_add_request(ring, file, obj);
+ __i915_add_request(params-ring, params-file, params-batch_obj);
}
static int
@@ -1335,8 +1332,7 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
trace_i915_gem_ring_dispatch(intel_ring_get_request(ring),
params-dispatch_flags);
i915_gem_execbuffer_move_to_active(vmas, ring);
- i915_gem_execbuffer_retire_commands(params-dev, params-file, ring,
- params-batch_obj);
+ i915_gem_execbuffer_retire_commands(params);
error:
kfree(cliprects);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c0d97e97..21af5d6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -941,7 +941,7 @@ int intel_execlists_submission(struct
i915_execbuffer_params *params,
trace_i915_gem_ring_dispatch(intel_ring_get_request(ring),
params-dispatch_flags);
i915_gem_execbuffer_move_to_active(vmas, ring);
- i915_gem_execbuffer_retire_commands(params-dev, params-file, ring,
params-batch_obj);
+ i915_gem_execbuffer_retire_commands(params);
return 0;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/59] drm/i915: Update move_to_gpu() to take a request structure
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the move_to_gpu() code paths.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +-
drivers/gpu/drm/i915/intel_lrc.c | 10 --
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0b705cb..7c7ec0c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -892,7 +892,7 @@ err:
}
static int
-i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs *ring,
+i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
struct list_head *vmas)
{
struct i915_vma *vma;
@@ -902,7 +902,7 @@ i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs
*ring,
list_for_each_entry(vma, vmas, exec_list) {
struct drm_i915_gem_object *obj = vma-obj;
- ret = i915_gem_object_sync(obj, ring);
+ ret = i915_gem_object_sync(obj, req-ring);
if (ret)
return ret;
@@ -913,7 +913,7 @@ i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs
*ring,
}
if (flush_chipset)
- i915_gem_chipset_flush(ring-dev);
+ i915_gem_chipset_flush(req-ring-dev);
if (flush_domains I915_GEM_DOMAIN_GTT)
wmb();
@@ -921,7 +921,7 @@ i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs
*ring,
/* Unconditionally invalidate gpu caches and ensure that we do flush
* any residual writes from the previous batch.
*/
- return intel_ring_invalidate_all_caches(ring);
+ return intel_ring_invalidate_all_caches(req-ring);
}
static bool
@@ -1238,7 +1238,7 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
}
}
- ret = i915_gem_execbuffer_move_to_gpu(ring, vmas);
+ ret = i915_gem_execbuffer_move_to_gpu(params-request, vmas);
if (ret)
goto error;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4c72c11b..4ed3621 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -579,11 +579,9 @@ static int logical_ring_invalidate_all_caches(struct
intel_ringbuffer *ringbuf,
return 0;
}
-static int execlists_move_to_gpu(struct intel_ringbuffer *ringbuf,
-struct intel_context *ctx,
+static int execlists_move_to_gpu(struct drm_i915_gem_request *req,
struct list_head *vmas)
{
- struct intel_engine_cs *ring = ringbuf-ring;
struct i915_vma *vma;
uint32_t flush_domains = 0;
bool flush_chipset = false;
@@ -592,7 +590,7 @@ static int execlists_move_to_gpu(struct intel_ringbuffer
*ringbuf,
list_for_each_entry(vma, vmas, exec_list) {
struct drm_i915_gem_object *obj = vma-obj;
- ret = i915_gem_object_sync(obj, ring);
+ ret = i915_gem_object_sync(obj, req-ring);
if (ret)
return ret;
@@ -608,7 +606,7 @@ static int execlists_move_to_gpu(struct intel_ringbuffer
*ringbuf,
/* Unconditionally invalidate gpu caches and ensure that we do flush
* any residual writes from the previous batch.
*/
- return logical_ring_invalidate_all_caches(ringbuf, ctx);
+ return logical_ring_invalidate_all_caches(req-ringbuf, req-ctx);
}
int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request)
@@ -913,7 +911,7 @@ int intel_execlists_submission(struct
i915_execbuffer_params *params,
return -EINVAL;
}
- ret = execlists_move_to_gpu(ringbuf, params-ctx, vmas);
+ ret = execlists_move_to_gpu(params-request, vmas);
if (ret)
return ret;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/59] drm/i915: Add request to execbuf params and add explicit cleanup
From: John Harrison john.c.harri...@intel.com
Rather than just having a local request variable in the execbuff code, the
request pointer is now stored in the execbuff params structure. Also added
explicit cleanup of the request (plus wiping the OLR to match) in the error
case. This means that the execbuff code is no longer dependent upon the OLR
keeping track of the request so as to not leak it when things do go wrong. Note
that in the success case, the i915_add_request() at the end of the submission
function will tidy up the request and clear the OLR.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c2c8a9..d9e9693 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1567,6 +1567,7 @@ struct i915_execbuffer_params {
struct intel_engine_cs *ring;
struct drm_i915_gem_object *batch_obj;
struct intel_context*ctx;
+ struct drm_i915_gem_request *request;
};
struct drm_i915_private {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 38f6c76..f14bd69 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1404,7 +1404,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_address_space *vm;
struct i915_execbuffer_params params_master; /* XXX: will be removed
later */
struct i915_execbuffer_params *params = params_master;
- struct drm_i915_gem_request *request;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
int ret;
@@ -1598,7 +1597,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
params-batch_obj_vm_offset = i915_gem_obj_offset(batch_obj,
vm);
/* Allocate a request for this batch buffer nice and early. */
- ret = i915_gem_request_alloc(ring, ctx, request);
+ ret = i915_gem_request_alloc(ring, ctx, params-request);
if (ret)
goto err_batch_unpin;
@@ -1632,6 +1631,16 @@ err:
i915_gem_context_unreference(ctx);
eb_destroy(eb);
+ /*
+* If the request was created but not successfully submitted then it
+* must be freed again. If it was submitted then it is being tracked
+* on the active request list and no clean up is required here.
+*/
+ if (ret params-request) {
+ i915_gem_request_cancel(params-request);
+ ring-outstanding_lazy_request = NULL;
+ }
+
mutex_unlock(dev-struct_mutex);
pre_mutex_err:
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/59] drm/i915: Update execbuffer_move_to_active() to take a request structure
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the
execbuffer_move_to_active() code path.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 +++---
drivers/gpu/drm/i915/intel_lrc.c |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d9e9693..d3b718e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2573,7 +2573,7 @@ int i915_gem_set_domain_ioctl(struct drm_device *dev,
void *data,
int i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
- struct intel_engine_cs *ring);
+ struct drm_i915_gem_request *req);
void i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params
*params);
int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
struct drm_i915_gem_execbuffer2 *args,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 7c7ec0c..3173550 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1014,9 +1014,9 @@ i915_gem_validate_context(struct drm_device *dev, struct
drm_file *file,
void
i915_gem_execbuffer_move_to_active(struct list_head *vmas,
- struct intel_engine_cs *ring)
+ struct drm_i915_gem_request *req)
{
- struct drm_i915_gem_request *req = intel_ring_get_request(ring);
+ struct intel_engine_cs *ring = i915_gem_request_get_ring(req);
struct i915_vma *vma;
list_for_each_entry(vma, vmas, exec_list) {
@@ -1331,7 +1331,7 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
trace_i915_gem_ring_dispatch(params-request, params-dispatch_flags);
- i915_gem_execbuffer_move_to_active(vmas, ring);
+ i915_gem_execbuffer_move_to_active(vmas, params-request);
i915_gem_execbuffer_retire_commands(params);
error:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4ed3621..8c69f88 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -939,7 +939,7 @@ int intel_execlists_submission(struct
i915_execbuffer_params *params,
trace_i915_gem_ring_dispatch(params-request, params-dispatch_flags);
- i915_gem_execbuffer_move_to_active(vmas, ring);
+ i915_gem_execbuffer_move_to_active(vmas, params-request);
i915_gem_execbuffer_retire_commands(params);
return 0;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/59] drm/i915: Add explicit request management to i915_gem_init_hw()
From: John Harrison john.c.harri...@intel.com
Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable call
eventually ends up within *_render_state_init() and this does it's own private
_i915_add_request() call.
This patch adds explicit request creation and submission to the top level loop
and removes the add_request() from deep within the sub-functions. Note that the
old add_request() call was being passed a batch object. This is now explicitly
written to the request object instead. A warning has also been added to
i915_add_request() to ensure that there is never an attempt to add two batch
objects to a single request - e.g. because render_state_init() was called during
execbuffer processing.
v2: Updated for removal of batch_obj from add_request call in previous patch
(which is new to series).
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |3 ++-
drivers/gpu/drm/i915/i915_gem.c | 12
drivers/gpu/drm/i915/i915_gem_render_state.c |2 --
drivers/gpu/drm/i915/intel_lrc.c |5 -
4 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cc957d5..aa0695b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2082,7 +2082,8 @@ struct drm_i915_gem_request {
struct intel_context *ctx;
struct intel_ringbuffer *ringbuf;
- /** Batch buffer related to this request if any */
+ /** Batch buffer related to this request if any (used for
+ error state dump only) */
struct drm_i915_gem_object *batch_obj;
/** Time at which this request was emitted, in jiffies. */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 29568c4..4452618 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4900,8 +4900,16 @@ i915_gem_init_hw(struct drm_device *dev)
/* Now it is safe to go back round and do everything else: */
for_each_ring(ring, dev_priv, i) {
+ struct drm_i915_gem_request *req;
+
WARN_ON(!ring-default_context);
+ ret = i915_gem_request_alloc(ring, ring-default_context, req);
+ if (ret) {
+ i915_gem_cleanup_ringbuffer(dev);
+ goto out;
+ }
+
if (ring-id == RCS) {
for (i = 0; i NUM_L3_SLICES(dev); i++)
i915_gem_l3_remap(ring, i);
@@ -4910,6 +4918,7 @@ i915_gem_init_hw(struct drm_device *dev)
ret = i915_ppgtt_init_ring(ring);
if (ret ret != -EIO) {
DRM_ERROR(PPGTT enable ring #%d failed %d\n, i, ret);
+ i915_gem_request_cancel(req);
i915_gem_cleanup_ringbuffer(dev);
goto out;
}
@@ -4917,9 +4926,12 @@ i915_gem_init_hw(struct drm_device *dev)
ret = i915_gem_context_enable(ring);
if (ret ret != -EIO) {
DRM_ERROR(Context enable ring #%d failed %d\n, i,
ret);
+ i915_gem_request_cancel(req);
i915_gem_cleanup_ringbuffer(dev);
goto out;
}
+
+ i915_add_request_no_flush(ring);
}
out:
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index a32a4b9..a07b4ee 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -173,8 +173,6 @@ int i915_gem_render_state_init(struct intel_engine_cs *ring)
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
- __i915_add_request(ring, NULL, NULL, true);
- /* __i915_add_request moves object to inactive if it fails */
out:
i915_gem_render_state_fini(so);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f24ab0c..b430e51 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1330,8 +1330,6 @@ static int intel_lr_context_render_state_init(struct
intel_engine_cs *ring,
{
struct intel_ringbuffer *ringbuf = ctx-engine[ring-id].ringbuf;
struct render_state so;
- struct drm_i915_file_private *file_priv = ctx-file_priv;
- struct drm_file *file = file_priv ? file_priv-file : NULL;
int ret;
ret = i915_gem_render_state_prepare(ring, so);
@@ -1350,9 +1348,6 @@ static int intel_lr_context_render_state_init(struct
intel_engine_cs *ring,
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
-
[Intel-gfx] [PATCH 13/59] drm/i915: Update the dispatch tracepoint to use params-request
From: John Harrison john.c.harri...@intel.com Updated a couple of trace points to use the now cached request pointer rather than extracting it from the ring. For: VIZ-5115 Signed-off-by: John Harrison john.c.harri...@intel.com Reviewed-by: Tomas Elf tomas@intel.com --- drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +- drivers/gpu/drm/i915/intel_lrc.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index f14bd69..0b705cb 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1329,7 +1329,7 @@ i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params, return ret; } - trace_i915_gem_ring_dispatch(intel_ring_get_request(ring), params-dispatch_flags); + trace_i915_gem_ring_dispatch(params-request, params-dispatch_flags); i915_gem_execbuffer_move_to_active(vmas, ring); i915_gem_execbuffer_retire_commands(params); diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ecd293a..4c72c11b 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -939,7 +939,7 @@ int intel_execlists_submission(struct i915_execbuffer_params *params, if (ret) return ret; - trace_i915_gem_ring_dispatch(intel_ring_get_request(ring), params-dispatch_flags); + trace_i915_gem_ring_dispatch(params-request, params-dispatch_flags); i915_gem_execbuffer_move_to_active(vmas, ring); i915_gem_execbuffer_retire_commands(params); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/59] drm/i915: Update alloc_request to return the allocated request
From: John Harrison john.c.harri...@intel.com
The alloc_request() function does not actually return the newly allocated
request. Instead, it must be pulled from ring-outstanding_lazy_request. This
patch fixes this so that code can create a request and start using it knowing
exactly which request it actually owns.
v2: Updated for new i915_gem_request_alloc() scheme.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|3 ++-
drivers/gpu/drm/i915/i915_gem.c| 10 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |3 ++-
drivers/gpu/drm/i915/intel_lrc.c |3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c|3 ++-
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e2d5790..2c2c8a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2121,7 +2121,8 @@ struct drm_i915_gem_request {
};
int i915_gem_request_alloc(struct intel_engine_cs *ring,
- struct intel_context *ctx);
+ struct intel_context *ctx,
+ struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
void i915_gem_request_free(struct kref *req_ref);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f35ac7f..9a335d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2516,13 +2516,17 @@ void i915_gem_request_free(struct kref *req_ref)
}
int i915_gem_request_alloc(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+ struct intel_context *ctx,
+ struct drm_i915_gem_request **req_out)
{
int ret;
struct drm_i915_gem_request *request;
struct drm_i915_private *dev_private = ring-dev-dev_private;
- if (ring-outstanding_lazy_request)
+ if (!req_out)
+ return -EINVAL;
+
+ if ((*req_out = ring-outstanding_lazy_request) != NULL)
return 0;
request = kzalloc(sizeof(*request), GFP_KERNEL);
@@ -2580,7 +2584,7 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
return ret;
}
- ring-outstanding_lazy_request = request;
+ *req_out = ring-outstanding_lazy_request = request;
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f9da0ad..38f6c76 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1404,6 +1404,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_address_space *vm;
struct i915_execbuffer_params params_master; /* XXX: will be removed
later */
struct i915_execbuffer_params *params = params_master;
+ struct drm_i915_gem_request *request;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
int ret;
@@ -1597,7 +1598,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
params-batch_obj_vm_offset = i915_gem_obj_offset(batch_obj,
vm);
/* Allocate a request for this batch buffer nice and early. */
- ret = i915_gem_request_alloc(ring, ctx);
+ ret = i915_gem_request_alloc(ring, ctx, request);
if (ret)
goto err_batch_unpin;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 21af5d6..ecd293a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -813,6 +813,7 @@ static int logical_ring_prepare(struct intel_ringbuffer
*ringbuf,
static int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
struct intel_context *ctx, int num_dwords)
{
+ struct drm_i915_gem_request *req;
struct intel_engine_cs *ring = ringbuf-ring;
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -828,7 +829,7 @@ static int intel_logical_ring_begin(struct intel_ringbuffer
*ringbuf,
return ret;
/* Preallocate the olr before touching the ring */
- ret = i915_gem_request_alloc(ring, ctx);
+ ret = i915_gem_request_alloc(ring, ctx, req);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1a7ed8b..958da01 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2256,6 +2256,7 @@ static int __intel_ring_prepare(struct intel_engine_cs
*ring, int bytes)
int intel_ring_begin(struct intel_engine_cs *ring,
int num_dwords)
{
+ struct drm_i915_gem_request *req;
struct
[Intel-gfx] [PATCH 06/59] drm/i915: i915_add_request must not fail
From: John Harrison john.c.harri...@intel.com
The i915_add_request() function is called to keep track of work that has been
written to the ring buffer. It adds epilogue commands to track progress (seqno
updates and such), moves the request structure onto the right list and other
such house keeping tasks. However, the work itself has already been written to
the ring and will get executed whether or not the add request call succeeds. So
no matter what goes wrong, there isn't a whole lot of point in failing the call.
At the moment, this is fine(ish). If the add request does bail early on and not
do the housekeeping, the request will still float around in the
ring-outstanding_lazy_request field and be picked up next time. It means
multiple pieces of work will be tagged as the same request and driver can't
actually wait for the first piece of work until something else has been
submitted. But it all sort of hangs together.
This patch series is all about removing the OLR and guaranteeing that each piece
of work gets its own personal request. That means that there is no more
'hoovering up of forgotten requests'. If the request does not get tracked then
it will be leaked. Thus the add request call _must_ not fail. The previous patch
should have already ensured that it _will_ not fail by removing the potential
for running out of ring space. This patch enforces the rule by actually removing
the early exit paths and the return code.
Note that if something does manage to fail and the epilogue commands don't get
written to the ring, the driver will still hang together. The request will be
added to the tracking lists. And as in the old case, any subsequent work will
generate a new seqno which will suffice for marking the old one as complete.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |6 ++--
drivers/gpu/drm/i915/i915_gem.c | 44 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/i915_gem_render_state.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
drivers/gpu/drm/i915/intel_overlay.c | 10 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c |8 ++---
7 files changed, 32 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe6446d..7b36d4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2748,9 +2748,9 @@ void i915_gem_init_swizzling(struct drm_device *dev);
void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_suspend(struct drm_device *dev);
-int __i915_add_request(struct intel_engine_cs *ring,
- struct drm_file *file,
- struct drm_i915_gem_object *batch_obj);
+void __i915_add_request(struct intel_engine_cs *ring,
+ struct drm_file *file,
+ struct drm_i915_gem_object *batch_obj);
#define i915_add_request(ring) \
__i915_add_request(ring, NULL, NULL)
int __i915_wait_request(struct drm_i915_gem_request *req,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fc383fc..cdf1c9d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1159,15 +1159,12 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
int
i915_gem_check_olr(struct drm_i915_gem_request *req)
{
- int ret;
-
WARN_ON(!mutex_is_locked(req-ring-dev-struct_mutex));
- ret = 0;
if (req == req-ring-outstanding_lazy_request)
- ret = i915_add_request(req-ring);
+ i915_add_request(req-ring);
- return ret;
+ return 0;
}
static void fake_irq(unsigned long data)
@@ -2325,9 +2322,14 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
return 0;
}
-int __i915_add_request(struct intel_engine_cs *ring,
- struct drm_file *file,
- struct drm_i915_gem_object *obj)
+/*
+ * NB: This function is not allowed to fail. Doing so would mean the the
+ * request is not being tracked for completion but the work itself is
+ * going to happen on the hardware. This would be a Bad Thing(tm).
+ */
+void __i915_add_request(struct intel_engine_cs *ring,
+ struct drm_file *file,
+ struct drm_i915_gem_object *obj)
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *request;
@@ -2337,7 +2339,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
request = ring-outstanding_lazy_request;
if (WARN_ON(request == NULL))
- return -ENOMEM;
+ return;
if (i915.enable_execlists) {
ringbuf = request-ctx-engine[ring-id].ringbuf;
@@ -2359,15 +2361,12 @@ int
[Intel-gfx] [PATCH 05/59] drm/i915: Reserve ring buffer space for i915_add_request() commands
From: John Harrison john.c.harri...@intel.com
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the ring (cache flushing, seqno updates, interrupt signalling). The
reasons for that are mostly down to running out of ring buffer space and the
problems associated with trying to get some more. This patch prevents that
situation from happening in the first place.
When a request is created, it marks sufficient space as reserved for the
epilogue commands. Thus guaranteeing that by the time the epilogue is written,
there will be plenty of space for it. Note that a ring_begin() call is required
to actually reserve the space (and do any potential waiting). However, that is
not currently done at request creation time. This is because the ring_begin()
code can allocate a request. Hence calling begin() from the request allocation
code would lead to infinite recursion! Later patches in this series remove the
need for begin() to do the allocate. At that point, it becomes safe for the
allocate to call begin() and really reserve the space.
Until then, there is a potential for insufficient space to be available at the
point of calling i915_add_request(). However, that would only be in the case
where the request was created and immediately submitted without ever calling
ring_begin() and adding any work to that request. Which should never happen. And
even if it does, and if that request happens to fall down the tiny window of
opportunity for failing due to being out of ring space then does it really
matter because the request wasn't doing anything in the first place?
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 47 +
drivers/gpu/drm/i915/intel_lrc.c| 12
drivers/gpu/drm/i915/intel_ringbuffer.c | 50 +--
drivers/gpu/drm/i915/intel_ringbuffer.h |9 ++
5 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4ebd421..fe6446d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2115,6 +2115,7 @@ struct drm_i915_gem_request {
int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct intel_context *ctx);
+void i915_gem_request_cancel(struct drm_i915_gem_request *req);
void i915_gem_request_free(struct kref *req_ref);
static inline uint32_t
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4824adf..fc383fc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2344,6 +2344,13 @@ int __i915_add_request(struct intel_engine_cs *ring,
} else
ringbuf = ring-buffer;
+ /*
+* To ensure that this call will not fail, space for it's emissions
+* should already have been reserved in the ring buffer. Let the ring
+* know that it is time to use that space up.
+*/
+ intel_ring_reserved_space_use(ringbuf, MIN_SPACE_FOR_ADD_REQUEST);
+
request_start = intel_ring_get_tail(ringbuf);
/*
* Emit any outstanding flushes - execbuf can fail to emit the flush
@@ -2426,6 +2433,9 @@ int __i915_add_request(struct intel_engine_cs *ring,
round_jiffies_up_relative(HZ));
intel_mark_busy(dev_priv-dev);
+ /* Sanity check that the reserved size was large enough. */
+ intel_ring_reserved_space_end(ringbuf);
+
return 0;
}
@@ -2551,10 +2561,47 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
return ret;
}
+ /*
+* Reserve space in the ring buffer for all the commands required to
+* eventually emit this request. This is to guarantee that the
+* i915_add_request() call can't fail. Note that the reserve may need
+* to be redone if the request is not actually submitted straight
+* away, e.g. because a GPU scheduler has deferred it.
+*
+* Note further that this call merely notes the reserve request. A
+* subsequent call to *_ring_begin() is required to actually ensure
+* that the reservation is available. Without the begin, if the
+* request creator immediately submitted the request without adding
+* any commands to it then there might not actually be sufficient
+* room for the submission commands. Unfortunately, the current
+* *_ring_begin() implementations potentially call back here to
+* i915_gem_request_alloc(). Thus calling _begin() here would lead to
+* infinite recursion! Until that back call path is removed, it
[Intel-gfx] [PATCH 17/59] drm/i915: Update i915_gpu_idle() to manage its own request
From: John Harrison john.c.harri...@intel.com
Added explicit request creation and submission to the GPU idle code path.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f143d15..8677293 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3115,11 +3115,23 @@ int i915_gpu_idle(struct drm_device *dev)
/* Flush everything onto the inactive list. */
for_each_ring(ring, dev_priv, i) {
if (!i915.enable_execlists) {
- ret = i915_switch_context(ring, ring-default_context);
+ struct drm_i915_gem_request *req;
+
+ ret = i915_gem_request_alloc(ring,
ring-default_context, req);
if (ret)
return ret;
+
+ ret = i915_switch_context(req-ring,
ring-default_context);
+ if (ret) {
+ i915_gem_request_cancel(req);
+ return ret;
+ }
+
+ i915_add_request_no_flush(req-ring);
}
+ WARN_ON(ring-outstanding_lazy_request);
+
ret = intel_ring_idle(ring);
if (ret)
return ret;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 34/59] drm/i915: Update mi_set_context() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated mi_set_context() to take a request structure instead of a ring and
context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 4ae3a3d..f615fca 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -476,10 +476,9 @@ i915_gem_context_get(struct drm_i915_file_private
*file_priv, u32 id)
}
static inline int
-mi_set_context(struct intel_engine_cs *ring,
- struct intel_context *new_context,
- u32 hw_flags)
+mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
{
+ struct intel_engine_cs *ring = req-ring;
u32 flags = hw_flags | MI_MM_SPACE_GTT;
const int num_rings =
/* Use an extended w/a on ivb+ if signalling from other rings */
@@ -531,7 +530,7 @@ mi_set_context(struct intel_engine_cs *ring,
intel_ring_emit(ring, MI_NOOP);
intel_ring_emit(ring, MI_SET_CONTEXT);
- intel_ring_emit(ring,
i915_gem_obj_ggtt_offset(new_context-legacy_hw_ctx.rcs_state) |
+ intel_ring_emit(ring,
i915_gem_obj_ggtt_offset(req-ctx-legacy_hw_ctx.rcs_state) |
flags);
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
@@ -632,7 +631,7 @@ static int do_switch(struct drm_i915_gem_request *req)
if (!to-legacy_hw_ctx.initialized || i915_gem_context_is_default(to))
hw_flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(ring, to, hw_flags);
+ ret = mi_set_context(req, hw_flags);
if (ret)
goto unpin_out;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 26/59] drm/i915: Update init_context() to take a request structure
From: John Harrison john.c.harri...@intel.com
Now that everything above has been converted to use requests, it is possible to
update init_context() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c |4 ++--
drivers/gpu/drm/i915/intel_lrc.c|9 -
drivers/gpu/drm/i915/intel_ringbuffer.c |7 +++
drivers/gpu/drm/i915/intel_ringbuffer.h |3 +--
4 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 78e9c9c..75b9d78 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -416,7 +416,7 @@ int i915_gem_context_enable(struct drm_i915_gem_request
*req)
if (ring-init_context == NULL)
return 0;
- ret = ring-init_context(ring, ring-default_context);
+ ret = ring-init_context(req);
} else
ret = i915_switch_context(req);
@@ -682,7 +682,7 @@ done:
if (uninitialized) {
if (ring-init_context) {
- ret = ring-init_context(ring, to);
+ ret = ring-init_context(req);
if (ret)
DRM_ERROR(ring init context: %d\n, ret);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c77a74b..46df37c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1353,16 +1353,15 @@ out:
return ret;
}
-static int gen8_init_rcs_context(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+static int gen8_init_rcs_context(struct drm_i915_gem_request *req)
{
int ret;
- ret = intel_logical_ring_workarounds_emit(ring, ctx);
+ ret = intel_logical_ring_workarounds_emit(req-ring, req-ctx);
if (ret)
return ret;
- return intel_lr_context_render_state_init(ring, ctx);
+ return intel_lr_context_render_state_init(req-ring, req-ctx);
}
/**
@@ -1955,7 +1954,7 @@ int intel_lr_context_deferred_create(struct intel_context
*ctx,
if (ret)
return ret;
- ret = ring-init_context(req-ring, ctx);
+ ret = ring-init_context(req);
if (ret) {
DRM_ERROR(ring init context: %d\n, ret);
i915_gem_request_cancel(req);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 958da01..f36d00d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -742,16 +742,15 @@ static int intel_ring_workarounds_emit(struct
intel_engine_cs *ring,
return 0;
}
-static int intel_rcs_ctx_init(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+static int intel_rcs_ctx_init(struct drm_i915_gem_request *req)
{
int ret;
- ret = intel_ring_workarounds_emit(ring, ctx);
+ ret = intel_ring_workarounds_emit(req-ring, req-ctx);
if (ret != 0)
return ret;
- ret = i915_gem_render_state_init(ring);
+ ret = i915_gem_render_state_init(req-ring);
if (ret)
DRM_ERROR(init render state: %d\n, ret);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index b334459..2dc111c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -146,8 +146,7 @@ struct intel_engine_cs {
int (*init_hw)(struct intel_engine_cs *ring);
- int (*init_context)(struct intel_engine_cs *ring,
- struct intel_context *ctx);
+ int (*init_context)(struct drm_i915_gem_request *req);
void(*write_tail)(struct intel_engine_cs *ring,
u32 value);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv
On Thu, 19 Mar 2015, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some of the baytrail systems :(. Switching back to legacy mode rps. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012 Signed-off-by: Deepak S deepa...@linux.intel.com Introduced in commit 31685c258e0b0ad6aa486c5ec001382cf8a64212 Author: Deepak S deepa...@linux.intel.com Date: Thu Jul 3 17:33:01 2014 -0400 drm/i915/vlv: WA for Turbo and RC6 to work together. Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_irq.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 6d8340d..7bbdede 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) INIT_WORK(dev_priv-l3_parity.error_work, ivybridge_parity_work); /* Let's track the enabled rps events */ - if (IS_VALLEYVIEW(dev_priv) !IS_CHERRYVIEW(dev_priv)) - /* WaGsvRC0ResidencyMethod:vlv */ - dev_priv-pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; - else - dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; + dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; INIT_DELAYED_WORK(dev_priv-gpu_error.hangcheck_work, i915_hangcheck_elapsed); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fallback to using unmappable memory for scanout
On Thu, Mar 19, 2015 at 04:23:32PM +0530, Deepak S wrote: Hi Chris, if we map the object into unmappable region. I think we should skip fence create ? We should just ignore the failure. Whether or not we want the fence pinned is a matter for the FBC code, which is a different level. But true, it should be fixed in this patch as well. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move vblank wait determination to 'check' phase
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5999 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 272/272 272/272 ILK 301/301 301/301 SNB 303/303 303/303 IVB 342/342 342/342 BYT 287/287 287/287 HSW 362/362 362/362 BDW 308/308 308/308 -Detailed- Platform Testdrm-intel-nightly Series Applied Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Split the batch pool by engine
On 03/19/2015 11:46 AM, Chris Wilson wrote: On Thu, Mar 19, 2015 at 11:39:16AM +, Tvrtko Ursulin wrote: On 03/19/2015 10:06 AM, Chris Wilson wrote: On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote: Well in a way at least where when we talk about LRU ordering, it depends on retiring working properly and that is not obvious from code layout and module separation. I've lost you. The list is in LRU submission order. With this split, the list is both in LRU submission and LRU retirememnt order. That the two are not the same originally is not a fault of retiring not working properly, but that the hardware is split into different units and timelines. And then with this me move traversal inefficiency to possible more resource use. Would it be better to fix the cause rather than symptoms? Is it feasible? What would be the downside of retiring all rings before submission? Not really. Inefficient userspace is inefficient. All we want to be sure is that one abusive client doesn't cause a DoS on another, whilst making sure that good clients are not penalized. Not sure to which of my question your not really was the answer. We do fix the cause later, and I've amended the throttling in mesa to prevent a reoccurrence. So I was thinking of why we only retire on the current ring. I understood that this is about the completed work which hasn't been retired due the latter only happening on submission to the same ring, or with too low frequency from retire work handler. If this is true, could we just not do a retire pass on all rings on any submission? No. The problem is that rings retire out of order. So a global LRU submission list is not strictly separated between inactive and active objects (in contrast to the per-engine list where it is true). How about retire all rings and then the inactive batch search with a global pool becomes only O(num_rings) at worst? Might be worth saving memory resource (multiple pools) vs. trivial traversal like that? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Split the batch pool by engine
On Thu, Mar 19, 2015 at 11:58:17AM +, Tvrtko Ursulin wrote: How about retire all rings and then the inactive batch search with a global pool becomes only O(num_rings) at worst? Might be worth saving memory resource (multiple pools) vs. trivial traversal like that? There isn't a memory resource issue here though. The pool is made out of easily reclaimable objects, and is ultimately limited by just how many batches can be submitted whilst the GPU is active. The principal issue is finding a new buffer to use for the next batch. Splitting by engine is also likely to have nice secondary effects like grouping of batch sizes. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/59] drm/i915: Move common request allocation code into a common function
From: John Harrison john.c.harri...@intel.com
The request allocation code is largely duplicated between legacy mode and
execlist mode. The actual difference between the two versions of the code is
pretty minimal.
This patch moves the common code out into a separate function. This is then
called by the execution specific version prior to setting up the one different
value.
For: VIZ-5190
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem.c | 37 +
drivers/gpu/drm/i915/intel_lrc.c| 39 +++
drivers/gpu/drm/i915/intel_lrc.h|2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 28 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++
6 files changed, 54 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1a23445..4ebd421 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2113,6 +2113,8 @@ struct drm_i915_gem_request {
};
+int i915_gem_request_alloc(struct intel_engine_cs *ring,
+ struct intel_context *ctx);
void i915_gem_request_free(struct kref *req_ref);
static inline uint32_t
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 51cdfb7..4824adf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2518,6 +2518,43 @@ void i915_gem_request_free(struct kref *req_ref)
kfree(req);
}
+int i915_gem_request_alloc(struct intel_engine_cs *ring,
+ struct intel_context *ctx)
+{
+ int ret;
+ struct drm_i915_gem_request *request;
+ struct drm_i915_private *dev_private = ring-dev-dev_private;
+
+ if (ring-outstanding_lazy_request)
+ return 0;
+
+ request = kzalloc(sizeof(*request), GFP_KERNEL);
+ if (request == NULL)
+ return -ENOMEM;
+
+ ret = i915_gem_get_seqno(ring-dev, request-seqno);
+ if (ret) {
+ kfree(request);
+ return ret;
+ }
+
+ kref_init(request-ref);
+ request-ring = ring;
+ request-uniq = dev_private-request_uniq++;
+
+ if (i915.enable_execlists)
+ ret = intel_logical_ring_alloc_request_extras(request, ctx);
+ else
+ ret = intel_ring_alloc_request_extras(request);
+ if (ret) {
+ kfree(request);
+ return ret;
+ }
+
+ ring-outstanding_lazy_request = request;
+ return 0;
+}
+
struct drm_i915_gem_request *
i915_gem_find_active_request(struct intel_engine_cs *ring)
{
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cad4300..6504689 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -611,44 +611,21 @@ static int execlists_move_to_gpu(struct intel_ringbuffer
*ringbuf,
return logical_ring_invalidate_all_caches(ringbuf, ctx);
}
-static int logical_ring_alloc_request(struct intel_engine_cs *ring,
- struct intel_context *ctx)
+int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request,
+ struct intel_context *ctx)
{
- struct drm_i915_gem_request *request;
- struct drm_i915_private *dev_private = ring-dev-dev_private;
int ret;
- if (ring-outstanding_lazy_request)
- return 0;
-
- request = kzalloc(sizeof(*request), GFP_KERNEL);
- if (request == NULL)
- return -ENOMEM;
-
- if (ctx != ring-default_context) {
- ret = intel_lr_context_pin(ring, ctx);
- if (ret) {
- kfree(request);
+ if (ctx != request-ring-default_context) {
+ ret = intel_lr_context_pin(request-ring, ctx);
+ if (ret)
return ret;
- }
- }
-
- kref_init(request-ref);
- request-ring = ring;
- request-uniq = dev_private-request_uniq++;
-
- ret = i915_gem_get_seqno(ring-dev, request-seqno);
- if (ret) {
- intel_lr_context_unpin(ring, ctx);
- kfree(request);
- return ret;
}
- request-ctx = ctx;
+ request-ringbuf = ctx-engine[request-ring-id].ringbuf;
+ request-ctx = ctx;
i915_gem_context_reference(request-ctx);
- request-ringbuf = ctx-engine[ring-id].ringbuf;
- ring-outstanding_lazy_request = request;
return 0;
}
@@ -840,7 +817,7 @@ static int intel_logical_ring_begin(struct intel_ringbuffer
*ringbuf,
return ret;
/* Preallocate the olr before touching the ring */
- ret = logical_ring_alloc_request(ring, ctx);
+ ret = i915_gem_request_alloc(ring, ctx);
if
Re: [Intel-gfx] [PATCH] drm/i915: Fallback to using unmappable memory for scanout
On Thursday 19 March 2015 03:38 AM, Chris Wilson wrote: The existing ABI says that scanouts are pinned into the mappable region so that legacy clients (e.g. old Xorg or plymouthd) can write directly into the scanout through a GTT mapping. However if the surface does not fit into the mappable region, we are better off just trying to fit it anywhere and hoping for the best. (Any userspace that is cappable of using ginormous scanouts is also likely not to rely on pure GTT updates.) In the future, there may even be a kernel mediated method for the legacy clients. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Satyanantha, Rama Gopal M rama.gopal.m.satyanan...@intel.com Cc: Deepak S deepa...@linux.intel.com Cc: Damien Lespiau damien.lesp...@intel.com Cc: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_gem.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 9e498e0bbf22..9a1de848e450 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4034,10 +4034,15 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj, /* As the user may map the buffer once pinned in the display plane * (e.g. libkms for the bootup splash), we have to ensure that we -* always use map_and_fenceable for all scanout buffers. +* always use map_and_fenceable for all scanout buffers. However, +* it may simply be too big to fit into mappable, in which case +* put it anyway and hope that userspace can cope (but always first +* try to preserve the existing ABI). */ ret = i915_gem_obj_ggtt_pin(obj, alignment, PIN_MAPPABLE); if (ret) + ret = i915_gem_obj_ggtt_pin(obj, alignment, 0); + if (ret) goto err_unpin_display; Hi Chris, if we map the object into unmappable region. I think we should skip fence create ? Thanks Deepak i915_gem_object_flush_cpu_write_domain(obj); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Track page table reload need
From: Ben Widawsky benjamin.widaw...@intel.com
This patch was formerly known as, Force pd restore when PDEs change,
gen6-7. I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object is mapped
into the current address space. The GPU does not snoop the new mapping
so we must do the gen specific action to reload the page tables.
GEN8 and GEN7 do differ in the way they load page tables for the RCS.
GEN8 does so with the context restore, while GEN7 requires the proper
load commands in the command streamer. Non-render is similar for both.
Caveat for GEN7
The docs say you cannot change the PDEs of a currently running context.
We never map new PDEs of a running context, and expect them to be
present - so I think this is okay. (We can unmap, but this should also
be okay since we only unmap unreferenced objects that the GPU shouldn't
be tryingto va-pa xlate.) The MI_SET_CONTEXT command does have a flag
to signal that even if the context is the same, force a reload. It's
unclear exactly what this does, but I have a hunch it's the right thing
to do.
The logic assumes that we always emit a context switch after mapping new
PDEs, and before we submit a batch. This is the case today, and has been
the case since the inception of hardware contexts. A note in the comment
let's the user know.
It's not just for gen8. If the current context has mappings change, we
need a context reload to switch
v2: Rebased after ppgtt clean up patches. Split the warning for aliasing
and true ppgtt options. And do not break aliasing ppgtt, where to-ppgtt
is always null.
v3: Invalidate PPGTT TLBs inside alloc_va_range.
v4: Rename ppgtt_invalidate_tlbs to mark_tlbs_dirty and move
pd_dirty_rings from i915_address_space to i915_hw_ppgtt. Fixes when
neither ctx-ppgtt and aliasing_ppgtt exist.
v5: Removed references to teardown_va_range.
v6: Updated needs_pd_load_pre/post.
v7: Fix pd_dirty_rings check in needs_pd_load_post, and update/move
comment about updated PDEs to object_pin/bind (Mika).
Cc: Mika Kuoppala mika.kuopp...@linux.intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+)
---
drivers/gpu/drm/i915/i915_gem.c| 4
drivers/gpu/drm/i915/i915_gem_context.c| 26 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 7 +++
drivers/gpu/drm/i915/i915_gem_gtt.c| 11 +++
drivers/gpu/drm/i915/i915_gem_gtt.h| 1 +
5 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 979dcb6..eefba9d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4247,6 +4247,10 @@ i915_gem_object_pin_view(struct drm_i915_gem_object *obj,
bound = vma ? vma-bound : 0;
if (vma == NULL || !drm_mm_node_allocated(vma-node)) {
+ /* In true PPGTT, bind has possibly changed PDEs, which
+* means we must do a context switch before the GPU can
+* accurately read some of the VMAs.
+*/
vma = i915_gem_object_bind_to_vm(obj, vm, alignment,
flags, view);
if (IS_ERR(vma))
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b6ea85d..dd9ab36 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -573,8 +573,20 @@ static inline bool should_skip_switch(struct
intel_engine_cs *ring,
struct intel_context *from,
struct intel_context *to)
{
- if (from == to !to-remap_slice)
- return true;
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
+
+ if (to-remap_slice)
+ return false;
+
+ if (to-ppgtt) {
+ if (from == to !test_bit(ring-id,
+ to-ppgtt-pd_dirty_rings))
+ return true;
+ } else if (dev_priv-mm.aliasing_ppgtt) {
+ if (from == to !test_bit(ring-id,
+ dev_priv-mm.aliasing_ppgtt-pd_dirty_rings))
+ return true;
+ }
return false;
}
@@ -610,10 +622,7 @@ needs_pd_load_post(struct intel_engine_cs *ring, struct
intel_context *to)
if (ring != dev_priv-ring[RCS])
return false;
- if (!to-legacy_hw_ctx.initialized)
- return true;
-
- if (i915_gem_context_is_default(to))
+ if (to-ppgtt-pd_dirty_rings)
return true;
return false;
@@ -664,6 +673,9 @@ static int do_switch(struct intel_engine_cs *ring,
ret = to-ppgtt-switch_mm(to-ppgtt, ring);
if (ret)
goto unpin_out;
+
+ /* Doing a PD load always
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Track page table reload need
On 3/19/2015 9:01 AM, Mika Kuoppala wrote:
Michel Thierry michel.thie...@intel.com writes:
From: Ben Widawsky benjamin.widaw...@intel.com
This patch was formerly known as, Force pd restore when PDEs change,
gen6-7. I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object is mapped
into the current address space. The GPU does not snoop the new mapping
so we must do the gen specific action to reload the page tables.
GEN8 and GEN7 do differ in the way they load page tables for the RCS.
GEN8 does so with the context restore, while GEN7 requires the proper
load commands in the command streamer. Non-render is similar for both.
Caveat for GEN7
The docs say you cannot change the PDEs of a currently running context.
We never map new PDEs of a running context, and expect them to be
present - so I think this is okay. (We can unmap, but this should also
be okay since we only unmap unreferenced objects that the GPU shouldn't
be tryingto va-pa xlate.) The MI_SET_CONTEXT command does have a flag
to signal that even if the context is the same, force a reload. It's
unclear exactly what this does, but I have a hunch it's the right thing
to do.
The logic assumes that we always emit a context switch after mapping new
PDEs, and before we submit a batch. This is the case today, and has been
the case since the inception of hardware contexts. A note in the comment
let's the user know.
It's not just for gen8. If the current context has mappings change, we
need a context reload to switch
v2: Rebased after ppgtt clean up patches. Split the warning for aliasing
and true ppgtt options. And do not break aliasing ppgtt, where to-ppgtt
is always null.
v3: Invalidate PPGTT TLBs inside alloc_va_range.
v4: Rename ppgtt_invalidate_tlbs to mark_tlbs_dirty and move
pd_dirty_rings from i915_address_space to i915_hw_ppgtt. Fixes when
neither ctx-ppgtt and aliasing_ppgtt exist.
v5: Removed references to teardown_va_range.
v6: Updated needs_pd_load_pre/post.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Michel Thierry michel.thie...@intel.com (v2+)
---
drivers/gpu/drm/i915/i915_gem_context.c| 26 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++
drivers/gpu/drm/i915/i915_gem_gtt.c| 11 +++
drivers/gpu/drm/i915/i915_gem_gtt.h| 1 +
4 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b6ea85d..9197ff4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -573,8 +573,20 @@ static inline bool should_skip_switch(struct
intel_engine_cs *ring,
struct intel_context *from,
struct intel_context *to)
{
- if (from == to !to-remap_slice)
- return true;
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
+
+ if (to-remap_slice)
+ return false;
+
+ if (to-ppgtt) {
+ if (from == to !test_bit(ring-id,
+ to-ppgtt-pd_dirty_rings))
+ return true;
+ } else if (dev_priv-mm.aliasing_ppgtt) {
+ if (from == to !test_bit(ring-id,
+ dev_priv-mm.aliasing_ppgtt-pd_dirty_rings))
+ return true;
+ }
return false;
}
@@ -610,10 +622,7 @@ needs_pd_load_post(struct intel_engine_cs *ring, struct
intel_context *to)
if (ring != dev_priv-ring[RCS])
return false;
- if (!to-legacy_hw_ctx.initialized)
- return true;
-
- if (i915_gem_context_is_default(to))
+ if (to-ppgtt-pd_dirty_rings)
if (to-ppgtt-pd_dirty_rings) ?
Sorry, wrong copy/paste from test/clear_bit functions.
return true;
return false;
@@ -664,6 +673,9 @@ static int do_switch(struct intel_engine_cs *ring,
ret = to-ppgtt-switch_mm(to-ppgtt, ring);
if (ret)
goto unpin_out;
+
+ /* Doing a PD load always reloads the page dirs */
+ clear_bit(ring-id, to-ppgtt-pd_dirty_rings);
}
if (ring != dev_priv-ring[RCS]) {
@@ -696,6 +708,8 @@ static int do_switch(struct intel_engine_cs *ring,
if (!to-legacy_hw_ctx.initialized || i915_gem_context_is_default(to))
hw_flags |= MI_RESTORE_INHIBIT;
+ else if (to-ppgtt test_and_clear_bit(ring-id,
to-ppgtt-pd_dirty_rings))
+ hw_flags |= MI_FORCE_RESTORE;
ret = mi_set_context(ring, to, hw_flags);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index dc10bc4..fd0241a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1187,6 +1187,13 @@
[Intel-gfx] [PATCH 49/59] drm/i915: Update intel_ring_begin() to take a request structure
From: John Harrison john.c.harri...@intel.com
Now that everything above has been converted to use requests, intel_ring_begin()
can be updated to take a request instead of a ring. This also means that it no
longer needs to lazily allocate a request if no-one happens to have done it
earlier.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c|2 +-
drivers/gpu/drm/i915/i915_gem_context.c|2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 +--
drivers/gpu/drm/i915/i915_gem_gtt.c|6 +--
drivers/gpu/drm/i915/intel_display.c | 10 ++--
drivers/gpu/drm/i915/intel_overlay.c |8 +--
drivers/gpu/drm/i915/intel_ringbuffer.c| 74 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h|2 +-
8 files changed, 55 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7304290..b047693 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4711,7 +4711,7 @@ int i915_gem_l3_remap(struct drm_i915_gem_request *req,
int slice)
if (!HAS_L3_DPF(dev) || !remap_info)
return 0;
- ret = intel_ring_begin(ring, GEN7_L3LOG_SIZE / 4 * 3);
+ ret = intel_ring_begin(req, GEN7_L3LOG_SIZE / 4 * 3);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 2c94c88..369e58d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -507,7 +507,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32
hw_flags)
if (INTEL_INFO(ring-dev)-gen = 7)
len += 2 + (num_rings ? 4*num_rings + 2 : 0);
- ret = intel_ring_begin(ring, len);
+ ret = intel_ring_begin(req, len);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index cb24ca7..9345db8 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1076,7 +1076,7 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
return -EINVAL;
}
- ret = intel_ring_begin(ring, 4 * 3);
+ ret = intel_ring_begin(req, 4 * 3);
if (ret)
return ret;
@@ -1107,7 +1107,7 @@ i915_emit_box(struct drm_i915_gem_request *req,
}
if (INTEL_INFO(ring-dev)-gen = 4) {
- ret = intel_ring_begin(ring, 4);
+ ret = intel_ring_begin(req, 4);
if (ret)
return ret;
@@ -1116,7 +1116,7 @@ i915_emit_box(struct drm_i915_gem_request *req,
intel_ring_emit(ring, ((box-x2 - 1) 0x) | (box-y2 - 1)
16);
intel_ring_emit(ring, DR4);
} else {
- ret = intel_ring_begin(ring, 6);
+ ret = intel_ring_begin(req, 6);
if (ret)
return ret;
@@ -1287,7 +1287,7 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
if (ring == dev_priv-ring[RCS]
instp_mode != dev_priv-relative_constants_mode) {
- ret = intel_ring_begin(ring, 4);
+ ret = intel_ring_begin(params-request, 4);
if (ret)
goto error;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5822429..7b656c8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -382,7 +382,7 @@ static int gen8_write_pdp(struct drm_i915_gem_request *req,
unsigned entry,
BUG_ON(entry = 4);
- ret = intel_ring_begin(ring, 6);
+ ret = intel_ring_begin(req, 6);
if (ret)
return ret;
@@ -889,7 +889,7 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
if (ret)
return ret;
- ret = intel_ring_begin(ring, 6);
+ ret = intel_ring_begin(req, 6);
if (ret)
return ret;
@@ -926,7 +926,7 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
if (ret)
return ret;
- ret = intel_ring_begin(ring, 6);
+ ret = intel_ring_begin(req, 6);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 277c73a..665e8cc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9426,7 +9426,7 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
u32 flip_mask;
int ret;
- ret = intel_ring_begin(ring, 6);
+ ret = intel_ring_begin(req, 6);
if (ret)
return ret;
@@ -9461,7 +9461,7 @@ static int intel_gen3_queue_flip(struct drm_device *dev,
u32 flip_mask;
int ret;
[Intel-gfx] [PATCH 40/59] drm/i915: Update some flush helpers to take request structures
From: John Harrison john.c.harri...@intel.com
Updated intel_emit_post_sync_nonzero_flush(), gen7_render_ring_cs_stall_wa() and
gen8_emit_pipe_control() to take requests instead of rings.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a29fa40..bbba27d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -214,8 +214,9 @@ gen4_render_ring_flush(struct drm_i915_gem_request *req,
* really our business. That leaves only stall at scoreboard.
*/
static int
-intel_emit_post_sync_nonzero_flush(struct intel_engine_cs *ring)
+intel_emit_post_sync_nonzero_flush(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
u32 scratch_addr = ring-scratch.gtt_offset + 2 * CACHELINE_BYTES;
int ret;
@@ -258,7 +259,7 @@ gen6_render_ring_flush(struct drm_i915_gem_request *req,
int ret;
/* Force SNB workarounds for PIPE_CONTROL flushes */
- ret = intel_emit_post_sync_nonzero_flush(ring);
+ ret = intel_emit_post_sync_nonzero_flush(req);
if (ret)
return ret;
@@ -302,8 +303,9 @@ gen6_render_ring_flush(struct drm_i915_gem_request *req,
}
static int
-gen7_render_ring_cs_stall_wa(struct intel_engine_cs *ring)
+gen7_render_ring_cs_stall_wa(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
ret = intel_ring_begin(ring, 4);
@@ -366,7 +368,7 @@ gen7_render_ring_flush(struct drm_i915_gem_request *req,
/* Workaround: we must issue a pipe_control with CS-stall bit
* set before a pipe_control command that has the state cache
* invalidate bit set. */
- gen7_render_ring_cs_stall_wa(ring);
+ gen7_render_ring_cs_stall_wa(req);
}
ret = intel_ring_begin(ring, 4);
@@ -383,9 +385,10 @@ gen7_render_ring_flush(struct drm_i915_gem_request *req,
}
static int
-gen8_emit_pipe_control(struct intel_engine_cs *ring,
+gen8_emit_pipe_control(struct drm_i915_gem_request *req,
u32 flags, u32 scratch_addr)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
ret = intel_ring_begin(ring, 6);
@@ -407,9 +410,8 @@ static int
gen8_render_ring_flush(struct drm_i915_gem_request *req,
u32 invalidate_domains, u32 flush_domains)
{
- struct intel_engine_cs *ring = req-ring;
u32 flags = 0;
- u32 scratch_addr = ring-scratch.gtt_offset + 2 * CACHELINE_BYTES;
+ u32 scratch_addr = req-ring-scratch.gtt_offset + 2 * CACHELINE_BYTES;
int ret;
flags |= PIPE_CONTROL_CS_STALL;
@@ -429,7 +431,7 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
/* WaCsStallBeforeStateCacheInvalidate:bdw,chv */
- ret = gen8_emit_pipe_control(ring,
+ ret = gen8_emit_pipe_control(req,
PIPE_CONTROL_CS_STALL |
PIPE_CONTROL_STALL_AT_SCOREBOARD,
0);
@@ -437,7 +439,7 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req,
return ret;
}
- return gen8_emit_pipe_control(ring, flags, scratch_addr);
+ return gen8_emit_pipe_control(req, flags, scratch_addr);
}
static void ring_write_tail(struct intel_engine_cs *ring,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 57/59] drm/i915: Update a bunch of LRC functions to take requests
From: John Harrison john.c.harri...@intel.com
A bunch of the low level LRC functions were passing around ringbuf and ctx
pairs. In a few cases, they took the r/c pair and a request as well. This is all
quite messy and unnecesary. The context_queue() call is especially bad since the
fake request code got removed - it takes a request and three extra things that
must be extracted from the request and then it checks them against what it finds
in the request. Removing all the derivable data makes the code much simpler all
round.
This patch updates those functions to just take the request structure.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 66 +-
1 file changed, 29 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 82190ad..ae00054 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -494,25 +494,20 @@ void intel_lrc_irq_handler(struct intel_engine_cs *ring)
((u32)ring-next_context_status_buffer 0x07) 8);
}
-static int execlists_context_queue(struct intel_engine_cs *ring,
- struct intel_context *to,
- u32 tail,
- struct drm_i915_gem_request *request)
+static int execlists_context_queue(struct drm_i915_gem_request *request)
{
+ struct intel_engine_cs *ring = request-ring;
struct drm_i915_gem_request *cursor;
struct drm_i915_private *dev_priv = ring-dev-dev_private;
unsigned long flags;
int num_elements = 0;
- if (to != ring-default_context)
- intel_lr_context_pin(ring, to);
-
- WARN_ON(!request);
- WARN_ON(to != request-ctx);
+ if (request-ctx != ring-default_context)
+ intel_lr_context_pin(ring, request-ctx);
i915_gem_request_reference(request);
- request-tail = tail;
+ request-tail = request-ringbuf-tail;
intel_runtime_pm_get(dev_priv);
@@ -529,7 +524,7 @@ static int execlists_context_queue(struct intel_engine_cs
*ring,
struct drm_i915_gem_request,
execlist_link);
- if (to == tail_req-ctx) {
+ if (request-ctx == tail_req-ctx) {
WARN(tail_req-elsp_submitted != 0,
More than 2 already-submitted reqs queued\n);
list_del(tail_req-execlist_link);
@@ -610,12 +605,12 @@ int intel_logical_ring_alloc_request_extras(struct
drm_i915_gem_request *request
return 0;
}
-static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx,
+static int logical_ring_wait_for_space(struct drm_i915_gem_request *req,
int bytes)
{
- struct intel_engine_cs *ring = ringbuf-ring;
- struct drm_i915_gem_request *request;
+ struct intel_ringbuffer *ringbuf = req-ringbuf;
+ struct intel_engine_cs *ring = req-ring;
+ struct drm_i915_gem_request *target;
int ret, new_space;
/* The whole point of reserving space is to not wait! */
@@ -624,30 +619,30 @@ static int logical_ring_wait_for_space(struct
intel_ringbuffer *ringbuf,
if (intel_ring_space(ringbuf) = bytes)
return 0;
- list_for_each_entry(request, ring-request_list, list) {
+ list_for_each_entry(target, ring-request_list, list) {
/*
* The request queue is per-engine, so can contain requests
* from multiple ringbuffers. Here, we must ignore any that
* aren't from the ringbuffer we're considering.
*/
- struct intel_context *ctx = request-ctx;
+ struct intel_context *ctx = target-ctx;
if (ctx-engine[ring-id].ringbuf != ringbuf)
continue;
/* Would completion of this request free enough space? */
- new_space = __intel_ring_space(request-postfix, ringbuf-tail,
+ new_space = __intel_ring_space(target-postfix, ringbuf-tail,
ringbuf-size);
if (new_space = bytes)
break;
}
/* It should always be possible to find a suitable request! */
- if (request-list == ring-request_list) {
+ if (target-list == ring-request_list) {
WARN_ON(true);
return -ENOSPC;
}
- ret = i915_wait_request(request);
+ ret = i915_wait_request(target);
if (ret)
return ret;
@@ -660,7 +655,7 @@ static int logical_ring_wait_for_space(struct
intel_ringbuffer *ringbuf,
/*
*
[Intel-gfx] [PATCH 45/59] drm/i915: Update ring-emit_bb_start() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the ring-emit_bb_start() implementation to take a request instead of a
ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 12 +---
drivers/gpu/drm/i915/intel_ringbuffer.h |3 +--
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 24a4816..cdbe514 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -931,7 +931,7 @@ int intel_execlists_submission(struct
i915_execbuffer_params *params,
exec_start = params-batch_obj_vm_offset +
args-batch_start_offset;
- ret = ring-emit_bb_start(ringbuf, params-ctx, exec_start,
params-dispatch_flags);
+ ret = ring-emit_bb_start(params-request, exec_start,
params-dispatch_flags);
if (ret)
return ret;
@@ -1146,14 +1146,14 @@ static int gen9_init_render_ring(struct intel_engine_cs
*ring)
return init_workarounds_ring(ring);
}
-static int gen8_emit_bb_start(struct intel_ringbuffer *ringbuf,
- struct intel_context *ctx,
+static int gen8_emit_bb_start(struct drm_i915_gem_request *req,
u64 offset, unsigned dispatch_flags)
{
+ struct intel_ringbuffer *ringbuf = req-ringbuf;
bool ppgtt = !(dispatch_flags I915_DISPATCH_SECURE);
int ret;
- ret = intel_logical_ring_begin(ringbuf, ctx, 4);
+ ret = intel_logical_ring_begin(ringbuf, req-ctx, 4);
if (ret)
return ret;
@@ -1333,9 +1333,7 @@ static int intel_lr_context_render_state_init(struct
drm_i915_gem_request *req)
if (so.rodata == NULL)
return 0;
- ret = req-ring-emit_bb_start(req-ringbuf,
- req-ctx,
- so.ggtt_offset,
+ ret = req-ring-emit_bb_start(req, so.ggtt_offset,
I915_DISPATCH_SECURE);
if (ret)
goto out;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 9f008d1..2d1d8a6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -240,8 +240,7 @@ struct intel_engine_cs {
int (*emit_flush)(struct drm_i915_gem_request *request,
u32 invalidate_domains,
u32 flush_domains);
- int (*emit_bb_start)(struct intel_ringbuffer *ringbuf,
-struct intel_context *ctx,
+ int (*emit_bb_start)(struct drm_i915_gem_request *req,
u64 offset, unsigned dispatch_flags);
/**
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/59] drm/i915: Update i915_switch_context() to take a request structure
From: John Harrison john.c.harri...@intel.com
Now that the request is guaranteed to specify the context, it is possible to
update the context switch code to use requests rather than ring and context
pairs. This patch updates i915_switch_context() accordingly.
Also removed the warning that the request's context must match the last context
switch's context. As the context switch now gets the context object from the
request structure, there is no longer any scope for the two to become out of
step.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|3 +--
drivers/gpu/drm/i915/i915_gem.c|4 +---
drivers/gpu/drm/i915/i915_gem_context.c| 19 +--
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
4 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e139f0e..ca070d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2892,8 +2892,7 @@ void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
int i915_gem_context_enable(struct drm_i915_gem_request *req);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
-int i915_switch_context(struct intel_engine_cs *ring,
- struct intel_context *to);
+int i915_switch_context(struct drm_i915_gem_request *req);
struct intel_context *
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
void i915_gem_context_free(struct kref *ctx_ref);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9d776a5..0a25461 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2396,8 +2396,6 @@ void __i915_add_request(struct intel_engine_cs *ring,
*/
request-batch_obj = obj;
- WARN_ON(!i915.enable_execlists (request-ctx != ring-last_context));
-
request-emitted_jiffies = jiffies;
list_add_tail(request-list, ring-request_list);
request-file_priv = NULL;
@@ -3121,7 +3119,7 @@ int i915_gpu_idle(struct drm_device *dev)
if (ret)
return ret;
- ret = i915_switch_context(req-ring,
ring-default_context);
+ ret = i915_switch_context(req);
if (ret) {
i915_gem_request_cancel(req);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 647b48d..26d5816 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -418,7 +418,7 @@ int i915_gem_context_enable(struct drm_i915_gem_request
*req)
ret = ring-init_context(ring, ring-default_context);
} else
- ret = i915_switch_context(ring, ring-default_context);
+ ret = i915_switch_context(req);
if (ret) {
DRM_ERROR(ring init context: %d\n, ret);
@@ -697,8 +697,7 @@ unpin_out:
/**
* i915_switch_context() - perform a GPU context switch.
- * @ring: ring for which we'll execute the context switch
- * @to: the context to switch to
+ * @req: request for which we'll execute the context switch
*
* The context life cycle is simple. The context refcount is incremented and
* decremented by 1 and create and destroy. If the context is in use by the
GPU,
@@ -709,25 +708,25 @@ unpin_out:
* switched by writing to the ELSP and requests keep a reference to their
* context.
*/
-int i915_switch_context(struct intel_engine_cs *ring,
- struct intel_context *to)
+int i915_switch_context(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
struct drm_i915_private *dev_priv = ring-dev-dev_private;
WARN_ON(i915.enable_execlists);
WARN_ON(!mutex_is_locked(dev_priv-dev-struct_mutex));
- if (to-legacy_hw_ctx.rcs_state == NULL) { /* We have the fake context
*/
- if (to != ring-last_context) {
- i915_gem_context_reference(to);
+ if (req-ctx-legacy_hw_ctx.rcs_state == NULL) { /* We have the fake
context */
+ if (req-ctx != ring-last_context) {
+ i915_gem_context_reference(req-ctx);
if (ring-last_context)
i915_gem_context_unreference(ring-last_context);
- ring-last_context = to;
+ ring-last_context = req-ctx;
}
return 0;
}
- return do_switch(ring, to);
+ return do_switch(req-ring, req-ctx);
}
static bool contexts_enabled(struct drm_device *dev)
diff --git
[Intel-gfx] [PATCH 42/59] drm/i915: Update ring-add_request() to take a request structure
From: John Harrison john.c.harri...@intel.com
Updated the various ring-add_request() implementations to take a request
instead of a ring. This removes their reliance on the OLR to obtain the seqno
value that the request should be tagged with.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 --
drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 95ed3a8..dd5c1d8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2380,7 +2380,7 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
if (i915.enable_execlists)
ret = ring-emit_request(ringbuf, request);
else
- ret = ring-add_request(ring);
+ ret = ring-add_request(request);
/* Not allowed to fail! */
WARN_ON(ret);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index bbba27d..0e55baf 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1239,16 +1239,16 @@ static int gen6_signal(struct intel_engine_cs
*signaller,
/**
* gen6_add_request - Update the semaphore mailbox registers
- *
- * @ring - ring that is adding a request
- * @seqno - return seqno stuck into the ring
+ *
+ * @request - request to write to the ring
*
* Update the mailbox registers in the *other* rings with the current seqno.
* This acts like a signal in the canonical semaphore.
*/
static int
-gen6_add_request(struct intel_engine_cs *ring)
+gen6_add_request(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
if (ring-semaphore.signal)
@@ -1261,8 +1261,7 @@ gen6_add_request(struct intel_engine_cs *ring)
intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
intel_ring_emit(ring, I915_GEM_HWS_INDEX MI_STORE_DWORD_INDEX_SHIFT);
- intel_ring_emit(ring,
- i915_gem_request_get_seqno(ring-outstanding_lazy_request));
+ intel_ring_emit(ring, i915_gem_request_get_seqno(req));
intel_ring_emit(ring, MI_USER_INTERRUPT);
__intel_ring_advance(ring);
@@ -1359,8 +1358,9 @@ do {
\
} while (0)
static int
-pc_render_add_request(struct intel_engine_cs *ring)
+pc_render_add_request(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
u32 scratch_addr = ring-scratch.gtt_offset + 2 * CACHELINE_BYTES;
int ret;
@@ -1380,8 +1380,7 @@ pc_render_add_request(struct intel_engine_cs *ring)
PIPE_CONTROL_WRITE_FLUSH |
PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE);
intel_ring_emit(ring, ring-scratch.gtt_offset |
PIPE_CONTROL_GLOBAL_GTT);
- intel_ring_emit(ring,
- i915_gem_request_get_seqno(ring-outstanding_lazy_request));
+ intel_ring_emit(ring, i915_gem_request_get_seqno(req));
intel_ring_emit(ring, 0);
PIPE_CONTROL_FLUSH(ring, scratch_addr);
scratch_addr += 2 * CACHELINE_BYTES; /* write to separate cachelines */
@@ -1400,8 +1399,7 @@ pc_render_add_request(struct intel_engine_cs *ring)
PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
PIPE_CONTROL_NOTIFY);
intel_ring_emit(ring, ring-scratch.gtt_offset |
PIPE_CONTROL_GLOBAL_GTT);
- intel_ring_emit(ring,
- i915_gem_request_get_seqno(ring-outstanding_lazy_request));
+ intel_ring_emit(ring, i915_gem_request_get_seqno(req));
intel_ring_emit(ring, 0);
__intel_ring_advance(ring);
@@ -1570,8 +1568,9 @@ bsd_ring_flush(struct drm_i915_gem_request *req,
}
static int
-i9xx_add_request(struct intel_engine_cs *ring)
+i9xx_add_request(struct drm_i915_gem_request *req)
{
+ struct intel_engine_cs *ring = req-ring;
int ret;
ret = intel_ring_begin(ring, 4);
@@ -1580,8 +1579,7 @@ i9xx_add_request(struct intel_engine_cs *ring)
intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
intel_ring_emit(ring, I915_GEM_HWS_INDEX MI_STORE_DWORD_INDEX_SHIFT);
- intel_ring_emit(ring,
- i915_gem_request_get_seqno(ring-outstanding_lazy_request));
+ intel_ring_emit(ring, i915_gem_request_get_seqno(req));
intel_ring_emit(ring, MI_USER_INTERRUPT);
__intel_ring_advance(ring);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 94182de..9641634 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -153,7 +153,7 @@ struct intel_engine_cs {
[Intel-gfx] [PATCH 3/3] drm/i915: DP link training optimization
This patch adds fast link training support if BDB version
is equal or higher than 182 and the feature is supported
in VBT.
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 4
drivers/gpu/drm/i915/intel_bios.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 17 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
5 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb38cd1..f4e413e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1349,6 +1349,7 @@ struct intel_vbt_data {
bool edp_support;
int edp_bpp;
bool edp_low_vswing;
+ bool edp_flt_enabled;
struct edp_power_seq edp_pps;
struct {
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index c684085..8262195 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -669,6 +669,10 @@ parse_edp(struct drm_i915_private *dev_priv, struct
bdb_header *bdb)
vswing = (edp-edp_vswing_preemph (panel_type * 4)) 0xF;
dev_priv-vbt.edp_low_vswing = vswing == 0;
}
+
+ /* support for fast link training */
+ if (bdb-version = 182)
+ dev_priv-vbt.edp_flt_enabled = (edp-edp_flt_enabled
panel_type) 0x1;
}
static void
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 6afd5be..fad7ff7 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -555,6 +555,7 @@ struct bdb_edp {
u16 edp_s3d_feature;
u16 edp_t3_optimization;
u64 edp_vswing_preemph; /* v173 */
+ u16 edp_flt_enabled;/* v182 */
} __packed;
struct psr_table {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f7720c..fbe97a9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3472,7 +3472,20 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp, uint32_t *DP,
uint8_t dp_train_pat)
{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int i;
+
memset(intel_dp-train_set, 0, sizeof(intel_dp-train_set));
+
+ /* eDP case */
+ if (intel_dp-edp_use_vbt_train_set dev_priv-vbt.edp_flt_enabled) {
+ for (i = 0; i intel_dp-lane_count; i++)
+ intel_dp-train_set[i] = dev_priv-vbt.edp_vswing |
+ dev_priv-vbt.edp_preemphasis;
+ }
+
intel_dp_set_signal_levels(intel_dp, DP);
return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
}
@@ -3580,6 +3593,9 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP |= DP_PORT_EN;
+ /* for eDP use link train set from VBT */
+ intel_dp-edp_use_vbt_train_set = is_edp(intel_dp);
+
/*
* check if eDP has already trained. Reset voltage swing and
* pre-emphasis levels if that's not the case.
@@ -3624,6 +3640,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
*/
if (intel_dp-link_trained) {
DRM_DEBUG_KMS(clock recovery not ok, reset);
+ intel_dp-edp_use_vbt_train_set = false;
if (!intel_dp_reset_link_train(intel_dp, DP,
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ba6eda1..fc692e3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -673,6 +673,7 @@ struct intel_dp {
int send_bytes,
uint32_t aux_clock_divider);
bool link_trained;
+ bool edp_use_vbt_train_set;
};
struct intel_digital_port {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv
On Thursday 19 March 2015 05:14 PM, David Weinehall wrote: On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some of the baytrail systems :(. Switching back to legacy mode rps. Is there any way to identify either what systems it's OK to use on, or to identif what Baytrail systems it isn't OK to use on? Just reverting this completely seems overly broad if it's possible to tell the difference between working and non-working systems. Kind regards, David Weinehall Restricting the changes to few system will be the right way to go. How do we get details of now working system? - Deepak ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Keep ring-active_list and ring-requests_list consistent
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5996 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 272/272 272/272 ILK 301/301 301/301 SNB 303/303 303/303 IVB 342/342 342/342 BYT 287/287 287/287 HSW 362/362 362/362 BDW 308/308 308/308 -Detailed- Platform Testdrm-intel-nightly Series Applied Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some of the baytrail systems :(. Switching back to legacy mode rps. Do we want to throw out the actual code as well then? Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012 Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_irq.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 6d8340d..7bbdede 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) INIT_WORK(dev_priv-l3_parity.error_work, ivybridge_parity_work); /* Let's track the enabled rps events */ - if (IS_VALLEYVIEW(dev_priv) !IS_CHERRYVIEW(dev_priv)) - /* WaGsvRC0ResidencyMethod:vlv */ - dev_priv-pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; - else - dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; + dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; INIT_DELAYED_WORK(dev_priv-gpu_error.hangcheck_work, i915_hangcheck_elapsed); -- 1.9.1 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv
On Thursday 19 March 2015 04:48 PM, Ville Syrjälä wrote: On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some of the baytrail systems :(. Switching back to legacy mode rps. Do we want to throw out the actual code as well then? Chris as cleaned up patches for VLV rps WA. I think its worth a try Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012 Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_irq.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 6d8340d..7bbdede 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) INIT_WORK(dev_priv-l3_parity.error_work, ivybridge_parity_work); /* Let's track the enabled rps events */ - if (IS_VALLEYVIEW(dev_priv) !IS_CHERRYVIEW(dev_priv)) - /* WaGsvRC0ResidencyMethod:vlv */ - dev_priv-pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED; - else - dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; + dev_priv-pm_rps_events = GEN6_PM_RPS_EVENTS; INIT_DELAYED_WORK(dev_priv-gpu_error.hangcheck_work, i915_hangcheck_elapsed); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Beignet] Preventing zero GPU virtual address allocation
Yeah my big concern was with not making this opt-in like the old patch or adding an interface which does a lot more than what we need right now (Chris' patch). Just a bitflag to ask for this seems best and is fine with me. And for the implementation I think we should reuse the PIN_BIAS logic since that'll work in all places where it's possible. One open from my side is how we should handle failures to move buffers (in case they ended up at 0 somehow) - we can either silently fail or return an error to userspace. Note that this is only possible if you render to an elg image from ocl, and if that egl image is a pinned frontbuffer and if we don't have full ppgtt support. I don't know what the spec requires us to do here, or whether we should care at all. So the situation you mentioned only comes up when a pinned buffer under global gtt? Under global gtt, a buffer would rarely binded at offset 0, in fact the most often cases are under ppgtt. So, I think silent ignore moving pinned buffer under gtt is acceptable. I will add the check for the binded at zero case in beignet. Ruiling -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Beignet mailing list beig...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
