Both perform the same actions with more or less indirection, so just
unify the code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_gem_context.c| 8 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 34 -
drivers/gpu/d
By using the same address for storing the HWS on every platform, we can
remove the platform specific vfuncs and reduce the get-seqno routine to
a single read of a cached memory location.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++--
drivers/gpu/drm/i915/i915
In a few frequent cases, having a direct pointer to the drm_i915_private
from the request is very useful.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 7 +++---
drivers/gpu/drm/i915/i915_gem_context.c| 21 +-
drivers/gpu/drm/i915/i915_gem_exec
The queue only ever contains at most one item and has no special flags.
It is just a very simple wrapper around the system-wq - a complication
with no benefits.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 11 ---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/d
If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM requ
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.
Note carefully that this will reduce the amount of info
Describe the intent of boosting the GPU frequency to maximum before
waiting on the GPU.
RPS waitboosting was introduced with
commit b29c19b645287f7062e17d70fa4e9781a01a5d88
Author: Chris Wilson
Date: Wed Sep 25 17:34:56 2013 +0100
drm/i915: Boost RPS frequency for CPU stalls
but lacked a
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the vmapping into the
obj->pages lifetime, then we can reuse an obj->vmapping for both and at
the same time couple it into the shrinker.
v2: Mark the failable kmalloc() as __GFP_NO
We want to restrict waitboosting to known process contexts, where we can
track which clients are receiving waitboosts and prevent excessive power
wasting. For fence_wait() we do not have any client tracking and so that
leaves it open to abuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915
Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 8 +-
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/d
igt likes to inject GPU hangs into its command streams. However, as we
expect these hangs, we don't actually want them recorded in the dmesg
output or stored in the i915_error_state (usually). To accomodate this
allow userspace to set a flag on the context that any hang emanating
from that context
Since the tests can and do explicitly check debugfs/i915_ring_missed_irqs
for the handling of a "missed interrupt", adding it to the dmesg at INFO
is just noise. When it happens for real, we still class it as an ERROR.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 3 ---
1 fi
With only a single callsite for intel_engine_cs->irq_get and ->irq_put,
we can reduce the code size by moving the common preamble into the
caller, and we can also eliminate the reference counting.
For completeness, as we are no longer doing reference counting on irq,
rename the get/put vfunctions
If we flag the seqno as potentially stale upon receiving an interrupt,
we can use that information to reduce the frequency that we apply the
heavyweight coherent seqno read (i.e. if we wake up a chain of waiters).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 15
Only declare a missed interrupt if we find that the GPU is idle with
waiters and a hangcheck interval has passed in which no new user
interrupts have been raised.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
drivers/gpu/drm/i915/i915_irq.c | 10 +++
If we do not have lowlevel support for reseting the GPU, or if the user
has explicitly disabled reseting the device, the failure is expected.
Since it is an expected failure, we should be using a lower priority
message than *ERROR*, perhaps NOTICE. In the absence of DRM_NOTICE, just
emit the expect
Reporting -EIO from i915_wait_request() has proven very troublematic
over the years, with numerous hard-to-reproduce bugs cropping up in the
corner case of where a reset occurs and the code wasn't expecting such
an error.
If the we reset the GPU or have detected a hang and wish to reset the
GPU, t
In order to simplify the next couple of patches, extract the
lazy_coherency optimisation our of the engine->get_seqno() vfunc into
its own callback.
v2: Rename the barrier to engine->irq_seqno_barrier to try and better
reflect that the barrier is only required after the user interrupt before
readi
Ideally, we want to automagically have the GPU respond to the
instantaneous load by reclocking itself. However, reclocking occurs
relatively slowly, and to the client waiting for a result from the GPU,
too late. To compensate and reduce the client latency, we allow the
first wait from a client to b
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. Using the testcases, we
have very determinist
In order to ensure seqno/irq coherency, we current read a ring register.
We are not sure quite how it works, only that is does. Experiments show
that e.g. doing a clflush(seqno) instead is not sufficient, but we can
remove the forcewake dance from the mmio access.
v2: Baytrail wants a clflush too.
As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the request and reuse
it when waiting upon that request in future. This removes a very hairy
atomic check serialised by the struct_mutex at the time of waiting and
allows us to
Now that we have split out the seqno-barrier from the
engine->get_seqno() callback itself, we can move the users of the
seqno-barrier to the required callsites simplifying the common code and
making the required workaround handling much more explicit.
Signed-off-by: Chris Wilson
---
drivers/gpu/
Now that the reset_counter is stored on the request, we can rearrange
the code to handle reading the counter versus waiting during the atomic
modesetting for readibility (by deleting the hairiest of codes).
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gp
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
Currently there is a #define to enable extra BUG_ON for debugging
requests and associated activities. I want to expand its use to cover
all of GEM internals (so that we can saturate the code with asserts).
We can add a Kconfig option to make it easier to enable - with the usual
caveats of not enabl
This is principally a little bit of syntatic sugar to hide the
atomic_read()s throughout the code to retrieve the current reset_counter.
It also provides the other utility functions to check the reset state on the
already read reset_counter, so that (in later patches) we can read it once
and do mul
As paranoia, we want to ensure that the CPU's PTEs have been revoked for
the object before we return from i915_gem_release_mmap(). This allows us
to rely on there being no outstanding memory accesses and guarantees
serialisation of the code against concurrent access just by calling
i915_gem_release
As we add the VMA to the request early, it may be cancelled during
execbuf reservation. This will leave the context object pointing to a
dangling request; i915_wait_request() simply skips the wait and so we
may unbind the object whilst it is still active.
However, if at any point we make a change
When userspace closes a handle, we remove it from the file->object_idr
and then tell the driver to drop its references to that file/handle.
However, as the file/handle is already available again for reuse, it may
be reallocated back to userspace and active on a new object before the
driver has had
== Summary ==
Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly:
2016y-01m-11d-07h-30m-16s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
dmesg-warn -> PASS (bdw-
On Mon, Jan 11, 2016 at 08:52:24AM +, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 09:00:13AM +0100, Daniel Vetter wrote:
> > On Fri, Jan 08, 2016 at 09:10:38AM +, Chris Wilson wrote:
> > > gem_concurrent_blit tries to ensure that it doesn't try and run a test
> > > that would grind the sy
On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
> > On Fri, Jan 08, 2016 at 08:44:29AM +, Chris Wilson wrote:
> > > Some stress tests create both the signal helper and a lot of competing
> > > processes. In these tes
On Mon, Jan 11, 2016 at 08:50:43AM +0100, Daniel Vetter wrote:
> On Fri, Jan 08, 2016 at 06:58:45PM +0200, Mika Kuoppala wrote:
> > With gen9+ the edram capabilities are defined so
> > that we can calculate the edram (ellc) size accordingly.
> >
> > Note that there are undefined combinations for s
On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
> On Fri, Jan 08, 2016 at 08:44:29AM +, Chris Wilson wrote:
> > Some stress tests create both the signal helper and a lot of competing
> > processes. In these tests, the parent is just waiting upon the children,
> > and the intentio
== Summary ==
HEAD is now at ff88655 drm-intel-nightly: 2016y-01m-11d-07h-30m-16s UTC
integration manifest
Applying: drm/i915: Use passed plane state for sprite planes, v4.
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/intel_drv.h
M drivers/gpu/drm/i915/intel_s
== Summary ==
Built on ff88655b3a5467bbc3be8c67d3e05ebf182557d3 drm-intel-nightly:
2016y-01m-11d-07h-30m-16s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-ultra)
dmesg-warn -> PASS (skl-i7k-2) UN
On Mon, Jan 11, 2016 at 09:00:13AM +0100, Daniel Vetter wrote:
> On Fri, Jan 08, 2016 at 09:10:38AM +, Chris Wilson wrote:
> > gem_concurrent_blit tries to ensure that it doesn't try and run a test
> > that would grind the system to a halt, i.e. unexpectedly cause swap
> > thrashing. It current
On Fri, Jan 08, 2016 at 11:29:48AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Engine initialization would have failed if those two weren't
> pinned and calling i915_gem_obj_is_pinned is illegal from irq
> context without the big lock held.
>
> Signed-off-by: Tvrtko Ursulin
Reviewe
On Mon, Jan 11, 2016 at 01:09:50PM +0530, Goel, Akash wrote:
>
>
> On 1/10/2016 11:09 PM, Chris Wilson wrote:
> >On Sat, Jan 09, 2016 at 05:00:21PM +0530, akash.g...@intel.com wrote:
> >>From: Akash Goel
> >>
> >>Gen9 has an additional address translation hardware support in form of
> >>Tiled Re
On Fri, Jan 08, 2016 at 11:29:50AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
> interrupt context without the big lock held.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 3 +--
> d
On Fri, Jan 08, 2016 at 11:44:04AM +, Chris Wilson wrote:
> On Fri, Jan 08, 2016 at 11:29:46AM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Purpose is to catch places which iterate the object VMA list
> > without holding the big lock.
> >
> > Implemented by open coding list_
On Fri, Jan 08, 2016 at 01:29:14PM +, Tvrtko Ursulin wrote:
>
> On 08/01/16 11:29, Tvrtko Ursulin wrote:
> >From: Tvrtko Ursulin
> >
> >Purpose is to catch places which iterate the object VMA list
> >without holding the big lock.
> >
> >Implemented by open coding list_for_each_entry to make t
On Fri, Jan 08, 2016 at 11:29:45AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> No need to call ktime_get_raw_ns twice per unlimited wait and can
> also elimate a local variable.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> 1 file ch
On Fri, Jan 08, 2016 at 11:29:44AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We are not allowed to call i915_gem_obj_ggtt_offset from irq
> context without the big kernel lock held.
>
> LRCA lifetime is well defined so cache it so it can be looked up
> cheaply from the interrupt co
On Fri, Jan 08, 2016 at 11:29:43AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> LRCA can change only when it goes from unpinned to pinned so it
> makes sense to check its alignment at that point rather than at
> every batch buffer submission.
>
> Furthermore, if we check it at pin tim
On Fri, Jan 08, 2016 at 11:29:42AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> There is no need to check on what Gen we are running on every
> interrupt and every command submission. We can instead set up
> some of that when engines are initialized, store it in the
> engine structure
On Fri, Jan 08, 2016 at 11:29:41AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Looks like the sleeping loop in __i915_wait_request can be
> simplified by using io_schedule_timeout instead of setting
> up and destroying a timer.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
On Fri, Jan 08, 2016 at 11:29:40AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Same effect for slightly less source code and resulting binary.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 15 ++-
> 1 file chan
On Fri, Jan 08, 2016 at 09:10:38AM +, Chris Wilson wrote:
> gem_concurrent_blit tries to ensure that it doesn't try and run a test
> that would grind the system to a halt, i.e. unexpectedly cause swap
> thrashing. It currently calls intel_require_memory(), but outside of
> the subtest (as the t
401 - 450 of 450 matches
Mail list logo
