About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Wang, Zhi A]

Hi Gurus:
  Forgive my junior HW knowledge, I just found that in execlist context initialization function populate_lr_context(), this line:
  
          reg_state[CTX_CONTEXT_CONTROL+1] =
                          _MASKED_BIT_ENABLE((1<<3) | MI_RESTORE_INHIBIT);
  
It seems the "Inhibit Synchronous Context Switch" bit is not set here, so when HW is trying to wait some events, e.g. semaphore, according to Bspec, per my basic understanding, it will switch out current context with some reason bit set. Here comes my question, I think if this situation happen, should i915 remember this context and try to re-schedule it in a proper time, e.g. before submitting a new context until the context_completed bit in CSB is set? I don't find a register that will remember the context switched out by waiting event, so I think it should be i915 to handle this situation or just set "Inhibit Synchronous Context Switch" bit here?... 

Thanks,
Zhi.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Wang, Zhi A]

Ping. If someone can confirm it. I can submit a patch, but I'm concerned about introducing new register bit needs some internal process....

-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Wang, Zhi A
Sent: Monday, February 09, 2015 11:05 PM
To: Intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

Hi Gurus:
  Forgive my junior HW knowledge, I just found that in execlist context initialization function populate_lr_context(), this line:
  
          reg_state[CTX_CONTEXT_CONTROL+1] =
                          _MASKED_BIT_ENABLE((1<<3) | MI_RESTORE_INHIBIT);
  
It seems the "Inhibit Synchronous Context Switch" bit is not set here, so when HW is trying to wait some events, e.g. semaphore, according to Bspec, per my basic understanding, it will switch out current context with some reason bit set. Here comes my question, I think if this situation happen, should i915 remember this context and try to re-schedule it in a proper time, e.g. before submitting a new context until the context_completed bit in CSB is set? I don't find a register that will remember the context switched out by waiting event, so I think it should be i915 to handle this situation or just set "Inhibit Synchronous Context Switch" bit here?... 

Thanks,
Zhi.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Daniel, Thomas]

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Wang, Zhi A
> Sent: Tuesday, February 10, 2015 1:27 PM
> To: Wang, Zhi A; Intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in
> populate_lr_context() intel_lrc.c
> 
> Ping. If someone can confirm it. I can submit a patch, but I'm concerned
> about introducing new register bit needs some internal process....
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Wang, Zhi A
> Sent: Monday, February 09, 2015 11:05 PM
> To: Intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in
> populate_lr_context() intel_lrc.c
> 
> Hi Gurus:
>   Forgive my junior HW knowledge, I just found that in execlist context
> initialization function populate_lr_context(), this line:
> 
>           reg_state[CTX_CONTEXT_CONTROL+1] =
>                           _MASKED_BIT_ENABLE((1<<3) | MI_RESTORE_INHIBIT);
> 
> It seems the "Inhibit Synchronous Context Switch" bit is not set here, so
> when HW is trying to wait some events, e.g. semaphore, according to Bspec,
> per my basic understanding, it will switch out current context with some
> reason bit set. Here comes my question, I think if this situation happen,
> should i915 remember this context and try to re-schedule it in a proper time,
> e.g. before submitting a new context until the context_completed bit in CSB
> is set? I don't find a register that will remember the context switched out by
> waiting event, so I think it should be i915 to handle this situation or just set
> "Inhibit Synchronous Context Switch" bit here?...

I don't think any of these events will be generated when execlists are enabled.  I think there is a plan to use semaphores again, and a similar codepath will be needed to deal with context pre-emption when we support that, in order to re-submit pre-empted contexts.

Thomas.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Wang, Zhi A]

Hi Thomas:
    Thanks for the information! Learned a lot. :) 

I remember that semaphore is disabled on Gen8 for a long time ago. Recently I found it has been enabled. just thought that if a workload which isn't being protected by MI_ARB_ON_OFF may be switched out by failing to wait semaphore here without that bit?

Would you mind to give a help to confirm the correct combos? That would be nice and great helpful to me :)

a. Set "Inhibit Synchronous Context Switch" bit, HW will wait until the condition is true or specific event is generated if SW issue some instructions like MI_SEMAPHORE_WAIT, I thought that's why SW don't need to process CSB with wait_semaphore bit set. But if MI_ARB_ON_OFF is ON, Can SW do a preemption here by submitting a new ELSP write combo? 

b. Clear "Inhibit Synchronous Context Switch", HW will switch out context directly after the condition is false or specific event is not generated at that time, and write a CSB with wait_semaphore bit is set. And SW has to be aware this kinds of CSB in this case I think...

Don't know if there is something I missed...:) Thanks.

-----Original Message-----
From: Daniel, Thomas 
Sent: Tuesday, February 10, 2015 10:17 PM
To: Wang, Zhi A; Wang, Zhi A; Intel-gfx@lists.freedesktop.org
Subject: RE: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> Behalf Of Wang, Zhi A
> Sent: Tuesday, February 10, 2015 1:27 PM
> To: Wang, Zhi A; Intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in
> populate_lr_context() intel_lrc.c
> 
> Ping. If someone can confirm it. I can submit a patch, but I'm 
> concerned about introducing new register bit needs some internal process....
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> Behalf Of Wang, Zhi A
> Sent: Monday, February 09, 2015 11:05 PM
> To: Intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in
> populate_lr_context() intel_lrc.c
> 
> Hi Gurus:
>   Forgive my junior HW knowledge, I just found that in execlist 
> context initialization function populate_lr_context(), this line:
> 
>           reg_state[CTX_CONTEXT_CONTROL+1] =
>                           _MASKED_BIT_ENABLE((1<<3) | 
> MI_RESTORE_INHIBIT);
> 
> It seems the "Inhibit Synchronous Context Switch" bit is not set here, 
> so when HW is trying to wait some events, e.g. semaphore, according to 
> Bspec, per my basic understanding, it will switch out current context 
> with some reason bit set. Here comes my question, I think if this 
> situation happen, should i915 remember this context and try to 
> re-schedule it in a proper time, e.g. before submitting a new context 
> until the context_completed bit in CSB is set? I don't find a register 
> that will remember the context switched out by waiting event, so I 
> think it should be i915 to handle this situation or just set "Inhibit Synchronous Context Switch" bit here?...

I don't think any of these events will be generated when execlists are enabled.  I think there is a plan to use semaphores again, and a similar codepath will be needed to deal with context pre-emption when we support that, in order to re-submit pre-empted contexts.

Thomas.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Daniel, Thomas]

> -----Original Message-----
> From: Wang, Zhi A
> Sent: Tuesday, February 10, 2015 2:44 PM
> To: Daniel, Thomas; Intel-gfx@lists.freedesktop.org
> Subject: RE: About CTX_CONTEXT_CONTROL initialization in
> populate_lr_context() intel_lrc.c
> 
> Hi Thomas:
>     Thanks for the information! Learned a lot. :)
> 
> I remember that semaphore is disabled on Gen8 for a long time ago.
> Recently I found it has been enabled. just thought that if a workload which
> isn't being protected by MI_ARB_ON_OFF may be switched out by failing to
> wait semaphore here without that bit?
Please check i915_drv.c i915_semaphore_is_enabled - should return false if execlists are enabled, or if we are on Gen8.

> Would you mind to give a help to confirm the correct combos? That would be
> nice and great helpful to me :)
> 
> a. Set "Inhibit Synchronous Context Switch" bit, HW will wait until the
> condition is true or specific event is generated if SW issue some instructions
> like MI_SEMAPHORE_WAIT, I thought that's why SW don't need to process
> CSB with wait_semaphore bit set. But if MI_ARB_ON_OFF is ON, Can SW do a
> preemption here by submitting a new ELSP write combo?
Correct.  However the driver will never cause a pre-emption in this way at the moment.
 
> b. Clear "Inhibit Synchronous Context Switch", HW will switch out context
> directly after the condition is false or specific event is not generated at that
> time, and write a CSB with wait_semaphore bit is set. And SW has to be
> aware this kinds of CSB in this case I think...
Correct.  But as I said, I don't think any of these events will be generated.

Thomas.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Wang, Zhi A]

Very appreciate. :) Thanks Thomas!

-----Original Message-----
From: Daniel, Thomas 
Sent: Tuesday, February 10, 2015 10:56 PM
To: Wang, Zhi A; Intel-gfx@lists.freedesktop.org
Subject: RE: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

> -----Original Message-----
> From: Wang, Zhi A
> Sent: Tuesday, February 10, 2015 2:44 PM
> To: Daniel, Thomas; Intel-gfx@lists.freedesktop.org
> Subject: RE: About CTX_CONTEXT_CONTROL initialization in
> populate_lr_context() intel_lrc.c
> 
> Hi Thomas:
>     Thanks for the information! Learned a lot. :)
> 
> I remember that semaphore is disabled on Gen8 for a long time ago.
> Recently I found it has been enabled. just thought that if a workload 
> which isn't being protected by MI_ARB_ON_OFF may be switched out by 
> failing to wait semaphore here without that bit?
Please check i915_drv.c i915_semaphore_is_enabled - should return false if execlists are enabled, or if we are on Gen8.

> Would you mind to give a help to confirm the correct combos? That 
> would be nice and great helpful to me :)
> 
> a. Set "Inhibit Synchronous Context Switch" bit, HW will wait until 
> the condition is true or specific event is generated if SW issue some 
> instructions like MI_SEMAPHORE_WAIT, I thought that's why SW don't 
> need to process CSB with wait_semaphore bit set. But if MI_ARB_ON_OFF 
> is ON, Can SW do a preemption here by submitting a new ELSP write combo?
Correct.  However the driver will never cause a pre-emption in this way at the moment.
 
> b. Clear "Inhibit Synchronous Context Switch", HW will switch out 
> context directly after the condition is false or specific event is not 
> generated at that time, and write a CSB with wait_semaphore bit is 
> set. And SW has to be aware this kinds of CSB in this case I think...
Correct.  But as I said, I don't think any of these events will be generated.

Thomas.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Dave Gordon]

On 09/02/15 15:05, Wang, Zhi A wrote:
> Hi Gurus:
> Forgive my junior HW knowledge, I just found that in execlist
> context initialization function populate_lr_context(), this line:
>   
>           reg_state[CTX_CONTEXT_CONTROL+1] =
>                           _MASKED_BIT_ENABLE((1<<3) | MI_RESTORE_INHIBIT);
>   
> It seems the "Inhibit Synchronous Context Switch" bit is not set
> here, so when HW is trying to wait some events, e.g. semaphore, according to
> Bspec, per my basic understanding, it will switch out current context
> with some reason bit set. Here comes my question, I think if this
> situation happen, should i915 remember this context and try to
> re-schedule it in a proper time, e.g. before submitting a new context
> until the context_completed bit in CSB is set? I don't find a register
> that will remember the context switched out by waiting event, so I think
> it should be i915 to handle this situation or just set "Inhibit
> Synchronous Context Switch" bit here?...

But that's exactly what it does already ... it sets bit 3, which is the
"Inhibit Synchronous Context Switch" bit you refer to.

What's wrong here is that it should use a #define for this bit, and for
the "Restore Inhibit" bit -- for which it's actually using a value
defined in a completely different context (no pun intended), namely the
bits in a MI_SET_CONTEXT *instruction*. It just happens to work because
they have the same numerical value. So, what we need is:

<intel_lrc.h>

#define RING_CONTEXT_CONTROL(ring)   	   ((ring)->mmio_base+0x244)
#define	  CTX_CTRL_INHIBIT_SYN_CTX_SWITCH	(1 << 3)
#define	  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT	(1 << 0)

and then change the line you pointed out to use the correct symbolic names.

.Dave.

> Thanks,
> Zhi.
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Daniel Vetter]

On Tue, Feb 10, 2015 at 04:25:20PM +0000, Dave Gordon wrote:
> On 09/02/15 15:05, Wang, Zhi A wrote:
> > Hi Gurus:
> > Forgive my junior HW knowledge, I just found that in execlist
> > context initialization function populate_lr_context(), this line:
> >   
> >           reg_state[CTX_CONTEXT_CONTROL+1] =
> >                           _MASKED_BIT_ENABLE((1<<3) | MI_RESTORE_INHIBIT);
> >   
> > It seems the "Inhibit Synchronous Context Switch" bit is not set
> > here, so when HW is trying to wait some events, e.g. semaphore, according to
> > Bspec, per my basic understanding, it will switch out current context
> > with some reason bit set. Here comes my question, I think if this
> > situation happen, should i915 remember this context and try to
> > re-schedule it in a proper time, e.g. before submitting a new context
> > until the context_completed bit in CSB is set? I don't find a register
> > that will remember the context switched out by waiting event, so I think
> > it should be i915 to handle this situation or just set "Inhibit
> > Synchronous Context Switch" bit here?...
> 
> But that's exactly what it does already ... it sets bit 3, which is the
> "Inhibit Synchronous Context Switch" bit you refer to.
> 
> What's wrong here is that it should use a #define for this bit, and for
> the "Restore Inhibit" bit -- for which it's actually using a value
> defined in a completely different context (no pun intended), namely the
> bits in a MI_SET_CONTEXT *instruction*. It just happens to work because
> they have the same numerical value. So, what we need is:
> 
> <intel_lrc.h>
> 
> #define RING_CONTEXT_CONTROL(ring)   	   ((ring)->mmio_base+0x244)
> #define	  CTX_CTRL_INHIBIT_SYN_CTX_SWITCH	(1 << 3)
> #define	  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT	(1 << 0)
> 
> and then change the line you pointed out to use the correct symbolic names.

Can I have this in patch form please? I.e. convert to diff, paste the
above into commit message and add sob line.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Wang, Zhi A]

Hi Daniel & Gordon & Thomas:
    Just found that, my bad. Thanks for giving so much introduction for me, a beginner. :)  Let me cook a patch for it. 
   BTW: CTXT_SR_CTRL register looks like a register needs mask. Does the bit 0 restore inhibit also needs _MASKED_BIT_ENABLE here? It looks like bit 0 is not set with _MASKED_BIT_ENABLE().

-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, February 11, 2015 6:19 AM
To: Gordon, David S
Cc: Wang, Zhi A; Daniel, Thomas; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

On Tue, Feb 10, 2015 at 04:25:20PM +0000, Dave Gordon wrote:
> On 09/02/15 15:05, Wang, Zhi A wrote:
> > Hi Gurus:
> > Forgive my junior HW knowledge, I just found that in execlist 
> > context initialization function populate_lr_context(), this line:
> >   
> >           reg_state[CTX_CONTEXT_CONTROL+1] =
> >                           _MASKED_BIT_ENABLE((1<<3) | 
> > MI_RESTORE_INHIBIT);
> >   
> > It seems the "Inhibit Synchronous Context Switch" bit is not set 
> > here, so when HW is trying to wait some events, e.g. semaphore, 
> > according to Bspec, per my basic understanding, it will switch out 
> > current context with some reason bit set. Here comes my question, I 
> > think if this situation happen, should i915 remember this context 
> > and try to re-schedule it in a proper time, e.g. before submitting a 
> > new context until the context_completed bit in CSB is set? I don't 
> > find a register that will remember the context switched out by 
> > waiting event, so I think it should be i915 to handle this situation 
> > or just set "Inhibit Synchronous Context Switch" bit here?...
> 
> But that's exactly what it does already ... it sets bit 3, which is 
> the "Inhibit Synchronous Context Switch" bit you refer to.
> 
> What's wrong here is that it should use a #define for this bit, and 
> for the "Restore Inhibit" bit -- for which it's actually using a value 
> defined in a completely different context (no pun intended), namely 
> the bits in a MI_SET_CONTEXT *instruction*. It just happens to work 
> because they have the same numerical value. So, what we need is:
> 
> <intel_lrc.h>
> 
> #define RING_CONTEXT_CONTROL(ring)   	   ((ring)->mmio_base+0x244)
> #define	  CTX_CTRL_INHIBIT_SYN_CTX_SWITCH	(1 << 3)
> #define	  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT	(1 << 0)
> 
> and then change the line you pointed out to use the correct symbolic names.

Can I have this in patch form please? I.e. convert to diff, paste the above into commit message and add sob line.

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

[Wang, Zhi A]

Sorry it's correct, has already been set with _MASK_ENABLE_BIT(). Let me cook a patch. :)

-----Original Message-----
From: Wang, Zhi A 
Sent: Wednesday, February 11, 2015 8:18 AM
To: 'Daniel Vetter'; Gordon, David S
Cc: Daniel, Thomas; Intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

Hi Daniel & Gordon & Thomas:
    Just found that, my bad. Thanks for giving so much introduction for me, a beginner. :)  Let me cook a patch for it. 
   BTW: CTXT_SR_CTRL register looks like a register needs mask. Does the bit 0 restore inhibit also needs _MASKED_BIT_ENABLE here? It looks like bit 0 is not set with _MASKED_BIT_ENABLE().

-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, February 11, 2015 6:19 AM
To: Gordon, David S
Cc: Wang, Zhi A; Daniel, Thomas; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] About CTX_CONTEXT_CONTROL initialization in populate_lr_context() intel_lrc.c

On Tue, Feb 10, 2015 at 04:25:20PM +0000, Dave Gordon wrote:
> On 09/02/15 15:05, Wang, Zhi A wrote:
> > Hi Gurus:
> > Forgive my junior HW knowledge, I just found that in execlist 
> > context initialization function populate_lr_context(), this line:
> >   
> >           reg_state[CTX_CONTEXT_CONTROL+1] =
> >                           _MASKED_BIT_ENABLE((1<<3) | 
> > MI_RESTORE_INHIBIT);
> >   
> > It seems the "Inhibit Synchronous Context Switch" bit is not set 
> > here, so when HW is trying to wait some events, e.g. semaphore, 
> > according to Bspec, per my basic understanding, it will switch out 
> > current context with some reason bit set. Here comes my question, I 
> > think if this situation happen, should i915 remember this context 
> > and try to re-schedule it in a proper time, e.g. before submitting a 
> > new context until the context_completed bit in CSB is set? I don't 
> > find a register that will remember the context switched out by 
> > waiting event, so I think it should be i915 to handle this situation 
> > or just set "Inhibit Synchronous Context Switch" bit here?...
> 
> But that's exactly what it does already ... it sets bit 3, which is 
> the "Inhibit Synchronous Context Switch" bit you refer to.
> 
> What's wrong here is that it should use a #define for this bit, and 
> for the "Restore Inhibit" bit -- for which it's actually using a value 
> defined in a completely different context (no pun intended), namely 
> the bits in a MI_SET_CONTEXT *instruction*. It just happens to work 
> because they have the same numerical value. So, what we need is:
> 
> <intel_lrc.h>
> 
> #define RING_CONTEXT_CONTROL(ring)   	   ((ring)->mmio_base+0x244)
> #define	  CTX_CTRL_INHIBIT_SYN_CTX_SWITCH	(1 << 3)
> #define	  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT	(1 << 0)
> 
> and then change the line you pointed out to use the correct symbolic names.

Can I have this in patch form please? I.e. convert to diff, paste the above into commit message and add sob line.

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx