On 14 February 2018 at 17:23, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Wed, Feb 14, 2018 at 8:43 AM, Daniel Stone <dan...@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 ...
mesa-dev mailing list