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).
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
