dynamic state required because pipeline hashing for this would be too pita

this should work the same way as argb/abgr

the base formats are supported, so these should fall into place naturally

tc needs the total host memory available, not the total video memory

currently this supports 3 modes, with the default being a hybrid between
caching and lazy

this doesn't actually do anything other than test the codepath since
the hashed pipeline state will still change on every frontface change,
but it's a start

this is pretty straightforward, just adding some extra calls

technically shouldn't matter but whatever

I'm told this is bad for perf

the first step to adding modular descriptor managers is to isolate the existing one
so that it can be easily swapped out

this lets us inline away our problems

moves some of the always-run passes into the base nir

vulkan doesn't support these natively, but we can do it with swizzles
using the new pipe cap

avoids memcpy slowpath

no point in updating blend state for this when we aren't using it

ANV and RADV are known to be good citizens with regard to shader image coherency,
so drop the mem model requirements/mechanics for them too

vk mem model is required for coherency with shader images, but cpu drivers
have coherent memory, so this is not actually an issue

just basic parts, no waiting on semaphores yet

Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <mesa/mesa!9963>

this includes:
* async buffer mapping/replacement
* async queue submission
* async (threaded) gallium flush handling

the main churn here is from handling async gallium flushes, which involves
creating multiple gallium fences (zink_tc_fence) for each zink fence (zink_fence).
a tc fence may begin waiting for completion at any time, even before the zink_fence
has had its cmdbuf(s) submitted, so handling this type of desync ends up needing
almost a complete rewrite of the existing queue architecture

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <mesa/mesa!9935>

This one is a bit of a tough nut to deal with gracefully. Zink has a set
of base-requirements that we always require. There's no Gallium caps to
report these missing features, so we're essentially left with two options:

1. Fail to create the screen.
2. Ignore the missing fetures.

Solution 1 will lead to difficulties bringing up a new Vulkan driver on
Zink, and solution 2 will lead to mis-rendering.

Since Zink is mostly an opt-in driver to use when there's no OpenGL driver
available, we should probably do 2 for now. It seems better to have some
mis-rendering than no rendering at all.

But let's at least check, and print a warning. That way people get to
know what's up.

Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <mesa/mesa!9925>

ensure this gets populated before using it

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <mesa/mesa!9885>

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <mesa/mesa!9788>

This cap depends on a device extension.

Fixes: b59d98ae

 ("zink: enable PIPE_CAP_TEXTURE_MIRROR_CLAMP_TO_EDGE")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <mesa/mesa!9803>

These limits depens on feature-bits.

Fixes: 322a3d4f

 ("zink: partially enable SSBO pipe cap")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <mesa/mesa!9803>

This cap depends on a feature-bit.

Fixes: 3d7d55c2

 ("zink: enable PIPE_CAP_POLYGON_OFFSET_CLAMP")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <mesa/mesa!9803>