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

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling
Date: Tue, 2 Feb 2016 09:34:11 +0000	[thread overview]
Message-ID: <56B07813.8040002@linux.intel.com> (raw)
In-Reply-To: <20160201175727.GU23290@intel.com>

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.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx