[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

2017-04-02 Thread Stephen Rothwell 
Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c: In function 'vmw_sou_crtc_page_flip':
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:327:8: error: too few arguments to 
function 'drm_atomic_helper_page_flip'
  ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
^
In file included from drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:31:0:
include/drm/drm_atomic_helper.h:126:5: note: declared here
 int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
 ^
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c: In function 'vmw_stdu_crtc_page_flip':
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:508:8: error: too few arguments to 
function 'drm_atomic_helper_page_flip'
  ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
^
In file included from drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:32:0:
include/drm/drm_atomic_helper.h:126:5: note: declared here
 int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
 ^

Caused by commit

  41292b1fa13a ("drm: Add acquire ctx parameter to ->page_flip(_target)")

interacting with commits

  904bb5e5817f ("drm/vmwgfx: Switch over to internal atomic API for STDU")
  b0119cb9229d ("drm/vmwgfx: Switch over to internal atomic API for SOU and 
LDU")

from the drm tree.

I added this merge fix patch for today:

From: Stephen Rothwell 
Date: Mon, 3 Apr 2017 13:25:55 +1000
Subject: [PATCH] drm/vmwgfx: merge fixup for page_flip API change

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 02b8f2541dca..8d7dc9def7c2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -324,7 +324,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc,
return -EINVAL;
 
flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
-   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
+   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
if (ret) {
DRM_ERROR("Page flip error %d.\n", ret);
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index e59bbcd8b226..bad31bdf09b6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -505,7 +505,7 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
 * don't hand it to the helper.
 */
flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
-   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
+   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
if (ret) {
DRM_ERROR("Page flip error %d.\n", ret);
return ret;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree

2017-04-02 Thread Stephen Rothwell 
Hi all,

Today's linux-next merge of the drm-misc tree got conflicts in:

  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c

between commits:

  904bb5e5817f ("drm/vmwgfx: Switch over to internal atomic API for STDU")
  b0119cb9229d ("drm/vmwgfx: Switch over to internal atomic API for SOU and 
LDU")

from the drm tree and commit:

  a4eff9aa6db8 ("drm: Add acquire ctx parameter to ->set_config")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell 
Date: Mon, 3 Apr 2017 13:04:36 +1000
Subject: [PATCH] drm/vmwgfx: merge fixup for set_config API change

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 5 -
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index c18c81f63ac3..2517debf214d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2940,6 +2940,7 @@ vmw_kms_create_implicit_placement_property(struct 
vmw_private *dev_priv,
  * vmw_kms_set_config - Wrapper around drm_atomic_helper_set_config
  *
  * @set: The configuration to set.
+ * @ctx: lock acquisition context
  *
  * The vmwgfx Xorg driver doesn't assign the mode::type member, which
  * when drm_mode_set_crtcinfo is called as part of the configuration setting
@@ -2947,10 +2948,11 @@ vmw_kms_create_implicit_placement_property(struct 
vmw_private *dev_priv,
  * the vmwgfx modesetting. So explicitly clear that member before calling
  * into drm_atomic_helper_set_config.
  */
-int vmw_kms_set_config(struct drm_mode_set *set)
+int vmw_kms_set_config(struct drm_mode_set *set,
+  struct drm_modeset_acquire_ctx *ctx)
 {
if (set && set->mode)
set->mode->type = 0;
 
-   return drm_atomic_helper_set_config(set);
+   return drm_atomic_helper_set_config(set, ctx);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 9c161d29aaeb..ecafa9a7648e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -453,6 +453,9 @@ int vmw_kms_stdu_dma(struct vmw_private *dev_priv,
 bool to_surface,
 bool interruptible);
 
-int vmw_kms_set_config(struct drm_mode_set *set);
+struct drm_modeset_acquire_ctx;
+
+int vmw_kms_set_config(struct drm_mode_set *set,
+  struct drm_modeset_acquire_ctx *ctx);
 
 #endif
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [Regression report] Weekly regression report WW13

2017-04-02 Thread Jairo Miramontes 
Link to FDO regression list: 
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED_status=NEEDINFO=DRM%2FIntel=OP=OP=short_desc=keywords=CP=CP=OR_name=i915%20regressions_id=600614=anywordssubstr=anywordssubstr_sys=All_sys=Linux%20%28All%29_sys=other=bug_id%20DESC=DRI_based_on=i915%20regressions_format=advanced_platform=All_platform=x86%20%28IA32%29_platform=x86-64%20%28AMD64%29_platform=IA64%20%28Itanium%29_platform=Other=regression%20bisect=regression%20bisected%20pending_bisect


Total regressions: 26

This week regressions:0
+---+-+++
| BugId | Summary | Created on | Bisect |
+---+-+++

Previous regressions:26
++--+++
| BugId  | Summary | Created on | Bisect |
++--+++
| 99929  | [i915] Black/gray screen with kernel 
4.9.3   | 2017-02-23 | Yes |
| 99766  | [v4.9 PATCH] DisplayPort Monitor Doesn't Come Back From 
Sleep| 2017-02-10 | Yes|
| 99578  | [SKL][bisected] Screen regularly returns from power save 
mode| 2017-01-28 | Yes|
| 99575  | [ilk bisected] "drm/i915: Type safe register read/write" -> 
poor/nonexistent IPS | 2017-01-28 | Yes|
| 99362  | no resolutions >=1080p with Acer P7500 and Thinkpad 
X1   | 2017-01-11 | No |
| 99093  | [PNV][regression] N450 and D510 machines get stuck in 
igt@gem_ringfill@basic-def | 2016-12-15 | Yes|
| 98690  | [SKL bisected] System freeze when starting X using kernel 
4.9-rc1 or later   | 2016-11-11 | Yes|
| 98517  | Skylake gen6 suspend/resume video regression 
4.9 | 2016-10-31 | No |
| 97918  | [bdw regression 4.8] Severe graphics regression, rainbow 
glitching and flickerin | 2016-09-25 | No |
| 96781  | [skl dp-mst] oops in atomic 
commit   | 2016-07-02 | Yes|
| 96428  | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR* dp aux hw did 
not signal timeout (h | 2016-06-07 | Yes|
| 95736  | [IVB bisected] *ERROR* uncleared fifo underrun on pipe 
A | 2016-05-24 | Yes|
| 94590  | [KBL] igt/kms_fbcon_fbt/psr-suspend 
regression   | 2016-03-17 | No |
| 93782  | [i9xx TV][BISECT] vblank wait timeout on 
crtc| 2016-01-19 | Yes|
| 93486  | [HP Compaq dc7800 Small Form Factor PC][REGRESSION] 
suspend/resume failure   | 2015-12-23 | No |
| 93361  | 12bpc hdmi causes wrong real refresh rate (swapbuffers return 
time)  | 2015-12-12 | Yes|
| 93263  | 945GM regression since 
4.3   | 2015-12-05 | 
No |
| 92050  | [regression]/bug introduced by commit 
[0e572fe7383a376992364914694c39aa7fe44c1d] | 2015-09-19 | Yes|
| 91974  | [bisected] unrecoverable black screen after killing 
X| 2015-09-11 | Yes|
| 90112  | [BSW bisected] OglGSCloth/Lightsmark/CS/ Portal/ Half Life 2 
games performance d | 2015-04-20 | Yes|
| 89632  | [i965 
regression]igt/kms_universal_plane/universal-plane-pipe-A-functional 
cause | 2015-03-18 | No |
| 88124  | i915: regression: after DP connected (via docking station) 
monitor is turned off | 2015-01-06 | No |
| 87726  | [BDW Bisected] OglDrvCtx performance reduced by ~30% after 
use true PPGTT in Gen | 2014-12-26 | Yes|
| 87725  | [BDW Bisected] OglBatch7 performance reduced by ~7% after 
enable execlists   | 2014-12-26 | Yes|
| 87131  | [PNV regression] igt/gem_exec_lut_handle takes more than 10 
minutes  | 2014-12-09 | No |
| 100221 | [SKL] Resume from suspend to disk fails - 
bisected   | 2017-03-15 | Yes|

++--+++
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Sleep after restarting the GPU after reset

2017-04-02 Thread Chris Wilson 
On Sun, Apr 02, 2017 at 03:36:11PM +0100, Chris Wilson wrote:
> A piece of magic that prevents Baytrail from doing a timewarp. (Perhaps
> executing an incorrect portion of the ring?) If left to itself after a
> few hundred resets, the GPU will write a stale seqno causing all
> requests to be completed early and the GPU then appears idle.

+ stuck in the future

> A msleep(1000) before the intel_gpu_reset, or after it is not
> sufficient, but a short delay of a few hundred microseconds after

(also demonstrating that this is not a stray write left inflight from
before the reset)

> writing the RING_CTL is. Less than a few hundred us, or inserting a few
> more posting reads into the init_ring_common is not enough. To limit the
> impact, it appears we only need one after all RING_CTL writes and also we
> only want to apply it when writing nonzero values into the RING_HEAD/TAIL
> i.e. after reset.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98836
Testcase: igt/gem_exec_whisper/hang-chain
> Signed-off-by: Chris Wilson 

Before I forget to add them.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sleep after restarting the GPU after reset

2017-04-02 Thread Patchwork 
== Series Details ==

Series: drm/i915: Sleep after restarting the GPU after reset
URL   : https://patchwork.freedesktop.org/series/22329/
State : success

== Summary ==

Series 22329v1 drm/i915: Sleep after restarting the GPU after reset
https://patchwork.freedesktop.org/api/1.0/series/22329/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 427s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 430s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 570s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 555s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 484s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 408s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 467s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 451s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time: 569s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 458s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 486s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 402s

19ceec7d516a7c4614833ba7a3724a4bea0c59d3 drm-tip: 2017y-03m-31d-20h-10m-03s UTC 
integration manifest
2aab31f drm/i915: Sleep after restarting the GPU after reset

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4380/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Sleep after restarting the GPU after reset

2017-04-02 Thread Chris Wilson 
A piece of magic that prevents Baytrail from doing a timewarp. (Perhaps
executing an incorrect portion of the ring?) If left to itself after a
few hundred resets, the GPU will write a stale seqno causing all
requests to be completed early and the GPU then appears idle.

A msleep(1000) before the intel_gpu_reset, or after it is not
sufficient, but a short delay of a few hundred microseconds after
writing the RING_CTL is. Less than a few hundred us, or inserting a few
more posting reads into the init_ring_common is not enough. To limit the
impact, it appears we only need one after all RING_CTL writes and also we
only want to apply it when writing nonzero values into the RING_HEAD/TAIL
i.e. after reset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98836
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bbc6f1c9f175..54e6d8b43c2b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4581,6 +4581,9 @@ static int __i915_gem_restart_engines(void *data)
return err;
}
 
+   /* Small piece of magic to stablize resets of an active GPU */
+   msleep(1);
+
return 0;
 }
 
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

2017-04-02 Thread Martin Kepplinger 


Am 2. April 2017 13:50:26 MESZ schrieb Thorsten Leemhuis 
:
>Lo! On 22.03.2017 11:36, Jani Nikula wrote:
>> On Wed, 22 Mar 2017, Martin Kepplinger  wrote:
>>> I know something similar is here: 
>>> https://bugs.freedesktop.org/show_bug.cgi?id=100110 too.
>>> But this is rc3 and my machine is totally *not usable*. Let me be 
>>> annoying :) I hope I can help:
>> Please file a bug over at [1].
>> […]
>> [1]
>https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
>
>@Martin: did you file that bug? I could not find one :-/

I did. Got marked as duplicate of 
https://bugs.freedesktop.org/show_bug.cgi?id=100181 and there's a fix out 
there. I don't know if it's in rc5 though.

>
>@Jani: In similar situations could you do me a favour and ask people to
>send one more reply to the public list which contains the link to the
>bug filed? Regression tracking is quite hard already; searching various
>bug tracker for follow up bug entries makes it even harder :-(
>
>Ciao, Thorsten

-- 
Martin Kepplinger
http://martinkepplinger.com
sent from mobile
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

2017-04-02 Thread Thorsten Leemhuis 
Lo! On 22.03.2017 11:36, Jani Nikula wrote:
> On Wed, 22 Mar 2017, Martin Kepplinger  wrote:
>> I know something similar is here: 
>> https://bugs.freedesktop.org/show_bug.cgi?id=100110 too.
>> But this is rc3 and my machine is totally *not usable*. Let me be 
>> annoying :) I hope I can help:
> Please file a bug over at [1].
> […]
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel

@Martin: did you file that bug? I could not find one :-/

@Jani: In similar situations could you do me a favour and ask people to
send one more reply to the public list which contains the link to the
bug filed? Regression tracking is quite hard already; searching various
bug tracker for follow up bug entries makes it even harder :-(

Ciao, Thorsten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Copy user requested buffers into the error state

2017-04-02 Thread Chris Wilson 
On Sat, Apr 01, 2017 at 05:48:55PM -0700, Matt Turner wrote:
> On Wed, Mar 29, 2017 at 8:56 AM, Chris Wilson  
> wrote:
> > Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
> > use to indicate that it wants the contents of this buffer preserved in
> > the error state (/sys/class/drm/cardN/error) following a GPU hang
> > involving this batch.
> >
> > Use this at your discretion, the contents of the error state. although
> > compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
> > eternity (until the error state is destroyed).
> >
> > Based on an earlier patch by Ben Widawsky 
> > Signed-off-by: Chris Wilson 
> > Cc: Ben Widawsky 
> > Cc: Matt Turner 
> > Acked-by: Ben Widawsky 
> > Reviewed-by: Joonas Lahtinen 
> > ---
> 
> Thank you, Chris. With this in place (and a few patches from Ben
> rebased for libdrm and Mesa) I can disassemble the shader program from
> an error state.
> 
> In this case, I turned off the end-of-thread bit on the sendc in order
> to cause a hang:
> 
> render ring --- user = 0x fff75000
> pln(8)  g124<1>Fg4<0,1,0>F  g2<8,8,1>F  {
> align1 1Q compacted };
> pln(8)  g125<1>Fg4.4<0,1,0>Fg2<8,8,1>F  {
> align1 1Q compacted };
> pln(8)  g126<1>Fg5<0,1,0>F  g2<8,8,1>F  {
> align1 1Q compacted };
> pln(8)  g127<1>Fg5.4<0,1,0>Fg2<8,8,1>F  {
> align1 1Q compacted };
> sendc(8)null<1>UW   g124<8,8,1>F
> render RT write SIMD8 LastRT Surface = 0
> mlen 4 rlen 0 { align1 1Q };
> nop ;
> pln(16) g120<1>Fg6<0,1,0>F  g2<8,8,1>F  {
> align1 1H compacted };
> pln(16) g122<1>Fg6.4<0,1,0>Fg2<8,8,1>F  {
> align1 1H compacted };
> pln(16) g124<1>Fg7<0,1,0>F  g2<8,8,1>F  {
> align1 1H compacted };
> pln(16) g126<1>Fg7.4<0,1,0>Fg2<8,8,1>F  {
> align1 1H compacted };
> sendc(16)   null<1>UW   g120<8,8,1>F
> render RT write SIMD16 LastRT Surface = 0
> mlen 8 rlen 0 { align1 1H };
> illegal(1)  { align1 1N };
> 
> Presumably we would like to save more than just instruction buffers.
> Do we have a good way of discerning what each blob of data in the
> error state is?

The prechosen set are named (batch, ring, HW context, HW status,
semaphore). The user ones just have a nondescript 'user'. My thinking
was that either there would be an additional debug only (aub-esque)
buffer added to the execbuf that contained all the useful info to index
the other buffers captured, or userspace puts a header/footer into its
captured batches. I did consider the possibility of adding a tag through
the execobject, maybe 8-bits inside flags, but I prefer the approach
of embedding information into the buffers (much more flexibile).

It is also possible to take the simulator route and decode the buffers
according to the current GPU state, the link between relocation
addresses and buffer address should be sufficient?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx