[Intel-gfx] [PATCH 0/5] Dynamic Parity Detection/Correction

Ben Widawsky ben at bwidawsk.net
Sat Apr 28 02:40:16 CEST 2012


Unfortunately dinq is not working on my IVB at this moment, so I was forced to
base these patches on din ie. that's why I've added Chris' patch to the series
manually.

Regarding whether or not to actually upstream these patches, I think it
would be awesome if distros could let us know how interested they are in
incorporating this. It is of particular use for any applications using
the GPU for compute. Even if distros don't want it, have the
uevent/interrupt is nice to incorporate, but I would think twice about
the sysfs interface.

Now for the explanation (you may want to get a coffee first):
Internal to the GPU is a cache referred to in docs as L3. The smallest
unit of the cache which is addressable is called a row. There are x rows
in each subbank, and y subbanks in each of the z banks.

HW provides two extra rows per subbank, and a software mechanism to
remap these rows. The addressing after remapping is handled
transparently to software. There is also an interrupt generated by the
render CS to tell us when a parity error occurs in one of the rows.

There is one portion currently unimplemented in the series; we are
required to issue a GPU reset before we remap a row. The documents I
have do not make it clear *exactly* why the gpu reset must occur, but I
believe, similar to Linux, it is the windows mechanism for basically
telling GPU clients that whatever work they've submitted needs to be
resubmitted.

There are various clients which use the L3, however none of these should
be utilized during simple modeset/fbcon.  Therefore, I believe the
following algorithm is guaranteed to work:
1. On boot check some non-volatile storage for bad r/b/s
2. load i915
3. disable bad rbs ASAP
4. Wait forever for uevent of bad r/b/s
5. store r/b/s in some non-volatile storage
6. reboot; goto 1

If we had the reset working, we could avoid the reboot, and instead do:
1. On boot check some non-volatile storage for bad r/b/s
2. load i915
3. disable bad rbs ASAP
4. Wait forever for uevent of bad r/b/s
5. store r/b/s in some non-volatile storage
6. gpu reset; goto 3

The reset is essentially used to "automatically" make all GPU clients
aware that they may need to resubmit their data. The problem with
algorithm #2 without the reset is that there is no way (afaict) to map
the RBS to a BO, and so we have no way to even figure out if the bad
data was propagated to the BO. So an alternative to reset is if system
software detects the uevent, it can send a signal to all known (or
computation based) GPU clients.

See the intel-gpu-tools app as a reference for how to use the sysfs
interface.

Ben Widawsky (4):
  drm/i915: Dynamic Parity Detection handling
  drm/i915: enable parity error interrupts
  drm/i915: remap l3 on hw init
  drm/i915: l3 parity sysfs interface

Chris Wilson (1):
  drm/i915: Use a global lock for modifying global irq flags

 drivers/gpu/drm/i915/i915_drv.h         |    5 ++
 drivers/gpu/drm/i915/i915_gem.c         |   26 +++++++
 drivers/gpu/drm/i915/i915_irq.c         |   87 ++++++++++++++++++++-
 drivers/gpu/drm/i915/i915_reg.h         |   20 +++++
 drivers/gpu/drm/i915/i915_sysfs.c       |  128 ++++++++++++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   45 +++++++----
 drivers/gpu/drm/i915/intel_ringbuffer.h |    3 +-
 7 files changed, 293 insertions(+), 21 deletions(-)

-- 
1.7.10




More information about the Intel-gfx mailing list