Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

2019-01-09 Thread Chris Wilson
Quoting Kenneth Graunke (2019-01-09 09:02:35)
> Does it work if you emit 3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP after
> MI_SET_CONTEXT?  That was the source of most CONSTANT_BUFFER hangs
> I saw on Broadwater/Crestline.  Notably, it's also a bug that was
> fixed on Eaglelake/Cantiga...

Thanks for the suggestion, but alas no. Which makes sense if my
understanding is correct and it is the immediate execution of
CONSTANT_BUFFER inside the context image that is triggering the hang --
we don't even reach the next primitive.

I think have DevCL happy (at least as far as a few runs through piglit
can determine), now to double check DevCTG, DevILK. Alas I have no
gen4/gen5 desktop machines to hand.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

2019-01-09 Thread Kenneth Graunke
On Tuesday, January 8, 2019 5:02:59 PM PST Chris Wilson wrote:
> Quoting Chris Wilson (2019-01-08 12:28:18)
> > Broadwater and the rest of gen4  do support being able to saving and
> > reloading context specific registers between contexts, providing isolation
> > of the basic GPU state (as programmable by userspace). This allows
> > userspace to assume that the GPU retains their state from one batch to the
> > next, minimising the amount of state it needs to reload and manually save
> > across batches.
> 
> Well Crestline's render context contains a nasty booby trap.
> 
> [  152.065764] hangcheck rcs0
> [  152.065770] hangcheck  current seqno 1b89, last 1bc5, hangcheck 1b89 
> [5984 ms]
> [  152.065773] hangcheck  Reset count: 0 (global 0)
> [  152.065774] hangcheck  Requests:
> [  152.065779] hangcheck  first  1b8a* [5:1b8a] @ 7376ms: rcs0
> [  152.065783] hangcheck  last   1bc5+ [5:1bc5] @ 7328ms: rcs0
> [  152.065786] hangcheck  active 1b8a* [5:1b8a] @ 7376ms: rcs0
> [  152.065789] hangcheck  ring->start:  0x4000
> [  152.065792] hangcheck  ring->head:   0x00017dd0
> [  152.065794] hangcheck  ring->tail:   0x00019fb0
> [  152.065795] hangcheck  ring->emit:   0x00019fb0
> [  152.065797] hangcheck  ring->space:  0x50a0
> [  152.065801] hangcheck [head 17df0, postfix 17e60, tail 17e80, batch 
> 0x_00335000]:
> [  152.065809] hangcheck [] 0202 7a004002 1fffe004   
> 0200 0200 0200
> [  152.065813] hangcheck [0020] 0200 0200 0200 0200 0200 
> 0200 0200 0200
> [  152.065817] hangcheck [0040] 0200 7a004002 1fffe004   
> 0202  0c00
> [  152.065821] hangcheck [0060] 0032f10c  18800180 00335000 0200 
> 1081 0100 1b8a
> [  152.065825] hangcheck [0080] 1081 00c0 1b8a 0100
> [  152.065829] hangcheck  CCID: 0x0003210d
> [  152.065831] hangcheck  RING_START: 0x4000
> [  152.065834] hangcheck  RING_HEAD:  0x00017e54
> [  152.065836] hangcheck  RING_TAIL:  0x00019fb0
> [  152.065839] hangcheck  RING_CTL:   0x0001f001
> [  152.065841] hangcheck  RING_MODE:  0x0040
> [  152.065844] hangcheck  ACTHD:  0x_00e17e54
> [  152.065847] hangcheck  BBADDR: 0x_002f81e0
> [  152.065849] hangcheck  DMA_FADDR: 0x_0001be50
> [  152.065851] hangcheck  IPEIR: 0x
> [  152.065853] hangcheck  IPEHR: 0x60020100 # CONSTANT_BUFFER see 0x1d4
> [  152.065860] hangcheck  E 1b8a* [5:1b8a] @ 7376ms: rcs0
> [  152.065864] hangcheck  E 1b8b+ [5:1b8b] @ 7376ms: rcs0
> [  152.065867] hangcheck  E 1b8c [5:1b8c] @ 7376ms: rcs0
> [  152.065870] hangcheck  E 1b8d [5:1b8d] @ 7376ms: rcs0
> [  152.065873] hangcheck  E 1b8e [5:1b8e] @ 7376ms: rcs0
> [  152.065877] hangcheck  E 1b8f [5:1b8f] @ 7376ms: rcs0
> [  152.065880] hangcheck  E 1b90 [5:1b90] @ 7372ms: rcs0
> [  152.065888] hangcheck  ...skipping 52 executing requests...
> [  152.065891] hangcheck  E 1bc5+ [5:1bc5] @ 7328ms: rcs0
> [  152.065893] hangcheck  Queue priority: -2147483648
> [  152.065909] hangcheck HWSP:
> [  152.065913] hangcheck []      
>   
> [  152.065915] hangcheck *
> [  152.065919] hangcheck [00c0] 1b89     
>   
> [  152.065923] hangcheck [00e0]      
>   
> [  152.065927] hangcheck [0100] 1b89     
>   
> [  152.065931] hangcheck [0120]      
>   
> [  152.065933] hangcheck *
> [  152.065945] hangcheck Context:
> [  152.065960] hangcheck []  112b 2120 6800 2124 
> 0180 20e4 0044
> [  152.065966] hangcheck [0020] 20c0  2310 0010 2314 
>  2318 0008
> [  152.065970] hangcheck [0040] 231c  2320  2324 
>  2328 
> [  152.065975] hangcheck [0060] 232c  2330  2334 
>  2338 
> [  152.065980] hangcheck [0080] 233c  2340  2344 
>  2348 
> [  152.065985] hangcheck [00a0] 234c  2350  2354 
>   
> [  152.065990] hangcheck [00c0] 6104 6001 0014 60003f01 0320a020 
> 1042 6002 0001
> [  152.065994] hangcheck [00e0] 61010004 0001 00316001 0001 0001 
> 0001 6102 
> [  152.065999] hangcheck [0100] 7902    79050003 
> 2c08007f 00035000 
> [  152.066004] hangcheck [0120] 0

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

2019-01-08 Thread Chris Wilson
Quoting Chris Wilson (2019-01-08 12:28:18)
> Broadwater and the rest of gen4  do support being able to saving and
> reloading context specific registers between contexts, providing isolation
> of the basic GPU state (as programmable by userspace). This allows
> userspace to assume that the GPU retains their state from one batch to the
> next, minimising the amount of state it needs to reload and manually save
> across batches.

Well Crestline's render context contains a nasty booby trap.

[  152.065764] hangcheck rcs0
[  152.065770] hangcheckcurrent seqno 1b89, last 1bc5, hangcheck 1b89 
[5984 ms]
[  152.065773] hangcheckReset count: 0 (global 0)
[  152.065774] hangcheckRequests:
[  152.065779] hangcheckfirst  1b8a* [5:1b8a] @ 7376ms: rcs0
[  152.065783] hangchecklast   1bc5+ [5:1bc5] @ 7328ms: rcs0
[  152.065786] hangcheckactive 1b8a* [5:1b8a] @ 7376ms: rcs0
[  152.065789] hangcheckring->start:  0x4000
[  152.065792] hangcheckring->head:   0x00017dd0
[  152.065794] hangcheckring->tail:   0x00019fb0
[  152.065795] hangcheckring->emit:   0x00019fb0
[  152.065797] hangcheckring->space:  0x50a0
[  152.065801] hangcheck [head 17df0, postfix 17e60, tail 17e80, batch 
0x_00335000]:
[  152.065809] hangcheck [] 0202 7a004002 1fffe004   
0200 0200 0200
[  152.065813] hangcheck [0020] 0200 0200 0200 0200 0200 
0200 0200 0200
[  152.065817] hangcheck [0040] 0200 7a004002 1fffe004   
0202  0c00
[  152.065821] hangcheck [0060] 0032f10c  18800180 00335000 0200 
1081 0100 1b8a
[  152.065825] hangcheck [0080] 1081 00c0 1b8a 0100
[  152.065829] hangcheckCCID: 0x0003210d
[  152.065831] hangcheckRING_START: 0x4000
[  152.065834] hangcheckRING_HEAD:  0x00017e54
[  152.065836] hangcheckRING_TAIL:  0x00019fb0
[  152.065839] hangcheckRING_CTL:   0x0001f001
[  152.065841] hangcheckRING_MODE:  0x0040
[  152.065844] hangcheckACTHD:  0x_00e17e54
[  152.065847] hangcheckBBADDR: 0x_002f81e0
[  152.065849] hangcheckDMA_FADDR: 0x_0001be50
[  152.065851] hangcheckIPEIR: 0x
[  152.065853] hangcheckIPEHR: 0x60020100 # CONSTANT_BUFFER see 0x1d4
[  152.065860] hangcheckE 1b8a* [5:1b8a] @ 7376ms: rcs0
[  152.065864] hangcheckE 1b8b+ [5:1b8b] @ 7376ms: rcs0
[  152.065867] hangcheckE 1b8c [5:1b8c] @ 7376ms: rcs0
[  152.065870] hangcheckE 1b8d [5:1b8d] @ 7376ms: rcs0
[  152.065873] hangcheckE 1b8e [5:1b8e] @ 7376ms: rcs0
[  152.065877] hangcheckE 1b8f [5:1b8f] @ 7376ms: rcs0
[  152.065880] hangcheckE 1b90 [5:1b90] @ 7372ms: rcs0
[  152.065888] hangcheck...skipping 52 executing requests...
[  152.065891] hangcheckE 1bc5+ [5:1bc5] @ 7328ms: rcs0
[  152.065893] hangcheckQueue priority: -2147483648
[  152.065909] hangcheck HWSP:
[  152.065913] hangcheck []      
  
[  152.065915] hangcheck *
[  152.065919] hangcheck [00c0] 1b89     
  
[  152.065923] hangcheck [00e0]      
  
[  152.065927] hangcheck [0100] 1b89     
  
[  152.065931] hangcheck [0120]      
  
[  152.065933] hangcheck *
[  152.065945] hangcheck Context:
[  152.065960] hangcheck []  112b 2120 6800 2124 
0180 20e4 0044
[  152.065966] hangcheck [0020] 20c0  2310 0010 2314 
 2318 0008
[  152.065970] hangcheck [0040] 231c  2320  2324 
 2328 
[  152.065975] hangcheck [0060] 232c  2330  2334 
 2338 
[  152.065980] hangcheck [0080] 233c  2340  2344 
 2348 
[  152.065985] hangcheck [00a0] 234c  2350  2354 
  
[  152.065990] hangcheck [00c0] 6104 6001 0014 60003f01 0320a020 
1042 6002 0001
[  152.065994] hangcheck [00e0] 61010004 0001 00316001 0001 0001 
0001 6102 
[  152.065999] hangcheck [0100] 7902    79050003 
2c08007f 00035000 
[  152.066004] hangcheck [0120]  79040002  f792ec01 0f9fa8a6 
79040002 4000 f7bdfd51
[  152.066009] hangcheck [0140] 2fdfb8e7 79040002 8000 7392fc15 efdfacb6 
79040002 c000 b5d2ec4

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

2019-01-08 Thread Ville Syrjälä
On Tue, Jan 08, 2019 at 12:28:18PM +, Chris Wilson wrote:
> Broadwater and the rest of gen4  do support being able to saving and
> reloading context specific registers between contexts, providing isolation
> of the basic GPU state (as programmable by userspace). This allows
> userspace to assume that the GPU retains their state from one batch to the
> next, minimising the amount of state it needs to reload and manually save
> across batches.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Kenneth Graunke 

Reading through the old mails on the subject this looks fine.

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index f89b8f199e3f..88109e0de051 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -219,6 +219,7 @@ __intel_engine_context_size(struct drm_i915_private 
> *dev_priv, u8 class)
>   return round_up(GEN6_CXT_TOTAL_SIZE(cxt_size) * 64,
>   PAGE_SIZE);
>   case 5:
> + case 4:
>   /*
>* There is a discrepancy here between the size reported
>* by the register and the size of the context layout
> @@ -235,7 +236,6 @@ __intel_engine_context_size(struct drm_i915_private 
> *dev_priv, u8 class)
>cxt_size * 64,
>cxt_size - 1);
>   return round_up(cxt_size * 64, PAGE_SIZE);
> - case 4:
>   case 3:
>   case 2:
>   /* For the special day when i810 gets merged. */
> -- 
> 2.20.1

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


[Intel-gfx] [PATCH 2/2] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

2019-01-08 Thread Chris Wilson
Broadwater and the rest of gen4  do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimising the amount of state it needs to reload and manually save
across batches.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Kenneth Graunke 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index f89b8f199e3f..88109e0de051 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -219,6 +219,7 @@ __intel_engine_context_size(struct drm_i915_private 
*dev_priv, u8 class)
return round_up(GEN6_CXT_TOTAL_SIZE(cxt_size) * 64,
PAGE_SIZE);
case 5:
+   case 4:
/*
 * There is a discrepancy here between the size reported
 * by the register and the size of the context layout
@@ -235,7 +236,6 @@ __intel_engine_context_size(struct drm_i915_private 
*dev_priv, u8 class)
 cxt_size * 64,
 cxt_size - 1);
return round_up(cxt_size * 64, PAGE_SIZE);
-   case 4:
case 3:
case 2:
/* For the special day when i810 gets merged. */
-- 
2.20.1

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