Fix defects reported by Coverity Scan.
uninit_member: Non-static class member score is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member prevData is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member prevOp is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8604>
This increases the wasted memory to 140 MB for DeusExMD, still below
the original number. The advantage is that we now get 2 MB pages for more
buffers and fewer total buffers allocated by the kernel, enabling faster
GPU page translation and slightly lower kernel overhead.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8683>
Instead of aligning slab allocations to powers of two (e.g. 129K -> 256K),
implement slab allocations with 3/4 of power of two sizes to reduce
overallocation. (e.g. 129K -> 192K)
The limitation is that the alignment must be 1/3rd of the allocation size.
DeusExMD allocates 2.1 GB of VRAM. Without this, slabs waste 194 MB due
to alignment, i.e. 9.2%. This commit reduces the waste to 102 MB, i.e. 4.9%.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8683>
Slabs always allocate the next power of two size from their pools. This
wastes memory if the size is not a power of two.
bo->base.size is overwritten because the default is the allocated power of
two size, but we need the real size to compute the wasted size in
amdgpu_bo_slab_destroy. entry_size is added to the hole in pb_slab_entry
to hold the real entry size.
Like other memory stats, no atomics are used.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8683>
Left unchecked, an app that just did an endless series of draws could
result in VSC buffer sizes >4GB, which doesn't work out well.
This limit is semi-arbitrary (ie. it is lower than hw limit, but 32*8MB
seems a bit excessive and not a limit that you'd hit in the real world).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8842>
According to VK_KHR_depth_stencil_resolve spec (see
VUID-VkSubpassDescriptionDepthStencilResolve-pDepthStencilResolveAttachment-03182):
"If the VkFormat of pDepthStencilResolveAttachment has a stencil
component, then the VkFormat of pDepthStencilAttachment must have a
stencil component with the same number of bits and numerical
type"
The issue with D32_SFLOAT_S8_UINT format is that it is implemented as
two planes, so we need to execute the separate_stencil path in
tu_emit_blit() to resolve its stencil component into S8_UINT image.
Fixes the following tests:
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d32_sfloat_s8_uint.compatibility_depth_zero_stencil_zero_testing_stencil
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d32_sfloat_s8_uint_separate_layouts.compatibility_depth_zero_stencil_zero_testing_stencil
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8527>
According to VK_KHR_depth_stencil_resolve spec (see
VUID-VkSubpassDescriptionDepthStencilResolve-pDepthStencilResolveAttachment-03182)
"If the VkFormat of pDepthStencilResolveAttachment has a stencil
component, then the VkFormat of pDepthStencilAttachment must have a
stencil component with the same number of bits and numerical type"
That means that we can resolve MSAA depth/stencil to a stencil only
image only if the stencil component matches with same number of bits
and type.
Although the driver only supports VK_RESOLVE_MODE_SAMPLE_ZERO_BIT
resolve mode, it was doing a sample average when resolving a MSAA
D24_UNORM_S8_UINT image to S8_UINT.
Fixes the following tests:
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d24_unorm_s8_uint.compatibility_depth_zero_stencil_zero_testing_s
tencil
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d24_unorm_s8_uint_separate_layouts.compatibility_depth_zero_stenc
il_zero_testing_stencil
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8527>
Vertex attribute bounds checking is supposed to be done per-attribute:
is_oob = index * stride + attrib_offset + attrib_size > buffer_size
but we were obtaining num_records by dividing the buffer size by the
stride, making it per-vertex:
is_oob = index * stride + (stride - 1) >= buffer_size
An example from Dead Cells (Wine) is:
attribute bindings: 0, 1, 2
attribute formats: r32g32, r32g32, r32g32b32a32
attribute offsets: 0, 0, 0
binding buffers: all the same buffer
binding offsets: 0, 8, 16
binding sizes: 128, 120, 112
binding strides: 32, 32, 32
Workaround this issue without switching to per-attribute descriptors by
rounding up the division. This is still incorrect, but it should now no
longer consider in-bounds attributes out-of-bounds.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3796
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4199
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8835>
Michel Dänzer