On Fri, Dec 11, 2015 at 12:29:40PM +, Chris Wilson wrote:
> On Fri, Dec 11, 2015 at 12:19:09PM +, Dave Gordon wrote:
> > On 10/12/15 08:58, Daniel Vetter wrote:
> > >On Mon, Dec 07, 2015 at 12:51:49PM +, Dave Gordon wrote:
> > >>I think I missed i915_gem_phys_pwrite().
> > >>
> > >>i915
On Fri, Dec 11, 2015 at 12:19:09PM +, Dave Gordon wrote:
> On 10/12/15 08:58, Daniel Vetter wrote:
> >On Mon, Dec 07, 2015 at 12:51:49PM +, Dave Gordon wrote:
> >>I think I missed i915_gem_phys_pwrite().
> >>
> >>i915_gem_gtt_pwrite_fast() marks the object dirty for most cases (vit
> >>set_
On 10/12/15 08:58, Daniel Vetter wrote:
On Mon, Dec 07, 2015 at 12:51:49PM +, Dave Gordon wrote:
I think I missed i915_gem_phys_pwrite().
i915_gem_gtt_pwrite_fast() marks the object dirty for most cases (vit
set_to_gtt_domain(), but isn't called for all cases (or can return before
the set_d
On Mon, Dec 07, 2015 at 12:51:49PM +, Dave Gordon wrote:
> I think I missed i915_gem_phys_pwrite().
>
> i915_gem_gtt_pwrite_fast() marks the object dirty for most cases (vit
> set_to_gtt_domain(), but isn't called for all cases (or can return before
> the set_domain). Then we try i915_gem_shme
On Mon, Dec 07, 2015 at 12:04:18PM +, Dave Gordon wrote:
> On 07/12/15 08:29, Daniel Vetter wrote:
> >On Fri, Dec 04, 2015 at 05:28:29PM +, Dave Gordon wrote:
> >>On 04/12/15 09:57, Daniel Vetter wrote:
> >>>On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote:
> On 01/12/15 13:0
On 01/12/15 12:42, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, the object should be
marked dirty, to ensure that the modifications are not discarded if the
object is evicted under memory pressure.
This
On 07/12/15 08:29, Daniel Vetter wrote:
On Fri, Dec 04, 2015 at 05:28:29PM +, Dave Gordon wrote:
On 04/12/15 09:57, Daniel Vetter wrote:
On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote:
On 01/12/15 13:04, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordo
On Fri, Dec 04, 2015 at 05:28:29PM +, Dave Gordon wrote:
> On 04/12/15 09:57, Daniel Vetter wrote:
> >On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote:
> >>On 01/12/15 13:04, Chris Wilson wrote:
> >>>On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
> In various places
On 04/12/15 09:57, Daniel Vetter wrote:
On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote:
On 01/12/15 13:04, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and up
On Tue, Dec 01, 2015 at 01:21:07PM +, Dave Gordon wrote:
> On 01/12/15 13:04, Chris Wilson wrote:
> >On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
> >>In various places, one or more pages of a GEM object are mapped into CPU
> >>address space and updated. In each such case, the ob
On 01/12/15 13:04, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, the object should be
marked dirty, to ensure that the modifications are not d
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
> In various places, one or more pages of a GEM object are mapped into CPU
> address space and updated. In each such case, the object should be
> marked dirty, to ensure that the modifications are not discarded if the
> object is evicted
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, the object should be
marked dirty, to ensure that the modifications are not discarded if the
object is evicted under memory pressure.
This is similar to commit
commit 51bc
13 matches
Mail list logo