On Sat, Apr 09, 2016 at 11:14:38AM +0200, Lluís Batlle i Rossell wrote:
> On Thu, Apr 07, 2016 at 11:54:39AM +0200, Lluís Batlle i Rossell wrote:
> > On Thu, Apr 07, 2016 at 03:19:04PM +0530, Kumar, Shobhit wrote:
> > > On Wednesday 06 April 2016 04:26 PM, Lluís Batlle i Rossell wrote:
> > > >I don
I found this issue when i run glbenchmark25, anyway, good to know, thanks.
Regards
Enpeng
On Saturday, April 9, 2016, Matthew Auld
wrote:
> There's already a patch in the works for this:
> https://patchwork.freedesktop.org/patch/80078/
>
> Regards,
> Matt
>
___
There's already a patch in the works for this:
https://patchwork.freedesktop.org/patch/80078/
Regards,
Matt
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
== Series Details ==
Series: fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to
kunmap_px.
URL : https://patchwork.freedesktop.org/series/5490/
State : failure
== Summary ==
Series 5490v1 fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to
kunmap_px.
http://patchwork
From: Enpeng Xu
Signed-off-by: Enpeng Xu
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 49e4f26..527eca7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
On Sat, Apr 09, 2016 at 12:27:35PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [01/10] drm/i915: Force clean compilation with
> -Werror
> URL : https://patchwork.freedesktop.org/series/5487/
> State : failure
>
> == Summary ==
>
> Series 5487v1 Series witho
== Series Details ==
Series: series starting with [01/10] drm/i915: Force clean compilation with
-Werror
URL : https://patchwork.freedesktop.org/series/5487/
State : failure
== Summary ==
Series 5487v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5487/revisions/
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
Mostly reviewed series, just 2/10 needs attention (and 1/10 will be good
to run through 0day to make sure it is invisible to the automated builders).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/
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
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
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
If we, when we store the reset_counter for the operation, we ensure that
it is not in a wedged or in the middle of a reset, we can then assert that
if any reset occurs the reset_counter must change. Later we can just
compare the operation's reset epoch against the current counter to see
if we need
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
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
Separate out the layers of includes (linux, drm, intel, i915) so that it
is a little easier to order our definitions between our multiple
reentrant headers. A couple of headers needed fixes to make them more
standalone (forgotten includes, forward declarations etc).
Signed-off-by: Chris Wilson
--
In the reset_counter, we use two bits to track a GPU hang and reset. The
low bit is a "reset-in-progress" flag that we set to signal when we need
to break waiters in order for the recovery task to grab the mutex. As
soon as the recovery task has the mutex, we can clear that flag (which
we do by inc
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
== Series Details ==
Series: series starting with [1/4] drm/i915: Fix gen8 semaphores id for legacy
mode
URL : https://patchwork.freedesktop.org/series/5486/
State : warning
== Summary ==
Series 5486v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5486/revisions/
== Series Details ==
Series: series starting with [CI-ping,1/5] drm/i915: Remove forcewake dance
from seqno/irq barrier on legacy gen6+
URL : https://patchwork.freedesktop.org/series/5485/
State : failure
== Summary ==
Series 5485v1 Series without cover letter
http://patchwork.freedesktop.org
On Sat, Apr 09, 2016 at 09:56:11AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/4] drm/i915: Prevent machine death on
> Ivybridge context switching
> URL : https://patchwork.freedesktop.org/series/5484/
> State : warning
>
> == Summary ==
>
> Series 5484v
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.
Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson
C
When the engine idles waiting upon a semaphore, it loses its
pagetables and we must reload them before executing the batch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffe
We have sufficient evidence from igt to support that semaphores are in
a working state. Enabling semaphores now for legacy provides a better
comparison of execlists against legacy ring submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 4
1 file changed, 4 deletio
Semaphores for gen8 were almost finished and only required a couple of
tweaks to pass the most stressful igt I could write, as well as the
existing inter-engine stress tests.
But what's the point you might ask when legacy ringbuffer submission is
already turned off by default? gen8 still serves as
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the
pipecontrol writing the signal value is complete, we have to pause the
CS inside the PIPE_CONTROL with the CS_STALL bit.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
1 file changed, 1 inserti
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.
v2: Clear the stuck interrupt marker between successful batches
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuop
When reading from the HWS page, we use barrier() to prevent the compiler
optimising away the read from the volatile (may be updated by the GPU)
memory address. This is more suited to READ_ONCE(); make it so.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Mika Kuoppala
Reviewed-by: Mika Kuopp
In order to simplify future 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
reading the seqno
Rather than call a function to compute the matching cachelines and
clflush them, just call the clflush *instruction* directly. We also know
that we can use the unpatched plain clflush rather than the clflushopt
alternative.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Imre Deak
Reviewed-by
In order to ensure seqno/irq coherency, we currently read a ring register.
The mmio transaction following the interrupt delays the inspection of
the seqno long enough for the MI_STORE_DWORD_IMM to update the CPU
cache. However, it is only the memory timing that is important for the
purposes of the
== Series Details ==
Series: series starting with [1/4] drm/i915: Prevent machine death on Ivybridge
context switching
URL : https://patchwork.freedesktop.org/series/5484/
State : warning
== Summary ==
Series 5484v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5
On Sat, Apr 09, 2016 at 10:27:37AM +0100, Chris Wilson wrote:
> For reasons unknown Sandybridge GT1 (at least) will eventually hang when
> it encounters a ring wraparound at offset 0. The test case that
> reproduces the bug reliably forces a large number of interrupted context
> switches, thereby c
Conceptually, each request is a record of a hardware transaction - we
build up a list of pending commands and then either commit them to
hardware, or cancel them. However, whilst building up the list of
pending commands, we may modify state outside of the request and make
references to the pending
Please review or even just ack!
Tvrtko, please have another look at 4/4 as it impacts upon requests and
both the state we track in a request and activity tracked by requests.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://list
Two concurrent writes into the same register cacheline has the chance of
killing the machine on Ivybridge and other gen7. This includes LRI
emitted from the command parser. The MI_SET_CONTEXT itself serves as
serialising barrier and prevents the pair of register writes in the first
packet from tri
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
For reasons unknown Sandybridge GT1 (at least) will eventually hang when
it encounters a ring wraparound at offset 0. The test case that
reproduces the bug reliably forces a large number of interrupted context
switches, thereby causing very frequent ring wraparounds, but there are
similar bug repor
On Thu, Apr 07, 2016 at 11:54:39AM +0200, Lluís Batlle i Rossell wrote:
> On Thu, Apr 07, 2016 at 03:19:04PM +0530, Kumar, Shobhit wrote:
> > On Wednesday 06 April 2016 04:26 PM, Lluís Batlle i Rossell wrote:
> > >I don't see any trace of pwm/lpss in dmesg, so it's normal that i915 fails
> > >to fi
On Fri, Apr 08, 2016 at 02:54:54PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Retired request queue coupled with retired work handler is a scalability
> concern on some workloads of which one dramatic example is gem_close_race.
>
> This series depend on i915_gem_object_pin_map serie
40 matches
Mail list logo
