On 14/10/2015 15:42, Dave Gordon wrote:
On 13/10/15 12:36, Chris Wilson wrote:
On Tue, Oct 13, 2015 at 01:29:56PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 06:23:50PM +0100, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 10
On 13/10/15 12:36, Chris Wilson wrote:
On Tue, Oct 13, 2015 at 01:29:56PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 06:23:50PM +0100, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
On F
On Tue, Oct 13, 2015 at 01:29:56PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 06:23:50PM +0100, Chris Wilson wrote:
> > On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> > > > On Fri, Oct 09, 2015 at 11:15
On Fri, Oct 09, 2015 at 06:23:50PM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> > > On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote:
> > > > My idea was to create a new r
On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> > On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote:
> > > My idea was to create a new request for 3. which gets signalled by the
> > > scheduler in intel_lrc
On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote:
> > My idea was to create a new request for 3. which gets signalled by the
> > scheduler in intel_lrc_irq_handler. My idea was that we'd only create
> > these when a ctx sw
On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote:
> My idea was to create a new request for 3. which gets signalled by the
> scheduler in intel_lrc_irq_handler. My idea was that we'd only create
> these when a ctx switch might occur to avoid overhead, but I guess if we
> just outright
On Fri, Oct 09, 2015 at 09:36:58AM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 09:58:51AM +0200, Daniel Vetter wrote:
> > > > +static bool i915_gem_request_retireable(struct drm_i915_gem_request
> > > > *req)
> > > > +{
> > > > + return (i915_gem_request_completed(req, true) &&
> >
On Fri, Oct 09, 2015 at 09:58:51AM +0200, Daniel Vetter wrote:
> > > +static bool i915_gem_request_retireable(struct drm_i915_gem_request *req)
> > > +{
> > > + return (i915_gem_request_completed(req, true) &&
> > > + (!req->elsp_submitted || req->ctx_complete));
> >
> > I disagree with th
On Thu, Oct 08, 2015 at 01:32:07PM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 03:52:01PM +0100, Nick Hoath wrote:
> > There is a desire to simplify the i915 driver by reducing the number of
> > different code paths introduced by the LRC / execlists support. As the
> > execlists request i
On Tue, Oct 06, 2015 at 03:52:01PM +0100, Nick Hoath wrote:
> There is a desire to simplify the i915 driver by reducing the number of
> different code paths introduced by the LRC / execlists support. As the
> execlists request is now part of the gem request it is possible and
> desirable to unify
On Wed, Oct 07, 2015 at 06:03:48PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 03:52:01PM +0100, Nick Hoath wrote:
> > There is a desire to simplify the i915 driver by reducing the number of
> > different code paths introduced by the LRC / execlists support. As the
> > execlists request
On Tue, Oct 06, 2015 at 03:52:01PM +0100, Nick Hoath wrote:
> There is a desire to simplify the i915 driver by reducing the number of
> different code paths introduced by the LRC / execlists support. As the
> execlists request is now part of the gem request it is possible and
> desirable to unify
There is a desire to simplify the i915 driver by reducing the number of
different code paths introduced by the LRC / execlists support. As the
execlists request is now part of the gem request it is possible and
desirable to unify the request life-cycles for execlist and legacy
requests.
Added a c
14 matches
Mail list logo
