On Sat, Aug 09, 2014 at 12:29:17PM -0700, Ben Widawsky wrote:
On Sat, Aug 09, 2014 at 05:37:23PM +0100, Chris Wilson wrote:
With ppgtt, it is no longer correct to mark an object as
map_and_fenceable if we simply unbind it from the global gtt. This has
consequences during execbuffer where we
On Sun, Aug 10, 2014 at 07:55:46AM +0100, Chris Wilson wrote:
On Sat, Aug 09, 2014 at 12:29:17PM -0700, Ben Widawsky wrote:
I didn't read the patch closely, but the problem is clear. It seems like
the one hunk:
- if (use_cpu_reloc(obj))
+ if (use_cpu_reloc(obj) ||
With ppgtt, it is no longer correct to mark an object as
map_and_fenceable if we simply unbind it from the global gtt. This has
consequences during execbuffer where we simply use
obj-map_and_fenceable in use_cpu_reloc() to decide which access method
to use for writing into the object. Now for a
On Sat, Aug 09, 2014 at 05:37:23PM +0100, Chris Wilson wrote:
With ppgtt, it is no longer correct to mark an object as
map_and_fenceable if we simply unbind it from the global gtt. This has
consequences during execbuffer where we simply use
obj-map_and_fenceable in use_cpu_reloc() to decide
With ppgtt, it is no longer correct to mark an object as
map_and_fenceable if we simply unbind it from the global gtt. This has
consequences during execbuffer where we simply use
obj-map_and_fenceable in use_cpu_reloc() to decide which access method
to use for writing into the object. Now for a
