Midgard aggregates a large amount of state into its renderer state descriptor.
Our current dirty tracking reflects this, with a single RENDERER dirty flag.
That won't work well on Valhall, which splits out orthogonal state into
independent descriptors (a blend descriptor, a depth/stencil descriptor, and so
on). To prepare for Valhall support, this patch moves the driver to finer dirty
tracking.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15956>
The optimized routine documented the tiling format together with the software
algorithm. The reference implementation wants the tiling format alone
documented. Let's break out the high level documentation into somewhere
centrally accessible, and refocus the comments in the optimized file on the
optimization.
This documentation is linked bidirectionally with both implementations, so it
should be easy to find.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15803>
The exact semantics of these routines are subtle, although they match what
Gallium wants. We're about to add unit tests. Add some comments that make it
obvious what it is we expect these routines to do. (In particular, it's not a
general region-of-interest copy, it's a region-of-interest of the tiled image
and the entire linear staging image.)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15803>
Now that tiled access to 3D textures works, we can enable tiling on all texture
targets. In particular, this adds tiling support for cube maps, arrays, and 3D
textures. Previously, these would usually fall back to linear, which is hard on
the caches.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15803>
Thanks to our macros and some type trickery, our generic tiling routines are
type-generic. So we just need to add 48-bit and 96-bit texel types to tile. Note
we only support power-of-two bit sizes in the specialized tile routines for the
sake of replacing a multiplication with a shift.
With this change, all pixel formats supported in Panfrost are tileable.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15803>
This fixes a number of tests like :
dEQP-VK.renderpass*.suballocation.multisample.s8_uint.*
dEQP-VK.renderpass*.suballocation.multisample.separate_stencil_usage.d24_unorm_s8_uint.*.test_stencil
dEQP-VK.renderpass*.suballocation.multisample.d24_unorm_s8_uint.*
dEQP-VK.renderpass*.suballocation.multisample.d32_sfloat_s8_uint.*
Because the driver asserts when generating RENDER_SURFACE_STATE with a
8 Valign value for stencil buffer (only 2 & 4 are supported).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12670>
Fossilize always enables all supported extensions, that means that
adjust_frag_coord_z would always be enabled on RDNA2, even if the
application doesn't enable it. The pipeline key would then be different
and precompilation wouldn't work. Move this per-pipeline since we can
know if VRS will be used.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15444>
The DXIL validator doesn't like dynamic indexing into resources if the
resource was not declared as an array type. This commit makes it so that
we always generate array resource types if the original type was
declared as an array instead, not just when the number of elements is
greater than 1.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14988>
This prevents more use-after-free errors. Passing them around using
std::unique_ptr ensures that the LLVMContext gets destroyed but doesn't
ensure destruction order. Declaring it on the stack ensures that the
context doesn't get destroyed until right before the the function
returns which is after any other LLVM stuff is destroyed.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15937>
First, separate out the LLVM context logging to make it take a
clc_logger instead of passing in a string stream. Currently, the LLVM
context may outlive the string stream which we assign which may lead to
use-after-free errors. Second, use a separate string stream for clang
diagnosticl logging which we intentionally declare before the compiler
so the compiler can't outlive it.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Icecream95 <ixn@disroot.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15937>
Alyssa Rosenzweig