[Mesa-dev] [PATCH 2/2] i965/miptree: Use the tiling from the modifier instead of the BO

[Kristian Høgsberg]

On Tue, Dec 5, 2017 at 9:43 AM, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> On Tue, Dec 5, 2017 at 8:49 AM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On Tue, Dec 5, 2017 at 8:23 AM, Kristian Høgsberg <hoegsberg at gmail.com>
>> wrote:
>>>
>>> On Tue, Dec 5, 2017 at 7:57 AM, Jason Ekstrand <jason at jlekstrand.net>
>>> wrote:
>>> > On Tue, Dec 5, 2017 at 1:22 AM, Daniel Stone <daniel at fooishbar.org>
>>> > wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> On 18 November 2017 at 00:10, Jason Ekstrand <jason at jlekstrand.net>
>>> >> wrote:
>>> >> > This fixes a bug where we were taking the tiling from the BO
>>> >> > regardless
>>> >> > of what the modifier said.  When we got images in from Vulkan where
>>> >> > it
>>> >> > doesn't set the tiling on the BO, we would treat them as linear even
>>> >> > though the modifier expressly said to treat it as Y-tiled.
>>> >>
>>> >> For some reason I thought Ken had already reviewed this and it landed,
>>> >> until Kristian mentioned last night.
>>> >
>>> >
>>> > There's been some discussion about what the right thing to do is here.
>>> > I've
>>> > got a patch (which is now landed) which will make us set the tiling from
>>> > Vulkan just like GL does.  It's rather annoying but I think that's
>>> > marginally better.
>>>
>>> I don't know that it's better - it reinforces the notion that you have
>>> to make the kernel-side tiling match for the dma-buf import extension
>>> to work. I think it'd be better to land these patches (btw, Rb: me
>>> (can you even do parenthetical Rbs?))
>>
>>
>> I'll allow it. :)
>>
>>>
>>> and call set-tiling in mesa.
>>
>>
>> Yeah, I think that's reasonable.  Really, this should only be a problem if
>> we have a bunch of users trying to use the same BO with different modifiers.
>> It can happen in theory (immagine two images in the same BO, one X and one
>> Y) but it's a pretty crazy case.
>
> It's not a complete solution, of course, but at least we're kicking
> the can down the road of increasingly esoteric use cases.
>
>>>
>>> The
>>> assumption being that if the tiling doesn't match the modifier, then
>>> maybe the producer didn't care about kernel tiling? Alternatively,
>>> could we set bo->tiling = INCONSISTENT or such in mesa and then use
>>> that to avoid the gtt map paths?

Actually, for compressed textures, you already must have a way to deal
with glTexSubImage2D and similar without falling back to GTT maps. Can
you just handle miptrees with mismatched modifiers (or perhaps just
any valid modifier) the same way?

Kristian