Previously we allocated 4kB of push constant space for VS, GS, and PS
(for a total of 12kB) no matter what. This works, but doesn't fully
utilize the space - we have 16kB or 32kB of space.
This makes anv use the same method as brw - divide up the space evenly
among all active shader stages. This means HS and DS would get space,
if those shader stages existed.
In the future, we can probably do better by inspecting how many push
constants each shader stage uses, and weight things accordingly. But
this is strictly better than the old code, and ideally we'd justify
a fancier solution with actual performance data.
Rather than keeping separate {vs,hs,ds,gs}_start fields, we now store an
array indexed by the shader stage (MESA_SHADER_*). The 3DSTATE_URB_*
commands are also sequentially numbered. This makes it easy to just
emit them in a loop.
This simplifies the code a little, and also will make it easier to add
more credible HS and DS code later.
The descriptor sizes array gives the total number of each type of
descriptor that will ever be allocated from the pool, not the total amount
that may be in any particular set. In our case, this simply means that we
have to sum a bunch of things up and there we go.
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>
