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.
This reverts commits
e17ed04 * vk/image: Don't double-allocate stencil buffers
1ee2d1c * vk/image: Teach anv_image_choose_tile_mode about WMAJOR
and instead adds a comment to describe the subtlety of how we create
images for stencil only formats.
- Reduce the number of table lookups in anv_image_create from 4 to 1.
- Add field for surface alignment.
- Shorten field names tile_width, tile_height -> width, height.
This also drops the share create_surface_state helper and moves filling
out SURFACE_STATE directly into anv_image_view_init() and
anv_color_attachment_view_init().
The *_init functions work basically the same as the Vulkan entrypoints
except that they act on an already-created view and take an optional
command buffer option. If a command buffer is given, the surface state is
allocated out of the command buffer's state stream.
We don't need to point back to the memory object the bo came from.
Pointing directly to a bo lets us bind images and buffers to other
bos - like our allocator bos.
