On Tue, Dec 5, 2017 at 7:57 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Tue, Dec 5, 2017 at 1:22 AM, Daniel Stone <dan...@fooishbar.org> wrote: >> >> Hi, >> >> On 18 November 2017 at 00:10, Jason Ekstrand <ja...@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?)) and call set-tiling in mesa. 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? Kristian > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
