[Mesa-dev] [PATCH 12/16] anv/image: Separate modifiers from legacy scanout

[Daniel Stone]

On 14 February 2018 at 17:23, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Wed, Feb 14, 2018 at 8:43 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> Linear is unchanged as it's implicit. X tiling has to take the
>> workaround, in case anyone wants to display it.
>
> I'm not sure I buy that.  From a userspace perspective, you shouldn't be
> using modifiers unless everything supports them.  Why?  Because no userspace
> that isn't an Intel driver should look at I915_FORMAT_MOD_X_TILED and say "I
> can hand that off without modifiers just fine".

Take a sprite plane which only advertises LINEAR + X_TILED at the
moment (watermark allocation bugs seem to prevent Y_TILED). Hand that
set of two modifiers to Vulkan for allocation, render into the
resulting image. Call AddFB on it with I915_FORMAT_MOD_X_TILED. That
will get rejected because set_tiling hasn't been called, even though
you _have_ been explicit with modifiers everywhere.

>> 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.
>
> Eh.  The whole point of modifiers is as an alternate mechanism.  Insisting
> that they "match" is, to me, equivalent to insisting that you use both which
> is silly.  Of course, anyone is free to argue in the opposite direction.

*shrug*. Looked at another way, it's just about having your implicit
and explicit mechanisms match exactly. Given the implicit mechanism
will stay around forever, keeping them consistent makes sure that
no-one slip up. Either way, we're stuck with it forever, and if we
ever want to display X_TILED then we need it, so ...

Cheers,
Daniel