[Mesa-dev] [PATCH 2/2] i965/miptree: Use the tiling from the modifier instead of the BO
jason at jlekstrand.net
Tue Dec 5 16:49:14 UTC 2017
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>
> >> Hi,
> >> On 18 November 2017 at 00:10, Jason Ekstrand <jason at jlekstrand.net>
> >> > This fixes a bug where we were taking the tiling from the BO
> >> > 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.
> > 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.
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev