On 18/04/16 12:37, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 12:28:43PM +0100, Dave Gordon wrote:
On 18/04/16 11:25, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are a
On Mon, Apr 18, 2016 at 12:28:43PM +0100, Dave Gordon wrote:
> On 18/04/16 11:25, Chris Wilson wrote:
> >On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote:
> >>With the new i915_gem_obj_pin_map() interface, it makes sense to keep
> >>GuC objects (which are always pinned in memory and in t
On 18/04/16 11:25, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are always pinned in memory and in the GGTT anyway)
mapped into kernel address space, rather than mapping a
On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote:
> With the new i915_gem_obj_pin_map() interface, it makes sense to keep
> GuC objects (which are always pinned in memory and in the GGTT anyway)
> mapped into kernel address space, rather than mapping and unmapping them
> on each access.
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are always pinned in memory and in the GGTT anyway)
mapped into kernel address space, rather than mapping and unmapping them
on each access.
This preliminary patch sets up the pin-and-map for all GuC-specific