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
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
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
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
