Convert the table from the direct mapping
VkImageViewType -> SurfaceType
into a mapping to an info struct
VkImageViewType -> struct anv_image_view_info
We should be asserting that the parent decoration didn't hand us
a member if the child decoration did, but different child decorations
may obviously have different members.
Since SSA values now have their own types, it's more convenient to make
'type' only used when we want to look up an actual SPIR-V type, since
we're going to change its type soon to support various decorations that
are handled at the SPIR-V -> NIR level.
Previously, the caller of vtn_handle_type had to handle actually inserting
the type. However, this didn't really work if the type was decorated in
any way.
The way the code currently works is that anv_format::cpp is the cpp of
anv_format::surface_format.
Me and Kristian disagree about how the code *should* work. Despite that,
I think it's in our discussion's best interest to document how the code
*currently* works. That should eliminate confusion.
If and when the code begins to work differently, then we'll update the
anv_format comments.
This prepares for upcoming miptree support.
anv_surface is a proxy for color surfaces, depth surfaces, and stencil
surfaces. Embed two instances of anv_surface into anv_image: the
primary surface (color or depth), and an optional stencil surface.
All function signatures that matched this pattern,
old: f(const VkImageCreateInfo *, const struct anv_image_create_info *)
were rewritten as
new: f(const struct anv_image_create_info *)
The format table defined cpp = 0 for stencil-only formats. The real cpp
is 1.
When code begins to lie, especially about stencil buffers, code becomes
increasingly fragile as time progresses, and the damage becomes
increasingly hard to undo. (For precedent, see the painful history of
stencil buffer cpp in the git log for gen6 and gen7 in the i965 driver).
Let's undo the stencil buffer cpp lie now to avoid future pain.
In the format table, set cpp = 1 for VK_FORMAT_S8; replace checks for
cpp == 0; and delete all comments about the hack.
From my experience with intel_mipmap_tree.c, I learned that for struct's
like anv_image and intel_mipmap_tree, which have sprawling
multi-function construction codepaths, it's easy to mistakenly use
unitialized struct members during construction.
Let's eliminate the risk of using unitialized anv_image members during
construction. Fill the struct at the function bottom instead of
piecemeal throughout the constructor.
