[Intel-gfx] [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling

[Daniel Vetter]

On Tue, Feb 02, 2016 at 09:34:11AM +0000, Tvrtko Ursulin wrote:
> 
> On 01/02/16 17:57, Ville Syrjälä wrote:
> >On Mon, Feb 01, 2016 at 05:44:42PM +0000, Tvrtko Ursulin wrote:
> >>
> >>On 01/02/16 17:16, Zanoni, Paulo R wrote:
> >>>Em Sex, 2016-01-29 às 21:06 +0200, Ville Syrjälä escreveu:
> >>>>On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote:
> >>>>>The interesting thing is that if we don't do this, we still get a
> >>>>>Y tiled framebuffer, but there won't be a fence around it, which
> >>>>>makes
> >>>>>the GTT mmaps less interesting. Is this a Kernel bug?
> >>>>
> >>>>I think some tests currently depend on not having a fence for Y tiled
> >>>>fbs. So this could break stuff.
> >>>
> >>>Do you have any additional information that could help me discover
> >>>which ones? A quick look on the IGT tests mentioning tiling didn't
> >>>point anything obvious.
> >>>
> >>>Besides, I think it's probably not a good idea to have such a high
> >>>level helper function behaving differently depending on the tiling
> >>>type, I'd vote to either call set_tiling on both or on none.
> >>
> >>Noticed the thread by accident. :)
> >>
> >>I can't help with the question of which tests might be affected by this.
> >>Some low level ones like kms_addfb don't use the fb helpers so they
> >>shouldn't be. Can't remember if any other would be.
> >>
> >>But just a little bit of background:
> >>
> >>Basically with the introduction of Y tiled (and Yf) scanout in Gen9 we
> >>have forked the path and destroyed the coupling between obj->tiling and
> >>framebuffer tiling.
> >>
> >>The X special casing in create_bo_for_fb is for compatibility with old
> >>userspace, but going forward it was decided fb  modifiers should be used
> >>to tell the driver about tiling and get/set_tiling ioctl is about
> >>fencing and only that.
> >>
> >>Paths implemented in IGT back then were rendering to Y and Yf tiling fbs
> >>via a temporary linear surface which is then blitted (blit?) to the real
> >>fb obj. (With the blitter doing the appropriate transformation.)
> >>
> >>So in that respect adding Y tiling to create_bo_for_fb would be wrong
> >>because it is not aligned with the above, and also you cannot support Yf
> >>this way at all.
> >>
> >>But I do agree this creates a problem for some use cases within the IGT
> >>since the fb and backing obj are created atomically and once that is
> >>done you cannot fiddle with obj->tiling (aka fencing).
> >
> >I suppose we could either make it easier to create the obj and fb
> >separately, or we could add a parameter to the fb funcs to indicate
> >whether we want a fence or not.
> 
> Either way sounds good to me. Will depend on whatever fits better with what
> Paulo is working on at the moment.

I'm ok with not tiling by default for anything but X-tiled in the igt_fb
code. Users can just call set_tiling on the underlying bo if they want it,
but in the shiny new world of Yf/Ys we should by default not use gtt mmaps
really for anything. See also some of the changes planned and then
cancelled/delayed for future products, where the gtt might go poof
entirely.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch