Chris, I think my assumption was not correct. I took out write_domain check but it is still failing. However, here are couple of observation points. I did some experiments.. One of them is to take out even cache_dirty check from eb_move_to_gpu. With this, all sample tests were passing but as you might expect, tests were running so slow, which explains how much clflush cost. Then, I put cache_dirty check back into eb_move_to_gpu then removed 'if (gpu_write_needs_clflush(obj))' from flush_write_domain when write_domain is I915_GEM_DOMAIN_RENDER @@ -753,6 +766,11 @@ flush_write_domain(struct drm_i915_gem_object *obj, unsigne d int flush_domains) + + case I915_GEM_DOMAIN_RENDER: + if (gpu_write_needs_clflush(obj)) <-- took out this line + obj->cache_dirty = true; + break; to make cache_dirty is set all the time if write_domain is I915_GEM_DOMAIN_RENDER. And I saw some of failing tests were now passing but this doesn't fix all of them. I will try to revert back other changes in your patch as well. Please let me know if there's any other thing you want me to try to find a clue. On Wed, Apr 19, 2017 at 07:26:29PM +0100, Chris Wilson wrote: > On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote: > > Chris, > > > > Just to make sure, you want to just remove write_domain check from > > if statement before clflush in execbuffer_move_to_gpu. Am I right? > > I will try both (cache_dirty only vs cache_dirty & !cache_coherent) > > and get back to you shortly. > > Yes, I just don't have a single bit for cache_coherent yet, so you > might as well let that call i915_gem_object_clflush(). > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
