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
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.
mesa-dev mailing list