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. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
