zink: handle more draw modes Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6269>
zink: change pipeline hashes to index based on vk primitive type this is a bit more convenient since we always support vk types but not necessarily gallium types Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6269>
zink: pre-hash gfx-pipeline-state Store a hash in `zink_gfx_pipeline_state` to keep track of state changes and avoid to recompute it when the state has not changed. Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com> Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6061>
zink: rename zink_gfx_program::stages to 'modules' we've been confusing 'stages' and 'shaders' over and over for a long time, so maybe having a totally different name will help here Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5970>
zink: always compile shaders in pipeline order in order to accurately perform slot/location mapping that's consistent across stages, we need to go through the stages in order so that we can pass each successive slot map allocation along to the next compiled stage Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5970>
zink: start using per-stage flags for new shaders, refcount shader modules we don't want to recompile shaders if we don't have to, so we can set bitflags upon receiving new shader states and then compile only the stages that have changed while refcounting the unchanged stages Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5970>
zink: use ZINK_SHADER_COUNT instead of PIPE_SHADER_TYPES - 1 everywhere this is just for convenience and consistency Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5970>
zink: split up creating zink_shader objects and VkShaderModule objects the actual VkShaderModule is only needed when we're creating a program to draw with, so this can be split off for "uncompiled" and "compiled" shader objects which will facilitate implementing shader keys Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5970>
zink: refcount zink_gfx_program objects now that we're tracking these by shader, we want to ensure that they live through each render pass successfully if there's no flush regardless of the timing when the shader objects are destroyed. this becomes useful when we split up shader create and compile functionality in future patches, at which point program refcounts can be changed during successive draw calls, potentially resulting in a program being destroyed at that point when it shouldn't be with this patch, each shader used by the program gets a reference, with the renderpass batch itself becoming the owner of the program such that it will be deleted when the draw state gets invalidated and a new program is created Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5970>
zink: move shader state methods for pipe_context into zink_program.c just moving these so all the shader code can be in one place Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5970>
zink: free pipeline cache during program destroy more leaks Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com> Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5887>
zink: destroy gfx program when a shader is freed there's no sense in having these objects sitting around when they can never be used again requires adding a zink_context* pointer to each program in order to prune the hash table entry Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com> Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5887>
zink: track program usages for each shader when shaders are created and destroyed in large numbers, the same pointers get reused for different shaders, which can lead to bad lookups in the program_cache hash table. now each shader tracks its program usage to automatically remove itself from that program in order to avoid hash collisions fixes mesa/mesa#3053 Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5315>
zink: avoid NULL-deref zink_render_pass_reference will dereference the memory 'dst' points at, which can't really go well. All we want to do here is to increase the reference-count, so let's use a different helper for that instead. CoverityID: 1455200 Reviewed-by: Dave Airlie <airlied@redhat.com>
zink: pass screen to zink_create_gfx_pipeline Acked-by: Jordan Justen <jordan.l.justen@intel.com>
zink: fixup return-value Acked-by: Jordan Justen <jordan.l.justen@intel.com>
zink: pool descriptors per batch Acked-by: Jordan Justen <jordan.l.justen@intel.com>
zink: keep a reference to used render-passes Acked-by: Jordan Justen <jordan.l.justen@intel.com>
zink: pass screen instead of device to program-functions Acked-by: Jordan Justen <jordan.l.justen@intel.com>
zink: move primitive-topology stuff into program The primitive topology is a bit of an odd-ball, as it's the only truly draw-call specific state that needs to be passed to the program to get a pipeline. So let's make this a bit more explict, by passing it separately. This makes the flow of data a bit easier to wrap your head around. Acked-by: Jordan Justen <jordan.l.justen@intel.com>