Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

[Belgaumkar, Vinay]

On 2/1/2018 3:58 PM, Belgaumkar, Vinay wrote:



On 1/15/2018 2:38 AM, Tvrtko Ursulin wrote:


On 11/01/2018 19:17, Daniele Ceraolo Spurio wrote:



On 10/01/18 02:12, Chris Wilson wrote:

Quoting Paulo Zanoni (2018-01-09 23:23:17)

From: Tvrtko Ursulin 

Since it is not possible to mask individual engine instances
and they are all permanently unmasked we do not need to do
anything for engine interrupt management.


This scares me as we will more than double our interrupt generation 
rate

as we have a breadcrumb interrupt after every request, just in case we
need to synchronize with the request. We've been relying on the ability
to mask those interrupts off, as historically we have been able to
saturate cpus with the amount of interrupts we could generate.
-Chris


We do have masks per instance, but they're in gunit and not in the 
CS. they're defined in patch 4 of this series:


+#define GEN11_RCS0_RSVD_INTR_MASK    _MMIO(0x190090)
+#define GEN11_BCS_RSVD_INTR_MASK    _MMIO(0x1900a0)
+#define GEN11_VCS0_VCS1_INTR_MASK    _MMIO(0x1900a8)
+#define GEN11_VCS2_VCS3_INTR_MASK    _MMIO(0x1900ac)
+#define GEN11_VECS0_VECS1_INTR_MASK    _MMIO(0x1900d0)

Each instance gets half of a register for a 16 bits vector. I think 
there was some gotcha with the masks being in gunit but can't 
remember exactly what. Tvrtko, do you remember anything on this?


I remember the message was to not use them since they were pencilled 
in for removal from the HW. There was some issue with them in general 
which made that decision attractive, coupled with the fact other OS 
did not have a need for them.


If that removal did not materialize we could perhaps revisit the 
plans. It would require a locked RMW cycle as minimum since there are 
two instances in each reg but that probably isn't such a big deal.


So yeah, I think summary would be someone needs to pull on sleeves of 
a HW designer, or someone close, to check what happened with the 
removal plans, and what exactly was the problematic bit with frequent 
(un)masking.


I asked the hardware team about the removal, and that does not seem to 
be the case. I have added you to the email if you want more clarification.


Please disregard that comment, looks like there was already a separate 
discussion on this.


Thanks,
Vinay.



Thanks,
Vinay.



Regards,

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

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

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

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

[Belgaumkar, Vinay]

On 1/15/2018 2:38 AM, Tvrtko Ursulin wrote:


On 11/01/2018 19:17, Daniele Ceraolo Spurio wrote:



On 10/01/18 02:12, Chris Wilson wrote:

Quoting Paulo Zanoni (2018-01-09 23:23:17)

From: Tvrtko Ursulin 

Since it is not possible to mask individual engine instances
and they are all permanently unmasked we do not need to do
anything for engine interrupt management.


This scares me as we will more than double our interrupt generation rate
as we have a breadcrumb interrupt after every request, just in case we
need to synchronize with the request. We've been relying on the ability
to mask those interrupts off, as historically we have been able to
saturate cpus with the amount of interrupts we could generate.
-Chris


We do have masks per instance, but they're in gunit and not in the CS. 
they're defined in patch 4 of this series:


+#define GEN11_RCS0_RSVD_INTR_MASK    _MMIO(0x190090)
+#define GEN11_BCS_RSVD_INTR_MASK    _MMIO(0x1900a0)
+#define GEN11_VCS0_VCS1_INTR_MASK    _MMIO(0x1900a8)
+#define GEN11_VCS2_VCS3_INTR_MASK    _MMIO(0x1900ac)
+#define GEN11_VECS0_VECS1_INTR_MASK    _MMIO(0x1900d0)

Each instance gets half of a register for a 16 bits vector. I think 
there was some gotcha with the masks being in gunit but can't remember 
exactly what. Tvrtko, do you remember anything on this?


I remember the message was to not use them since they were pencilled in 
for removal from the HW. There was some issue with them in general which 
made that decision attractive, coupled with the fact other OS did not 
have a need for them.


If that removal did not materialize we could perhaps revisit the plans. 
It would require a locked RMW cycle as minimum since there are two 
instances in each reg but that probably isn't such a big deal.


So yeah, I think summary would be someone needs to pull on sleeves of a 
HW designer, or someone close, to check what happened with the removal 
plans, and what exactly was the problematic bit with frequent (un)masking.


I asked the hardware team about the removal, and that does not seem to 
be the case. I have added you to the email if you want more clarification.


Thanks,
Vinay.



Regards,

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

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

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

[Tvrtko Ursulin]

On 11/01/2018 19:17, Daniele Ceraolo Spurio wrote:



On 10/01/18 02:12, Chris Wilson wrote:

Quoting Paulo Zanoni (2018-01-09 23:23:17)

From: Tvrtko Ursulin 

Since it is not possible to mask individual engine instances
and they are all permanently unmasked we do not need to do
anything for engine interrupt management.


This scares me as we will more than double our interrupt generation rate
as we have a breadcrumb interrupt after every request, just in case we
need to synchronize with the request. We've been relying on the ability
to mask those interrupts off, as historically we have been able to
saturate cpus with the amount of interrupts we could generate.
-Chris


We do have masks per instance, but they're in gunit and not in the CS. 
they're defined in patch 4 of this series:


+#define GEN11_RCS0_RSVD_INTR_MASK    _MMIO(0x190090)
+#define GEN11_BCS_RSVD_INTR_MASK    _MMIO(0x1900a0)
+#define GEN11_VCS0_VCS1_INTR_MASK    _MMIO(0x1900a8)
+#define GEN11_VCS2_VCS3_INTR_MASK    _MMIO(0x1900ac)
+#define GEN11_VECS0_VECS1_INTR_MASK    _MMIO(0x1900d0)

Each instance gets half of a register for a 16 bits vector. I think 
there was some gotcha with the masks being in gunit but can't remember 
exactly what. Tvrtko, do you remember anything on this?


I remember the message was to not use them since they were pencilled in 
for removal from the HW. There was some issue with them in general which 
made that decision attractive, coupled with the fact other OS did not 
have a need for them.


If that removal did not materialize we could perhaps revisit the plans. 
It would require a locked RMW cycle as minimum since there are two 
instances in each reg but that probably isn't such a big deal.


So yeah, I think summary would be someone needs to pull on sleeves of a 
HW designer, or someone close, to check what happened with the removal 
plans, and what exactly was the problematic bit with frequent (un)masking.


Regards,

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

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

[Daniele Ceraolo Spurio]

On 10/01/18 02:12, Chris Wilson wrote:

Quoting Paulo Zanoni (2018-01-09 23:23:17)

From: Tvrtko Ursulin 

Since it is not possible to mask individual engine instances
and they are all permanently unmasked we do not need to do
anything for engine interrupt management.


This scares me as we will more than double our interrupt generation rate
as we have a breadcrumb interrupt after every request, just in case we
need to synchronize with the request. We've been relying on the ability
to mask those interrupts off, as historically we have been able to
saturate cpus with the amount of interrupts we could generate.
-Chris


We do have masks per instance, but they're in gunit and not in the CS. 
they're defined in patch 4 of this series:


+#define GEN11_RCS0_RSVD_INTR_MASK  _MMIO(0x190090)
+#define GEN11_BCS_RSVD_INTR_MASK   _MMIO(0x1900a0)
+#define GEN11_VCS0_VCS1_INTR_MASK  _MMIO(0x1900a8)
+#define GEN11_VCS2_VCS3_INTR_MASK  _MMIO(0x1900ac)
+#define GEN11_VECS0_VECS1_INTR_MASK_MMIO(0x1900d0)

Each instance gets half of a register for a 16 bits vector. I think 
there was some gotcha with the masks being in gunit but can't remember 
exactly what. Tvrtko, do you remember anything on this?


Thanks,
Daniele


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


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

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

[Chris Wilson]

Quoting Paulo Zanoni (2018-01-09 23:23:17)
> From: Tvrtko Ursulin 
> 
> Since it is not possible to mask individual engine instances
> and they are all permanently unmasked we do not need to do
> anything for engine interrupt management.

This scares me as we will more than double our interrupt generation rate
as we have a breadcrumb interrupt after every request, just in case we
need to synchronize with the request. We've been relying on the ability
to mask those interrupts off, as historically we have been able to
saturate cpus with the amount of interrupts we could generate.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx