[Mesa-dev] [RFC 00/22] DRI3 v1.1, ANV dmabuf

[Daniel Stone]

Hi,

On 14 June 2017 at 07:45, Chad Versace <chad at kiwitree.net> wrote:
> On Thu 08 Jun 2017, Jason Ekstrand wrote:
>> I'm just getting started looking at these.  The first thing to say is that
>> I'm pretty sure I made a bunch of comments the first time they were sent
>> out and I don't see anything different.  It's been a while though.
>
> I found some small differences in the first few patches. I haven't
> progressed past patch 13 yet, though.
>
> Jason, patches 5 through 12 are general cleanups in preparation for
> vk-dma-buf support. Those cleanups, in my opinion, can and should land
> before the actual vk-dma-buf patches, and could land now (after review
> and testing). What do you think? I don't expect those patches to change,
> even as the rest of the patch series evolves.

Thanks all for looking into these. I generally agree that 5-12 are
good, and after applying the whole series I do quite like the
image-creation flow, and find it much more easy to follow.

To sum up what we discussed on IRC, rather than it being lost in the
mists of time ...

I don't think the current modifier -> isl_tiling is adequate. The
Y_CCS modifier implies both Y-tiling and a CCS aux surface: converting
to an isl_tiling bitmask loses CCS. Nor can we just have an aux_usage
bitmask paired with the tiling bitmask: if upstream tells us that we
can use Y, Yf or Y_CCS, then a (Y0 | Yf) + (AUX_NONE | AUX_CCS) pair
could lead us to use Yf_CCS where we support it but the consumer
doesn't. So we need something which gives us (tiling,aux_usage) pairs.
The obvious one which jumps out at me is an isl_tiling bitmask as
before, paired with an array of aux_usage bitmasks, one bitmask per
tiling mode.

Conversely, (isl_tiling + aux_usage) -> modifier also needs more
information. We can allocate an auxiliary surface (e.g. CCS) for
internal usage, but fully resolve (ambiguate?) it such that it is not
used externally. So it seems like we need an additional flag for how
the auxiliary surface is represented to the external/winsys user, so
we can decide if (Y + CCS) is really Y_CCS for the external consumer,
or just plain Y.

Cheers,
Daniel