On Tue, Dec 5, 2017 at 8:23 AM, Kristian Høgsberg <hoegsb...@gmail.com> wrote:
> 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?)) 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. > 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? >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
