[Intel-gfx] [PATCH v3 3/6] drm/i915: Amalgamate flushing of display objects

Yaroslav Shabalin yaroslav.shabalin at gmail.com
Tue Sep 12 22:11:03 UTC 2017


Hi!

I would like to report a problem which I believe is connected to changes
introduced in this patch (
https://lists.freedesktop.org/archives/intel-gfx/2017-February/120777.html).
Specifically the problem is: screen freezes for 0.5 - 5 seconds (mostly for
2-3 seconds) when PSR is enabled (i915.enable_psr=1 kernel boot option).
Freezes are more frequent with rich, dynamic screen content. The most
reliable way to reproduce it, I discovered so far, is to start Gnome "Disk
Usage Analyzer", analyze some catalog and move mouse pointer over color
rectangles for a while. Usually that way I get 3-5 freezes in a minute.
During normal PC usage freezes are happening less frequently, but still
annoyingly. For the first time this problem appeared after update to kernel
4.12 and still there in recent 4.13 too.
I've looked into it a little and seems that mentioned patch is the one that
brought it in. Git bisect indicates it as the first bad commit. After
realizing that I tried to partly revert changes in the patch and found that
following change:

 	/* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
-	if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
-		i915_gem_clflush_object(obj, true);
-		intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
-	}
+	__i915_gem_object_flush_to_display(obj);
+	intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);

when reverted solves the problem completely. One of the main
difference is that in old version intel_fb_obj_flush was called
conditionally and now it is called every time. So I surrounded the
call with "if" just to check and it worked:

/* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
-	if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
-		i915_gem_clflush_object(obj, true);
-		intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
-	}
+	__i915_gem_object_flush_to_display(obj);
+	if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
+	  intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
+ }

 The above code was just a guess based on some logical insight.
Although it eliminates the freezes, I don't really know if the change
in calling intel_fb_obj_flush wasn't made intentionally. So could you
please look at that case?

If you need any help in reproducing problem conditions or further
diagnostic information, please let me know.


Thank you in advance,

Yaroslav Shabalin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170913/5a6f75ad/attachment.html>


More information about the Intel-gfx mailing list