On 30/11/15 17:11, Chris Wilson wrote:
On Mon, Nov 30, 2015 at 06:53:06PM +0200, Mika Kuoppala wrote:
Some operations that happen in ringbuffer, like flushing,
can take significant amounts of time. After some intense
shader tests, the PIPE_CONTROL with flush can apparently last
longer time than
the multiple places where
object content is updated by the host CPU.
It also incorporates and supercedes Alex Dai's earlier patch
[PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted
Signed-off-by: Dave Gordon
Cc: Chris Wilson
Cc: Alex Dai
---
drivers/gpu/drm
On 01/12/15 13:04, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, the object should be
marked dirty, to ensure that the modifications are not
On 30/11/15 10:06, Tvrtko Ursulin wrote:
On 29/11/15 08:48, Chris Wilson wrote:
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
s
On 01/12/15 15:58, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 03:47:34PM +, Dave Gordon wrote:
On 30/11/15 10:06, Tvrtko Ursulin wrote:
On 29/11/15 08:48, Chris Wilson wrote:
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently
On 29/11/15 08:48, Chris Wilson wrote:
We have testcases to ensure that seqno wraparound works fine, so we can
forgo forcing everyone to encounter seqno wraparound during early
uptime. seqno wraparound incurs a full GPU stall so not forcing it
will eliminate one jitter from the early system.
Adv
On 30/11/15 14:18, Chris Wilson wrote:
On Mon, Nov 30, 2015 at 01:32:16PM +, Tvrtko Ursulin wrote:
On 30/11/15 12:30, Chris Wilson wrote:
On Mon, Nov 30, 2015 at 12:05:50PM +, Tvrtko Ursulin wrote:
+ struct intel_breadcrumbs {
+ spinlock_t lock; /* protects the per
On 28/10/15 12:08, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
A call to i915_gem_obj_ggtt_pin is being made after this, which again
calls the get_pages function. Hence removing the redundant call to
get_pages.
Signed-off-by: Ankitprasad Sharma
---
drivers/gpu/drm/i915/i9
On 30/11/15 14:34, Chris Wilson wrote:
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results, but e
On 25/11/15 09:23, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
/* Iterate over initialised rings */
#define for_each_ring(ring__
On 02/12/15 13:46, Chris Wilson wrote:
On Wed, Dec 02, 2015 at 01:29:21PM +, Dave Gordon wrote:
On 25/11/15 09:23, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07
On 02/12/15 14:58, Chris Wilson wrote:
On Wed, Dec 02, 2015 at 02:51:17PM +, Dave Gordon wrote:
Or, put the active ones on a linked list, or keep a bitmask of which
ones have been initialised inside the dev_priv structure, so you
don't have to even dereference the engine[] array to wor
k in the
previous review cycle, but the code looks OK so
Reviewed-by: Dave Gordon
and here's a suggestion for the commit message, with a
bit more background and more 'why' rather than 'what':
: For now, remove the spinlocks that protected the GuC's
: statistics block
On 06/10/15 12:53, Chris Wilson wrote:
On Tue, Oct 06, 2015 at 12:21:05PM +0100, Dave Gordon wrote:
... although I still think my version is (slightly) easier to read.
Or it could be improved even more by moving the increment of 'iter'
to the end, making it one line shorter and perha
On 03/12/15 21:35, Chris Wilson wrote:
On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote:
On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote:
On Thu, 03 Dec 2015 21:33:29 +0100,
Ville Syrjälä wrote:
On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
Hi,
I've
On 04/12/15 09:57, Daniel Vetter wrote:
On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote:
On 01/12/15 13:04, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and
On 07/12/15 08:29, Daniel Vetter wrote:
On Fri, Dec 04, 2015 at 05:28:29PM +, Dave Gordon wrote:
On 04/12/15 09:57, Daniel Vetter wrote:
On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote:
On 01/12/15 13:04, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave
On 01/12/15 12:42, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, the object should be
marked dirty, to ensure that the modifications are not discarded if the
object is evicted under memory pressure.
This
On 07/12/15 16:48, Johannes Weiner wrote:
On Mon, Dec 07, 2015 at 02:48:12PM +0100, Michal Hocko wrote:
On Fri 04-12-15 15:58:53, Chris Wilson wrote:
Some modules, like i915.ko, use swappable objects and may try to swap
them out under memory pressure (via the shrinker). Before doing so, they
wa
On 07/12/15 19:13, Johannes Weiner wrote:
On Mon, Dec 07, 2015 at 06:10:00PM +, Dave Gordon wrote:
Exporting random uncontrolled variables from the kernel to loaded modules is
not really considered best practice. It would be preferable to provide an
accessor function - which is just what
Way back at the beginning of October, Chris Wilson suggested that cleaning
up these macros by removing the redundant 'temp' might be worthwhile. So
here's the patch.
There's one more thing that might be cleaned up here (but for which
I don't have a patch yet), which is that gen8_for_each_pdpe() st
;temp' variable for both inner and outer instances. It's quite
surprising that this didn't introduce bugs! But it does show that the
value of 'temp' isn't required to persist during the iterated body.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem_gtt.c |
On 08/12/15 14:33, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 02:03:39PM +, Tvrtko Ursulin wrote:
On 08/12/15 10:44, Chris Wilson wrote:
On Mon, Dec 07, 2015 at 03:08:28PM +, Tvrtko Ursulin wrote:
Equally, why wouldn't we wake up all waiters for which the requests
have been completed?
drm/i915/bdw: Generic logical ring init and cleanup
Signed-off-by: Chris Wilson
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c| 17 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 39 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h
Based on Chris Wilson's patch from 6 months ago, rebased and adapted.
The idea is to use ring->dev as an indicator showing which engines have
been initialised and are therefore to be included in iterations that use
for_each_ring(). This allows us to avoid multiple memory references and
a (non-inli
This patchset covers three variations on GEM objects being dirtied by
means of CPU writes.
The first is simple: an object has been entirely filled with data via
CPU writes, and the whole object is therefore dirty (i.e. backing store
is out-of-date w.r.t. current contents). For these cases, marking
marking only
specific pages of the object as dirty (for objects backed by shmfs
pages); but for now let's ensure correctness by dirtying the whole
object.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 4 +++-
drivers/gpu/drm/i915/i915_gem_dmabuf.
like to mark only the updated pages dirty; but it
isn't clear at this point whether this will work for all types of GEM
objects (regular/gtt, phys, stolen, userptr, dmabuf, ...). So for now,
let's ensure correctness by marking the whole object dirty.
Signed-off-by: Dave Gordon
Cc: Ch
5/guc: Fix a fw content lost issue after it is evicted
Signed-off-by: Dave Gordon
Cc: Chris Wilson
Cc: Alex Dai
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 1 +
drivers/gpu/drm/i915/i915_gem.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser
On 08/12/15 17:00, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 04:51:16PM +, Dave Gordon wrote:
In various places, a GEM object is filled with data by means of CPU
writes. In such cases, the object should be marked dirty, to ensure that
the data is not discarded if the object is evicted
On 08/12/15 17:03, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 04:51:18PM +, Dave Gordon wrote:
This patch covers a couple more places where a GEM object is (or may be)
modified by means of CPU writes, and should therefore be marked dirty to
ensure that the changes are not lost in the
On 08/12/15 17:00, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 04:51:17PM +, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, either the page or the the
object should be marked dirty, to ensure that the
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
regio
This patchset covers various places where GEM objects are dirtied by
means of CPU writes.
The first patch covers cases where only one page is actually written;
here we can mark just the specific page in the pagecache dirty. This
applies to regular (shmfs-backed) objects only.
The second patch cov
updated in this way --
the objects in question are contexts and batchbuffers, which are always
shmfs-backed.
A separate patch deals with the case where whole objects are (or may
be) dirtied.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3
pressure.
The cases where only a single page is touched are dealt with in a
separate patch.
This incorporates and supercedes Alex Dai's earlier patch
[PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted
Signed-off-by: Dave Gordon
Cc: Alex Dai
Cc: Chris Wilson
---
drivers/gp
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
Ville reminded us that stolen memory is not preserved across
hibernation, and a result of this was that context objects now being
allocated from stolen were being corrupted on S4 and promptly hanging
the GPU on resume.
On 09/12/15 16:15, Tvrtko Ursulin wrote:
Hi,
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover
On 25/11/15 09:23, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
/* Iterate over initialised rings */
#define for_each_ring(ring__
On 10/12/15 14:06, Daniel Vetter wrote:
On Wed, Dec 09, 2015 at 03:52:52PM +, Dave Gordon wrote:
In a few places, we fill a GEM object with data, or overwrite some
portion of its contents other than a single page. In such cases, we
should mark the object dirty so that its pages in the
On 09/12/15 18:50, yu@intel.com wrote:
From: Alex Dai
Split GuC work queue space reserve from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle
On 10/12/15 13:29, Chris Wilson wrote:
On Wed, Dec 09, 2015 at 03:52:51PM +, Dave Gordon wrote:
In various places, a single page of a (regular) GEM object is mapped into
CPU address space and updated. In each such case, either the page or the
the object should be marked dirty, to ensure
On 10/12/15 16:43, Tvrtko Ursulin wrote:
Hi,
On 10/12/15 14:58, Mika Kuoppala wrote:
We get build error as we try to cast from ptr to integer
of different size on 32 bit platforms. Use unsigned long
as the cast, it will work with both 32 and 64 bit
systems.
Cc: Vinay Belgaumkar
Signed-off-by
On 10/12/15 14:15, Tvrtko Ursulin wrote:
On 10/12/15 13:17, Ankitprasad Sharma wrote:
On Thu, 2015-12-10 at 09:43 +, Tvrtko Ursulin wrote:
Hi,
Two more comments below:
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
Ville reminded us that stolen memory is n
On 10/12/15 11:12, Ankitprasad Sharma wrote:
On Wed, 2015-12-09 at 19:39 +, Dave Gordon wrote:
On 09/12/15 16:15, Tvrtko Ursulin wrote:
Hi,
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite
Another reworking of this patchset. Changes since v2 include:
* added two more calls to get_dirty_page() in the relocation code
[Chris Wilson]
* split the remaining changes into multiple tiny patches
[Chris Wilson]
* reinstated setting obj->dirty in i915_gem_begin_cpu_access()
Wilson]
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem.c | 15 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8
drivers/gpu/drm/i915/i915_gem_render_state.c | 2
an (unsigned int) bitfield, let's not treat it as a bool.
Maybe it should be a byte instead?
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +++
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 3 +++
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
3 files changed, 7
over
every possible path through the pwrite code, for every possible type
of object (e.g. phys, stolen, etc). So here we move setting-the-mark
to the top level so that it is obvious that it applies no matter which
subsequent path is followed.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gp
ore rather than discarded.
Based on an original version by Alex Dai.
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
ind
On 10/12/15 22:14, Rafael J. Wysocki wrote:
On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote:
On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote:
On Thursday, December 10, 2015 10:36:37 PM Rafael J. Wysocki wrote:
On Thursday, December 10, 2015 11:43:50 AM Imre Deak wrote:
O
On 10/12/15 08:58, Daniel Vetter wrote:
On Mon, Dec 07, 2015 at 12:51:49PM +, Dave Gordon wrote:
I think I missed i915_gem_phys_pwrite().
i915_gem_gtt_pwrite_fast() marks the object dirty for most cases (vit
set_to_gtt_domain(), but isn't called for all cases (or can return befor
On 11/12/15 12:19, Tvrtko Ursulin wrote:
On 11/12/15 11:22, Ankitprasad Sharma wrote:
On Wed, 2015-12-09 at 14:06 +, Tvrtko Ursulin wrote:
Hi,
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
[snip!]
+/**
+ * Requested flags (currently used fo
hould certainly update the current (v2) upstream with this.
Thomas Daniel already R-B'd this code on 23rd October, when it was:
[PATCH v3 7/8] drm/i915: Grab execlist spinlock to avoid post-reset
concurrency issues.
and it hasn't changed in substance since then, so you can carry his R
On 11/12/15 22:59, Chris Wilson wrote:
The request tells us where to read the ringbuf from, so use that
information to simplify the error capture. If no request was active at
the time of the hang, the ring is idle and there is no information
inside the ring pertaining to the hang.
Signed-off-by:
On 11/12/15 22:59, Chris Wilson wrote:
Remove some redundant kernel messages as we deduce a hung GPU and
capture the error state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Using stolen backed objects as a batchbuffer may result into a kernel
panic during relocation. Added a check to prevent the panic and fail
the execbuffer call. It is not recommended to use stolen object as
a batch
On 14/12/15 15:39, Thierry Reding wrote:
On Wed, Dec 09, 2015 at 05:08:02PM +0100, Daniel Vetter wrote:
Every time I type or review docs this seems a bit different. Try to
document the common style so we can try to unify at least new docs.
v2: Spelling fixes from Pierre, Laurent and Jani.
v3:
er to handle the error.
v1: Move wq_reserve_space to ring_reserve_space
v2: Move wq_reserve_space to alloc_request_extras (Chris Wilson)
v3: The work queue head pointer is cached by driver now. So we can
quickly return if space is available.
s/reserve/check/g (Dave Gordon)
Signed-off-by: Ale
On 11/12/15 18:15, Daniel Vetter wrote:
On Wed, Dec 09, 2015 at 07:39:56PM +, Dave Gordon wrote:
On 09/12/15 16:15, Tvrtko Ursulin wrote:
Hi,
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite
f2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
The #defines below need a comment, at the very least:
/* Bits in struct intel_context::flags below */
otherwise we can't tell where they are appropriate.
With that fixed, then
Reviewed-by: Dave Gordon
-#define CONTEXT_NO_ZEROMAP (1
On 14/12/15 11:28, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 11:14:31AM +, Dave Gordon wrote:
On 11/12/15 22:59, Chris Wilson wrote:
The request tells us where to read the ringbuf from, so use that
information to simplify the error capture. If no request was active at
the time of the
On 15/12/15 14:54, Chris Wilson wrote:
On Tue, Dec 15, 2015 at 02:41:47PM +, Dave Gordon wrote:
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Using stolen backed objects as a batchbuffer may result into a kernel
panic during relocation. Added a check
On 14/12/15 22:17, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 05:13:43PM +, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 04:30:04PM +, Nick Hoath wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 900ffd0..7df3c7a 100644
--- a/dr
On 16/12/15 10:09, Daniel Vetter wrote:
On Wed, Dec 16, 2015 at 10:00:44AM +, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 09:54:47AM +0100, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 10:18:35PM +, Chris Wilson wrote:
igt likes to inject GPU hangs into its command streams. However, as
t_pointer (still) being set up; to iterate over engines
in reverse (as this is teardown code); and to reduce the nesting level
so it's easier to read.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
ister accesses from intel_cleanup_ring_buffer()
(which calls intel_stop_ring_buffer(ring) which calls stop_ring())
down into stop_ring() itself), which is already doing low-level
register accesses. Then, intel_cleanup_ring_buffer() no longer
needs 'dev_priv'.
Signed-off-
his refcount is nominally ascribed
to the render ring (RCS), which is set up first and now torn down last.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem_context.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_con
ation.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 66b1705..15f8989 100644
--- a/dr
A collection of small patches to fix some incorrect failure paths and
generally tidy up the corresponding teardown code, mostly relating to
contexts, and in particular the global default context that's created
at startup.
These should make subsequent reorganisation of other startup/teardown
code e
On 16/12/15 18:57, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:
Some of the LRC-specific context-destruction code has to special-case
the global default context, because the HWSP is part of that context. At
present it deduces it indirectly by checking for the
pends on the compile-time symbol MODULE, defined
by the Kbuild system when building an LKM.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
Cc: "Goel, Akash"
Cc: Michal Hocko
Cc: Johannes Weiner
Cc: linux...@kvack.org
Cc: intel-gfx@lists.freedesktop.org
---
include/linux/swap.h | 1
On 17/12/15 12:27, Chris Wilson wrote:
On Thu, Dec 17, 2015 at 11:09:54AM +, Nick Hoath wrote:
On 16/12/2015 19:30, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 07:22:52PM +, Dave Gordon wrote:
On 16/12/15 18:57, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 06:36:49PM +, Dave
On 18/12/15 10:39, Joonas Lahtinen wrote:
Using __stringify(x) instead of #x adds support for macros as
a parameter and reduces runtime overhead.
Slightly increases the .text size but should not matter.
v2:
- Define I915_STATE_WARN_ON though I915_STATE_WARN
(Bikeshed inspiration by Chris)
C
On 17/12/15 19:00, Dave Gordon wrote:
On 17/12/15 12:27, Chris Wilson wrote:
On Thu, Dec 17, 2015 at 11:09:54AM +, Nick Hoath wrote:
[snip!]
If you want to make such a big change, eliminate the default_ctx from
execlists.
-Chris
No, we need the default (or global) context for idling
On 18/12/15 12:27, Joonas Lahtinen wrote:
Take advantage of WARN return value to simplify the flow.
Cc: Rob Clark
Reviewed-by: Chris Wilson
Reported-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 15 +--
1 file changed, 5 insertions(+), 1
On 18/12/15 09:49, Jani Nikula wrote:
On Fri, 18 Dec 2015, Chris Wilson wrote:
On Fri, Dec 18, 2015 at 10:51:35AM +0200, Jani Nikula wrote:
Use dev_priv rather than dev pointer where applicable. Remove plenty of
unnecessary temp variables. No functional changes.
Signed-off-by: Jani Nikula
--
On 21/12/15 11:01, Chris Wilson wrote:
On Mon, Dec 21, 2015 at 11:48:35AM +0100, Daniel Vetter wrote:
On Wed, Dec 16, 2015 at 06:36:48PM +, Dave Gordon wrote:
We set up engines in forwards order, so some things (notably the
default context) are "owned" by engine 0 (the render e
On 21/12/15 08:11, Joonas Lahtinen wrote:
On pe, 2015-12-18 at 16:18 +, Dave Gordon wrote:
On 18/12/15 12:27, Joonas Lahtinen wrote:
Take advantage of WARN return value to simplify the flow.
Cc: Rob Clark
Reviewed-by: Chris Wilson
Reported-by: Chris Wilson
Signed-off-by: Joonas
are), and to fall back to execlist mode if any
required firmware cannot be found or fails to load.
Signed-off-by: Dave Gordon
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_gem.c | 1 -
drivers/gpu/drm/i915/i915_params.c | 14 -
drivers/gpu/drm/i915/i915_params.h | 3
On 21/01/16 21:41, Jeff McGee wrote:
On Thu, Jan 21, 2016 at 06:11:01PM +, Peter Antoine wrote:
This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory
spaces do not overlap.
Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
Signed-off-by: Peter Antoine
---
drivers/
This has to be done before the containing object is freed, otherwise
the mapping ends up pointing to no-longer-allocated memory :(
Signed-off-by: Dave Gordon
Cc: Mika Kuoppala
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
() rather than repeat the mapping calculation.
[Chris Wilson]
Signed-off-by: Dave Gordon
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
in
t and let intel_cleanup_ring_buffer()
deal with any partially-set-up state.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/dr
nature of lrc_setup_hardware_status_page()
to match
so that all knowledge of this special arrangement is local to these
two functions.
v3: Rebased
Signed-off-by: Dave Gordon
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 41 +++-
1 file changed, 24 insertio
There's some unreachable code in intel_logical_ring_cleanup(),
presumably copypasted from the legacy ringbuffer version at
creation. Let's delete it :)
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
di
Add call to i915_gem_context_fini() to deallocate the default context
if the call to init_rings() fails, so that we don't leak the allocated
memory in that situation.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
ointer, as drm_gem_object_unreference
can handle NULL [Chris Wilson]. This relies on 'base' being the very
first member of 'struct intel_ringbuffer'!
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 --
1 file changed,
et up.
Signed-off-by: Dave Gordon
Cc: Mika Kuoppala
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 95ba8ec..b4deaca 100644
--- a/dr
s ring->dev as an
'initialised' flag, so it can now be NULL after engine teardown. This in
turn can cause a problem in the context code, which (used to) check the
ring->dev->struct_mutex -- causing a fault if ring->dev was NULL.
Signed-off-by: Nick Hoath
Signed-off-by: Davi
uld pass a pass/fail status back, but since the high-level
code continues anyway, there's no reason to at present.
As a bonus, apart from fixing the lavering violation, moving the code
lets us eliminate the implicitly-used local 'dev_priv' from the caller.
Signed-off-by: Dave Gor
hile we're looking at this function, there's a strangely-formatted
comment block that looks ugly, so let's prettify it.
Signed-off-by: Nick Hoath
Signed-off-by: David Gordon
Cc: Mika Kuoppala
Cc: Chris Wilson
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_dma.c | 4 +
Chris Wilson), the remaining ones have been broken up
into smaller more digestible chunks.
Dave Gordon (9):
drm/i915: unmap the correct page in intel_logical_ring_cleanup()
drm/i915: consolidate LRC mode HWSP setup & teardown
drm/i915: remove useless copypasted code
drm/i915: tid
so we could accommodate GPUs
that required different amounts of padding, generalised NOOP fill
[Rodrigo Vivi], added W/A space to reserved amount and updated
code comments [Dave Gordon],
Originally-by: Rodrigo Vivi
Rewritten-by: Chris Wilson
Further-tweaked-by: Dave Gordon
Signed
On 06/02/16 09:33, Chris Wilson wrote:
On Fri, Feb 05, 2016 at 02:56:51PM -0800, Rodrigo Vivi wrote:
On Fri, Feb 5, 2016 at 11:31 AM, Dave Gordon wrote:
@@ -907,7 +927,8 @@ int intel_logical_ring_reserve_space(struct
drm_i915_gem_request *request)
* adding any commands to it then
On 05/02/16 22:56, Rodrigo Vivi wrote:
On Fri, Feb 5, 2016 at 11:31 AM, Dave Gordon wrote:
From: Chris Wilson
Currently emit-request starts writing to the ring and reserves space
for a workaround to be emitted later whilst submitting the request. It
is easier to read if the caller only
On 09/02/16 00:20, Kristian Høgsberg wrote:
On Fri, Feb 5, 2016 at 5:48 PM, Ben Widawsky
wrote:
This behavior of checking for a shmem backed GEM object was introduced here:
commit 4c914c0c7c787b8f730128a8cdcca9c50b0784ab
Author: Brad Volkin
Date: Tue Feb 18 10:15:45 2014 -0800
drm/i915
expressions.
v2: Use comma as list separator (Ville Syrjala)
support both ^ and ! as not operators (Dave Gordon)
v3: Updated to use uwildmat() (Dave Gordon)
Signed-off-by: Derek Morton
---
COPYING | 21 +++
lib/Makefile.sources| 2 +
lib/igt_core.c | 17 +-
lib
so we could accommodate GPUs
that required different amounts of padding, generalised NOOP fill
[Rodrigo Vivi], added W/A space to reserved amount and updated
code comments [Dave Gordon],
v4:
Made #define for WA_TAIL_DWORDS a function-type macro in case we
want different values
On 11/02/16 08:47, Daniel Vetter wrote:
On Mon, Feb 01, 2016 at 09:45:25AM +, Dave Gordon wrote:
On 30/01/16 11:28, Chris Wilson wrote:
On Sat, Jan 30, 2016 at 10:56:27AM +, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 07:19:27PM +, Dave Gordon wrote:
1. add call to
301 - 400 of 1151 matches
Mail list logo
