panvk: Split panvk source files
What does this MR do and why?
Right now, panvk source split is a bit odd, with almost all the driver internal functions and structs defined in panvk_private.h, various stuff implemented in panvk_device.c even though they're not directly related to VkDevice, and everything descriptor set related in panvk_descriptor_set.c,h.
We also sometimes have implementation for a VkXxxx concept split in panvk_vX_xxxx.c (for the per-gen part) and panvk_xxx.c (for the generic part). While this might help reduce the binary size, it's overly confusing, and if we're really interested in reducing the final driver size, we might be better off providing a way to disable architectures. This MR merges panvk_xxx.c into panvk_vX_xxxx.c and makes such implementations entirely per-gen, which also allows us to use the mali_xxx_packed structs direction, instead of some opaque uint32_t arrays sized to cover the max of all supported arches.
BTW, I'm seriously considering getting rid of the panvk_vX_ prefix and prefix both per-gen and gen-agnostic source files with panvk_ (the distinction could still be identified by looking at meson.build file, or the header).
@kusma How would you feel about that ^.
This cleanup is just the first step before further per-gen specialization that will be needed for v9 and v10 support. Ultimately, we will end up with something like:
# Valhall adopted a new descriptor model closer to what Vulkan wants
src/panfrost/vulkan/{bifrost,valhall}/panvk_[vX_]descriptor_set[_layout].{c,h}
src/panfrost/vulkan/{bifrost,valhall}/panvk_[vX_]pipeline[_layout].{c,h}
src/panfrost/vulkan/{bifrost,valhall}/panvk_vX_nir_lower_descriptors.c
src/panfrost/vulkan/{bifrost,valhall}/panvk_[vX_]cmd_desc.{c,h}
# Job frontend changes the way we issue draw/dispatch calls, and the way we track the cmd buffer state
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]cmd_gfx.c
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]cmd_compute.c
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]cmd_buffer.{c,h}
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]queue.{c,h}
# Events are natively supported on CSF
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]event.{c,h}
# Once transitioned to vk_meta, anything meta should be generic
src/panfrost/vulkan/panvk_meta.{c,h}
# Everything that is already generic after this MR will stay
src/panfrost/vulkan/panvk_priv_bo.{c,h}
src/panfrost/vulkan/panvk_android.c
src/panfrost/vulkan/panvk_buffer.{c,h}
src/panfrost/vulkan/panvk_image.{c,h}
src/panfrost/vulkan/panvk_cmd_pool.{c,h}
src/panfrost/vulkan/panvk_physical_device.{c,h}
src/panfrost/vulkan/panvk_instance.{c,h}
src/panfrost/vulkan/panvk_mempool.{c,h}
src/panfrost/vulkan/panvk_wsi.{c,h}
src/panfrost/vulkan/panvk_macros.h
src/panfrost/vulkan/panvk_varyings.h
...
# Some files are per-gen, but their implementation is similar enough that it doesn't deserve a bifrost/valhall split
# and can instead be specialized with #if PAN_ARCH == xx sections in the code
src/panfrost/vulkan/panvk_[vX_]buffer_view.{c,h}
src/panfrost/vulkan/panvk_[vX_]image_view.{c,h}
src/panfrost/vulkan/panvk_[vX_]shader.{c,h}
src/panfrost/vulkan/panvk_[vX_]sampler.{c,h}
src/panfrost/vulkan/panvk_[vX_]device.{c,h}Getting there requires mores cleanups (like the transition to vk_meta, the transition to vk_graphics_state for cmdbuf state tracking, or the split of panvk_cmd_buffer.{c,h} in smaller pieces that can be specialized independently), but I'd like to have your opinion early on so I don't spend too much time splitting things as I suggest if you think that's irrelevant.
This MR depends on !28104 (merged) and !28167 (merged).