Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1515180 > unrolled thread

Re: redraw issues on i915 since 4.9-rc

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: redraw issues on i915 since 4.9-rc Chris Wilson <chris@chris-wilson.co.uk> - 2016-11-04 14:00 +0100
    Re: redraw issues on i915 since 4.9-rc Norbert Preining <preining@logic.at> - 2016-11-04 18:30 +0100
      Re: redraw issues on i915 since 4.9-rc Chris Wilson <chris@chris-wilson.co.uk> - 2016-11-04 18:40 +0100
        Re: redraw issues on i915 since 4.9-rc Norbert Preining <preining@logic.at> - 2016-11-05 05:30 +0100
          Re: redraw issues on i915 since 4.9-rc Chris Wilson <chris@chris-wilson.co.uk> - 2016-11-05 20:10 +0100

#1515180 — Re: redraw issues on i915 since 4.9-rc

On Fri, Nov 04, 2016 at 08:40:47PM +0900, Norbert Preining wrote:
> Dear all,
> 
> since 4.9-rc series started I see heavy redraw problems on i915. Starting
> or resizing for example the digikam window messes up completely the content.
> 
> I have seen this at least since rc2 (I often wait till rc2), and 
> confirm that 4.8.0 does not exhibit these problems.
> 
> A screenshot of the redraw problems is attached.

The fencing looks correct. To me it looks like we filled the vma with
the wrong set of pages from the parent object.

https://cgit.freedesktop.org/drm-intel/ #drm-intel-nightly contains one
interesting patch wrt to the partial vma->pages
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued&id=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you mind testing -nightly to see if I'm barking up the wrong tree?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[toc] | [next] | [standalone]

#1515328

Hi Chris,

> https://cgit.freedesktop.org/drm-intel/

I pulled from there and rebuild my kernel. Rebooting and everything
is fine. Looks much better!!!

> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued&id=d2a84a76a3b970fa32e6eda3d85e7782f831379e

Do you want me to test this patch only on top of master? (If it applies!!!)

All the best

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13    fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

[toc] | [prev] | [next] | [standalone]

#1515329

On Sat, Nov 05, 2016 at 02:25:19AM +0900, Norbert Preining wrote:
> Hi Chris,
> 
> > https://cgit.freedesktop.org/drm-intel/
> 
> I pulled from there and rebuild my kernel. Rebooting and everything
> is fine. Looks much better!!!
> 
> > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued&id=d2a84a76a3b970fa32e6eda3d85e7782f831379e
> 
> Do you want me to test this patch only on top of master? (If it applies!!!)

It won't apply directly, but you could try testing that commit and its
parent to see if my hunch was correct.

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[toc] | [prev] | [next] | [standalone]

#1515501

> It won't apply directly, but you could try testing that commit and its
> parent to see if my hunch was correct.

Unfortunately parent commit was also ok. I am trying to bisect, but
somehow git tells me something about "...merge commit..." - will see
how it goes.

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13    fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

[toc] | [prev] | [next] | [standalone]

#1515609

On Sat, Nov 05, 2016 at 01:27:30PM +0900, Norbert Preining wrote:
> > It won't apply directly, but you could try testing that commit and its
> > parent to see if my hunch was correct.
> 
> Unfortunately parent commit was also ok. I am trying to bisect, but
> somehow git tells me something about "...merge commit..." - will see
> how it goes.

Git should be fairly sensible and stick to the drm side of the merges
(just remember that the kernel version will jump around a lot, an issue
if your grub isn't setup to boot the last installed kernel as opposed to
the highest version). Since my guess was wrong, any clues you can find
to point me in the direction will be very useful.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web