> From: Gordon, David S
> Sent: Tuesday, January 12, 2016 9:49 PM
>
> On 12/01/2016 11:43, John Harrison wrote:
> > On 12/01/2016 04:37, Tian, Kevin wrote:
> >>> From: john.c.harri...@intel.com
> >>> Sent: Tuesday, January 12, 2016 2:42 AM
> >>>
> >>> From: John Harrison
> >>>
> >>> Implemented a
On 12/01/2016 11:43, John Harrison wrote:
On 12/01/2016 04:37, Tian, Kevin wrote:
From: john.c.harri...@intel.com
Sent: Tuesday, January 12, 2016 2:42 AM
From: John Harrison
Implemented a batch buffer submission scheduler for the i915 DRM
driver.
The general theory of operation is that whe
On 12/01/2016 04:37, Tian, Kevin wrote:
From: john.c.harri...@intel.com
Sent: Tuesday, January 12, 2016 2:42 AM
From: John Harrison
Implemented a batch buffer submission scheduler for the i915 DRM driver.
The general theory of operation is that when batch buffers are
submitted to the driver,
> From: john.c.harri...@intel.com
> Sent: Tuesday, January 12, 2016 2:42 AM
>
> From: John Harrison
>
> Implemented a batch buffer submission scheduler for the i915 DRM driver.
>
> The general theory of operation is that when batch buffers are
> submitted to the driver, the execbuffer() code as
On Mon, Jan 11, 2016 at 06:42:29PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Implemented a batch buffer submission scheduler for the i915 DRM driver.
I've lost track of the number of patches that are a result of not having
per-context seqno and could be eliminated.
> Th
From: John Harrison
Implemented a batch buffer submission scheduler for the i915 DRM driver.
The general theory of operation is that when batch buffers are
submitted to the driver, the execbuffer() code assigns a unique seqno
value and then packages up all the information required to execute the