We can't use a global descriptor pool like we were because it's not
thread-safe. For now, we'll allocate them on-the-fly and that should work
fine. At some point in the future, we could do something where we
stack-allocate them or allocate them out of one of the state streams.
Descriptor pools are an optimization that lets applications allocate
descriptor sets through an externally synchronized object (that is,
unlocked). In our case it's also plugging a memory leak, since we
didn't track all allocated sets and failed to free them in
vkResetDescriptorPool() and vkDestroyDescriptorPool().
I've had people ask about the design of the pack functions, for example,
why aren't we using bitfields. I wrote up a bit of background on why and
how we ended up with the current design and we might as well keep that
with the code.
As with anv_CmdCopyBufferToImage, compressed textures require special
handling during copies.
Reviewed-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
This gives us the chance to pack the binding table down to just what the
shaders actually need. Some applications use very large descriptor sets
and only ever use a handful of entries. Compacted binding tables should be
much more efficient in this case. It comes at the down-side of having to
re-emit binding tables every time we switch pipelines, but that's
considered an acceptable cost.
We ignore unused dimensions in the isl surface; do the same for the
resulting anv_image.
Reviewed-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
"Result is the same as computing the sum of the absolute values of
OpDPdx and OpDPdy on P."
We were doing sum of absolute values of OpDPdx of P and OpDPdx of NULL.
We don't need to look at the stage flags, as we don't really support any
fine-grained, stage-level synchronization. We have to do two
PIPE_CONTROLs in case we're both flushing and
invalidating.
Additionally, if we do end up doing two PIPE_CONTROLs, the first,
flusing one also has to stall and wait for the flushing to finish, so we
don't re-dirty the caches with in-flight rendering after the second
PIPE_CONTROL invalidates.
We would assert on unused dimensions (eg extent.depth for
VK_IMAGE_TYPE_2D) not being 1, but the specification doesn't put any
constraints on those. For example, for VK_IMAGE_TYPE_1D:
"If imageType is VK_IMAGE_TYPE_1D, the value of extent.width must be
less than or equal to the value of
VkPhysicalDeviceLimits::maxImageDimension1D, or the value of
VkImageFormatProperties::maxExtent.width (as returned by
vkGetPhysicalDeviceImageFormatProperties with values of format,
type, tiling, usage and flags equal to those in this structure) -
whichever is higher"
We'll fix up the arguments to isl to keep isl strict in what it expects.
We need to make sure GEM understands that we're writing to the BO, in
case it needs to synchronize with other rings (blitter use in display
server, for example).
Jason Ekstrand