[Intel-gfx] [PATCH 0/3] drm/i915: Fix SKL+ 90/270 degree rotated scanout
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Tue Jun 6 08:29:06 UTC 2017
On 06/06/2017 09:06, Maarten Lankhorst wrote:
> Op 05-04-17 om 15:49 schreef Ville Syrjälä:
>> On Fri, Mar 31, 2017 at 10:23:18PM +0100, Chris Wilson wrote:
>>> On Fri, Mar 31, 2017 at 09:00:53PM +0300, ville.syrjala at linux.intel.com wrote:
>>>> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>>>>
>>>> I figured it's about time I fix what I broke with my fb offset stuff.
>>>> I've posted the scaler thing before, but the watermark and fbc stuff
>>>> is new.
>>>>
>>>> Based on some quick tests the WM fixes seem effective. Or at least
>>>> underruns seemed to disappear when I was running xonotic with 90/270
>>>> degree rotation.
>>> The key question for me is would we be able to detect any of the errors
>>> in igt? How can we improve our testing?
>> The rotation test definitely would need some love. It fails to detect
>> these problems because it scans out a square image. Making it non-square
>> would at least catch the use of the scaler when it shouldn't be used.
>>
>> Detecting the watermark breakage is less clear. I suppose making the
>> plane have a very wide or very tall aspect ratio might help induce
>> underruns with the broken wm code.
>>
>> Another thing that may or may not be missing from the test is panning.
>> I'd also like to test scaling, but sadly our hardware makes that
>> rather hard by not allowing us to force nearest and/or linear filtering,
>> and bspec doesn't actually document what kind of algorithm the hardware
>> uses for the different filter modes.
>>
> Agreed, the whole series is useful but until we have some tests we may as well not commit it. Nothing prevents it from being broken again in the next commit. :(
In case tests hit a stumbling blocks/delays, I would appreciate if this
got reviewed and merged soonish. As it stands I've been applying (and
occasionally forgetting to apply) patches locally since September.
And FWIW I would report if it got re-broken, since I'm using monitors in
portrait, and like to run recent drm-tip to help catch issues missed
elsewhere.
> I'll take a look and see if I can make kms_rotation_crc break without this test.
Would also need to upgrade the test to basic, or count on extended runs
getting attention soon?
Regards,
Tvrtko
More information about the Intel-gfx
mailing list