Re: [Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

On Tue, Jun 28, 2016 at 04:44:42PM +0200, Maarten Lankhorst wrote: > Op 28-06-16 om 10:35 schreef Chris Wilson: > > On Tue, Jun 28, 2016 at 09:56:47AM +0200, Maarten Lankhorst wrote: > >> Op 24-06-16 om 14:44 schreef Chris Wilson: > >>> This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f.

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

Op 28-06-16 om 10:35 schreef Chris Wilson: > On Tue, Jun 28, 2016 at 09:56:47AM +0200, Maarten Lankhorst wrote: >> Op 24-06-16 om 14:44 schreef Chris Wilson: >>> This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. >>> >>> Something appears to be off in the timing, but as far as I can

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

Hi Chris, On 24 June 2016 at 22:44, Chris Wilson wrote: > This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. > > Something appears to be off in the timing, but as far as I can tell it > is not along the event delivery path. The net effect appears to be >

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

On Tue, Jun 28, 2016 at 09:56:47AM +0200, Maarten Lankhorst wrote: > Op 24-06-16 om 14:44 schreef Chris Wilson: > > This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. > > > > Something appears to be off in the timing, but as far as I can tell it > > is not along the event delivery path.

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

Op 24-06-16 om 14:44 schreef Chris Wilson: > This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. > > Something appears to be off in the timing, but as far as I can tell it > is not along the event delivery path. The net effect appears to be > rendering flicker (the current render buffer

[Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. Something appears to be off in the timing, but as far as I can tell it is not along the event delivery path. The net effect appears to be rendering flicker (the current render buffer appears on the scanout, with what appears to be