In struct anv_saved_state, each member's type was a pointer to an Anvil
struct and each member's name was prefixed with "old" except cb_state,
which was a Vulkan handle whose name lacked "old".
The source image's format was incorrectly used for both the source view
and destination view. For vkCmdCopyImage to correctly translate formats,
the destination view's format must be that of the destination image's.
Change type of anv_render_pass_attachment::format from VkFormat to const
struct anv_format*. This elimiates the repetitive lookups into the
VkFormat -> anv_format table when looping over attachments during
anv_cmd_buffer_clear_attachments().
Stop creating a temporary VkImageCreateInfo with overriden
format=VK_FORMAT_S8_UINT. Instead, just pass the format override
directly to anv_image_make_surface().
Stencil formats are often a special case. To reduce the number of lookups
into the VkFormat-to-anv_format translation table when working with
stencil, expose the table's entry for VK_FORMAT_S8_UINT as global
variable anv_format_s8_uint.
Change type of anv_surface_view::format from VkFormat to const struct
anv_format*. This reduces the number of lookups in the VkFormat ->
anv_format table.
This moves the translation of VkFormat to anv_format from
anv_fill_buffer_surface_state() to its caller.
A prep commit to reduce more VkFormat -> anv_format translations.
Store the original VkFormat as anv_format::vk_format. This will be used
to reduce format indirection, such as lookups into the VkFormat ->
anv_format translation table.
We need to make sure we use the VkImage infrastructure for creating
dmabuf images.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
We already query the device in various ways here and we can just also
get the aperture size. This avoids keeping an extra drm fd open
during the life time of the driver.
Also, we need to use explicit 64 bit types for the aperture size, not
size_t.
This lets us hit an assert if we exceed the block pool size instead of
GPU hanging.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
The anv_block_pool data structure suffered from the exact same race as the
state pool. Namely, that the uniqueness of the blocks handed out depends
on the next_block value increasing monotonically. However, this invariant
did not hold thanks to our block "return" concept.
The previous algorithm had a race because of the way we were using
__sync_fetch_and_add for everything. In particular, the concept of
"returning" over-allocated states in the "next > end" case was completely
bogus. If too many threads were hitting the state pool at the same time,
it was possible to have the following sequence:
A: Get an offset (next == end)
B: Get an offset (next > end)
A: Resize the pool (now next < end by a lot)
C: Get an offset (next < end)
B: Return the over-allocated offset
D: Get an offset
in which case D will get the same offset as C. The solution to this race
is to get rid of the concept of "returning" over-allocated states.
Instead, the thread that gets a new block simply sets the next and end
offsets directly and threads that over-allocate don't return anything and
just futex-wait. Since you can only ever hit the over-allocate case if
someone else hit the "next == end" case and hasn't resized yet, you're
guaranteed that the end value will get updated and the futex won't block
forever.
We have pools, so we should be using them. Also, I think this will help
keep valgrind from getting confused when we have to end up fighting with
system allocations such as those from malloc/free and mmap/munmap.
Figuring out whether or not to do a copy requires knowing the length of the
final batch_bo. This gets set by anv_batch_bo_finish so we have to do it
afterwards. Not sure how this was even working before.
Previously, the command buffer implementation was split between
anv_cmd_buffer.c and anv_cmd_emit.c. However, this naming convention was
confusing because none of the Vulkan entrypoints for anv_cmd_buffer were
actually in anv_cmd_buffer.c. This changes it so that anv_cmd_buffer.c is
what you think it is and the internals are in anv_batch_chain.c.
