On 14 February 2018 at 16:27, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Wed, Feb 14, 2018 at 3:39 AM, Daniel Stone <dan...@fooishbar.org> wrote: >> > On Tue, Feb 13, 2018 at 10:48 AM, Daniel Stone <dan...@fooishbar.org> >> > wrote: >> >> For actual scanout, the kernel very specifically demands that if the >> >> BO is X-tiled, then set_tiling be called with TILING_X. This applies >> >> even if we explicitly allocate with MOD_X_TILED and pass that in via >> >> drmModeAddFB2WithModifiers: there is an explicit check for >> >> !!(bo_tiling == TILING_X) == !!(modifier == MOD_X_TILED). >> >> You missed this bit. Suggested fixup: https://hastebin.com/xikopobiza > > I was really hoping I'd read wrong. I'm going with "that's a kernel bug". > Modifiers is supposed to separate tiling from the BO. Tying them back > together in drmModeAddFB2WithModifiers is wrong. This is especially true > since SET_TILING is an inherently racy operation and we really need to stop > using it entirely. > > If what you wrote above really is immutably true, then this patch is dead.
It is immutably true, but I think this patch (with ugly fixup) still makes sense. Linear is unchanged as it's implicit. X tiling has to take the workaround, in case anyone wants to display it. Y tiling can skip it though, and future Yf/etc tiling modes don't need to either extend the I915_TILING_* enum (eww), or be explicitly set to linear when they're not. I think there's value in having the code clarify, rather than it doing set_tiling everywhere, so people assuming it's still required. I can kind of see why that ABI makes sense though. Having userspace explicitly call set_tiling(X) had the kernel magically imply that the FB created from that BO should be X-tiled. Given that ABI still unfortunately exists, enforcing coherency between old and new ways to declare an FB should be tiled, doesn't seem unreasonable. > What's the failure mode here? We just don't flip? Or the compositor wigs > out and crashes? AddFB never succeeds, so we can never flip. Cheers, Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
