[Mesa-dev] [PATCH 2/2] i965/miptree: Use the tiling from the modifier instead of the BO
hoegsberg at gmail.com
Tue Dec 5 17:43:58 UTC 2017
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>
>> On Tue, Dec 5, 2017 at 7:57 AM, Jason Ekstrand <jason at jlekstrand.net>
>> > 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.
>> 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?
More information about the mesa-dev