This was missing and was causing the driver to not work with
execlists. Presumably we get a different initial hw context with
execlists enabled, that has sample mask 0 initially.
Set this to 0xffff for now. When we add MS support, we need to take the
value from VkPipelineMsStateCreateInfo::sampleMask.
The new headers use stdbool for enable/disable fields which
implicitly converts expressions like (flags & 8) to 0 or 1.
Also handles MBO (must-be-one) fields by setting them to one,
corrects a bspec typo (_3DPRIM_LISTSTRIP_ADJ -> LINESTRIP) and
makes a few enum values less clashy.
Convert the table from the direct mapping
VkImageViewType -> SurfaceType
into a mapping to an info struct
VkImageViewType -> struct anv_image_view_info
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.
anv_format::surface_format was incorrect for Vulkan depth formats.
For example, the format table mapped
VK_FORMAT_D24_UNORM -> .surface_format = D24_UNORM_X8_UINT
VK_FORMAT_D32_FLOAT -> .surface_format = D32_FLOAT
but should have mapped
VK_FORMAT_D24_UNORM -> .surface_format = R24_UNORM_X8_TYPELESS
VK_FORMAT_D32_FLOAT -> .surface_format = R32_FLOAT
The Crucible test func.depthstencil.basic passed despite the bug, but
only because it did not attempt to texture from the depth surface.
The core problem is that RENDER_SURFACE_STATE.SurfaceFormat and
3DSTATE_DEPTH_BUFFER.SurfaceFormat are distinct types. Considering them
as enum spaces, the two enum spaces have incompatible collisions.
Fix this by adding a new field 'depth_format' to struct anv_format.
Refer to brw_surface_formats.c:translate_tex_format() for precedent.
I misinterpreted anv_format::format as a VkFormat. Instead, it is
a hardware surface format (RENDER_SURFACE_STATE.SurfaceFormat). Rename
the field to 'surface_format' to make it unambiguous.
