The previous way we were attempting to handle AUX tables on TGL-LP was
very GL-like. We used the same aux table management code that's shared
with iris and we updated the table on image create/destroy. The problem
with this is that Vulkan allows multiple
VkImage objects to be bound to
the same memory location simultaneously and the app can ping-pong back
and forth between them in the same command buffer. Because the AUX
table contains format-specific data, we cannot support this ping-pong
behaviour with only CPU updates of the AUX table.
There are a few different ways of handling this. The ideal way would be if we had sparse binding support in the kernel. Then we would just make all compressed images sparse-bound and each
VkImage would have its own VA range. In this scenario, since the AUX table is a VA -> VA mapping, each
VkImage would have its own AUX table entries and we would have no format conflict issues. Unfortunately, we don't have sparse binding support in the kernel yet so we have to go about thins in a more round-about fassion.
The new mechanism proposed in this MR switches things around a bit and instead makes the aux data part of the BO. At BO creation time, a bit of space is appended to the end of the BO for AUX data and the AUX table is updated in bulk for the entire BO. The problem here, of course, is that we can't insert the format-specific data into the AUX table at BO create time.
Fortunately, Vulkan has a requirement that every
must be initialized prior to use by transitioning the image from
VK_IMAGE_LAYOUT_UNDEFINED to something else. When doing the above
described ping-pong behavior, the app has to do such an initialization
transition every time it corrupts the underlying memory of the
by using it as something else. We can hook into this initialization and
use it to update the AUX-TT entries from the command streamer. This way
the AUX table gets its format information, apps get aliasing support,
and everyone is happy.