[igt-dev] [PATCH v2 3/8] tests/kms_available_modes_crc: Don't set tiling for framebuffer

[Dixit, Ashutosh]

On Tue, 11 Feb 2020 12:42:02 -0800, Imre Deak wrote:
> On Tue, Feb 11, 2020 at 12:15:57PM -0800, Dixit, Ashutosh wrote:
> > On Mon, 10 Feb 2020 18:31:03 -0800, Imre Deak wrote:
> > I think there are still the following remaining issues with this patch:
> >
> > 1. 33cc93c8 has introduced a gem_require_mappable_ggtt() skipping the
> >    entire test. That should probably be removed as part of this patch?
> >
> > 2. do_write() has a gem_mmap__gtt() which should be converted to
> >    device_coherent()?
>
> That's a good point, we'll need to use another way to write the test
> image to the FB and stop skipping the test. However I think this patch
> is still valid on its own, and the above things can be done as a
> follow-up.

OK, you have a R-b on the patch anyway.

> > 3. This is sort of optional but in my view there is an inconsistency here
> >    which should be addressed:
> >
> >    The original test was actually using a tiled object and using the tiling
> >    available in the aperture/gtt to write to the object. Through this patch
> >    we have essentially removed the tiling on the object. However, we are
> >    continuing to use LOCAL_I915_FORMAT_MOD_X_TILED in setup_fb(). It just
> >    happens that because we are filling in a single value the modifier is
> >    immaterial.
>
> It's not immaterial, the display will scan out an X tiled FB.

I am aware of it, what I meant was only because it is a solid color, if we
write assuming it is untiled whereas the scan out will assume tiled, the
output on the display will still look right.

> >    Shouldn't this be made consistent? Either
> >
> >    (a) we should change the modifier to LOCAL_DRM_FORMAT_MOD_NONE, or
> >
> >    (b) if we are going to use the tiled modifer we should assume the object
> >        is really tiled and use the blitter or rendercopy to write to the
> >        object.
>
> The test just solid fills the FB and we don't need to do that in a pixel
> line-by-line order.
>
> >    I guess (a) is simpler to do.