[Intel-gfx] [PATCH v3 3/6] drm/i915: Amalgamate flushing of display objects
Yaroslav Shabalin
yaroslav.shabalin at gmail.com
Thu Sep 14 10:48:43 UTC 2017
Dear Chris,
As you are the author of original patch, could you please take a look at my
report below.
On Wed, Sep 13, 2017 at 1:11 AM, Yaroslav Shabalin <
yaroslav.shabalin at gmail.com> wrote:
> 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/20170914/a5c9566c/attachment.html>
More information about the Intel-gfx
mailing list