So we have a lower level representation of a buffer object that we can
manipulate that is not tied to a Vulkan representation of memory. This
will be useful as we start allocating driver internal buffers, such as
command lists.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
Right now there is not a big reason/difference to implement the
utilities present at v3d_debug for the vulkan driver, so lets just
reuse it.
The other advantage is that is the debug utilities used by common
parts of the driver, like broadcom/compiler
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This relies heavily in infrastructure taken from the v3d driver. We should
probably look for ways to share the code between both drivers by creating
a surface layout library that we can use from both, or at least moving
parts of the v3d driver to broadcom/common. Specifically:
We take v3d_tiling.c, which requires gallium's pipe_box type for some
helper functions that we don't quite need yet.
We copied and adapted bits of v3d_resource.c into v3dv_image.c, however,
it should be possible to look for ways to reuse the code instead of
duplicating it.
Pre-compute UIF padding into the slice setup. This is different from
what we do in v3d (we do this at cerate_surface time), but it is
more convenient for us to pre-calculate it here for all mipmap
slices.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This takes a subset of vk_format_info.h from Anvil which has some
Intel specific elements. At some point we might want to discuss
if we want to make the file reusable and move the intel bits to
some other place, but it is not a lot of code and for now this works,
so we keep going.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
For now we are only interested in being able to include the header
file for format definitions, so this is enough. When we start actually
emitting packets we will need to provide proper hooks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
Not an actual implementation since this doesn't initialize any actual
physical devices just yet.
Also, this doesn't check that available decices are really compatible
with the driver for now. This is for convenience, so we can move
past this point even if we are not running on actual hardware.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
Initial commit, mostly a import of the minimum from anv/radv to get a
skeleton to start to work with.
In includes:
* meson files
* Copy & adapt entrypoints ane extensions scripts from anv (that were
later used on radv)
This is a firt approach, but is is likely that we can remove/simplify
some things.
v2: fix copyright character at broadcom/vulkan/meson.build (Eric)
v3: no spaces inside arrays (Dylan)
v4: add gnu_symbol_visibility (detected by CI on first Merge attemp)
Reviewed-by: Eric Anholt <eric@anholt.net>
squash! v3dv: add v3d vulkan driver skeleton
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
To ask to debug a registr allocation failure
(V3D_DEBUG_REGISTER_ALLOCATION seemed too long to me).
When a fallback register allocation algorithm was added, if the
register allocation fails, it only dumpg the current vir with the
register pressure info with the failed fallback. But if we want do
debug the problem, we would be interested on both.
Additionally, it was strange that we got the full vir dump with the
failure even if no debug option was set.
Additionally we add shaderdb like stats for those failures, to make
easier to compare one and the other.
v2: keep a small warning message in case both register allocation
algorithms fails (Neil)
Reviewed-by: Neil Roberts <nroberts@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6999>
This is needed due Vulkan because by spec (31.1. Limit Requirements)
the minimum value for the following limits are the following ones:
maxPerStageDescriptorSampledImages 16
maxPerStageDescriptorStorageImages 4
maxPerStageDescriptorInputAttachments 4
And we are using v3d textures for all of them, so current limit would
not be enough for some cases.
Note that as the current comment explains there is not exactly a HW
limit for it, so we could bump to 32 for example, but let's just be
conservative and ask the minimum required.
It is worth to note that we needed to maintain the same value for the
OpenGL case, as it gets a register allocation failure on some GL
cases. We tried to fix that with small changes on the nir scheduler,
but we found that it would require some non-trivial effort to get it
done (that eventually we would need to).
Fixes tests like:
dEQP-VK.binding_model.descriptorset_random.sets16.constant.ubolimitlow.sbolimitlow.imglimitlow.noiub.uab.comp.noia.0
v2: keep the previous limit for Opengl (Eric)
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6999>
