AMD APUs are hitting this case where they have very small discrete VRAM,
but a lot of staging memory, which can be used additionally.
Fixes: 7487ac2046 ("rusticl/device: support query_memory_info to retrieve available memory")
(cherry picked from commit 58d45725c7)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Is a single triangle is selected, it can be the case that the next iteration
can't merge any pair with the triangle. In that case, the HW node with a
single triangle will not have the highest hw_node_index, triggering an
assert.
Fixes: c18a7d0 ("radv: Emit compressed primitive nodes on GFX12")
Reviewed-by: Natalie Vock <natalie.vock@gmx.de>
(cherry picked from commit db38d1a98c)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
When cross-compiling with MinGW, d3d12_resource_state.cpp fails to
compile with:
d3d12_resource_state.cpp:161:83: error: call to non-'constexpr'
function 'D3D12_RESOURCE_STATES operator|(D3D12_RESOURCE_STATES,
D3D12_RESOURCE_STATES)'
161 | D3D12_RESOURCE_STATE_ALL_SHADER_RESOURCE |
| D3D12_RESOURCE_STATE_COPY_SOURCE | D3D12_RESOURCE_STATE_COPY_DEST;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/share/mingw-w64/include/minwindef.h:163,
from /usr/share/mingw-w64/include/windef.h:9,
from /usr/share/mingw-w64/include/windows.h:69,
from /usr/share/mingw-w64/include/rpc.h:16,
from /usr/share/mingw-w64/include/unknwn.h:7,
from ../subprojects/DirectX-Headers-1.0/include/wsl/winadapter.h:6,
from ../src/gallium/drivers/d3d12/d3d12_common.h:29,
from ../src/gallium/drivers/d3d12/d3d12_bufmgr.h:31,
from ../src/gallium/drivers/d3d12/d3d12_resource_state.cpp:24:
../subprojects/DirectX-Headers-1.0/include/directx/d3d12.h:3540:1:
note: 'D3D12_RESOURCE_STATES operator|(D3D12_RESOURCE_STATES,
D3D12_RESOURCE_STATES)' declared here
3540 | DEFINE_ENUM_FLAG_OPERATORS( D3D12_RESOURCE_STATES )
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
The DEFINE_ENUM_FLAG_OPERATORS macro in the MinGW winnt.h header
defines operator| for D3D12_RESOURCE_STATES as inline but not
constexpr. (The DirectX-Headers WSL stubs do define it as constexpr,
but when building with MinGW, windows.h is pulled in via winadapter.h
and its non-constexpr definition wins.) Calling a non-constexpr
function to initialize a constexpr variable is ill-formed in C++.
Fix by changing static constexpr to static const, which avoids the
constexpr context while still giving the variable static storage
duration.
Fixes: fe48cd7c5a ("d3d12: Allow state promotion for non-simultaneous access textures")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
(cherry picked from commit 2443f3608a)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Usually connector property IDs are acquired in
wsi_display_get_connector, which is called by wsi_get_connectors, and in
turn by vkGetPhysicalDeviceDisplayProperties2KHR and
vkGetPhysicalDeviceDisplayPlanePropertiesKHR. Except if the drm fd is
not available when these functions are called. Which will be the case if
vkAcquireXlibDisplayEXT is not called first.
So it goes like this. First, the display is created in
vkGetRandROutputDisplayEXT. Then it's used in
vkGetPhysicalDeviceDisplayPlanePropertiesKHR, but since the drm fd is
not available at this point, connector property IDs are not initialized.
Later, this display is used in vkAcquireXlibDisplayEXT, which also
doesn't touch the property IDs. Finally in drm_atomic_commit, the
atomic commit fails with EINVAL, specifically because of the
uninitialized ID of the "CRTC_ID" property. Since it's one of the
properties drm_atomic_commit tries to set.
This commit makes sure that find_connector_properties is called in
vkAcquireXlibDisplayEXT to initialize the property IDs.
Fixes: 513ffea1d3 ("wsi/display: use atomic mode setting")
Signed-off-by: Yuxuan Shui <yshui@codeweavers.com>
(cherry picked from commit 37a1986691)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The immediate fs_clear_color shader uses IMM[0] but still declares
CONST[0][0]. That can make drivers try to read a fragment constant
buffer even though one is never uploaded on this path. Only declare
CONST[0][0] when the shader actually uses a constant buffer.
Fixes: 2ff9fa8b72 ("gallium/u_blitter: add a new fs_color_clear variant")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 79e3196320)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Entering a loop with empty exec mask might lead to
not be able to execute the break condition and
lead to infinite loops.
Totals from 81 (0.04% of 202440) affected shaders: (Navi48)
Instrs: 3040566 -> 3040716 (+0.00%)
CodeSize: 17506768 -> 17507188 (+0.00%)
Latency: 16342966 -> 16345166 (+0.01%)
InvThroughput: 3112932 -> 3113286 (+0.01%)
Branches: 82229 -> 82365 (+0.17%)
Cc: mesa-stable
(cherry picked from commit 60b3e5b3f0)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Add asserts this time that we don't miss any and that the buckets
actually match the enum in bifrost/compiler.h.
Fixes: 82328a5245 ("pan/bi: Generate instruction packer for new IR")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit fd5c6d1223)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
On v12+, IDVS no longer has separate position and varying variants, so
we only need to emit stats for one binary. Attempting to emit stats for
the nonexistent varying shader breaks shader-db.
Fixes: 7819b103fa ("pan/bi: Add support for IDVS2 on Avalon")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
(cherry picked from commit 31ddfe26eb)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
All B-series Rogue cores seem to have USC rounding mode as RTE instead
of RTZ.
Set the has_usc_alu_roundingmode_rne feature flag for them (currently
only BXS-4-64 has it set).
Verified via testing on BXM-4-64 (36.52.104.182) by fixing CTS tests
dEQP-VK.spirv_assembly.instruction.*.float_controls.fp32.input_args.* ,
and via proprietary driver vulkaninfo result on BXE-2-32 (36.29.52.182),
BXE-4-32 (36.50.54.182) and BXM-4-64 (36.56.104.183) (checking
shaderRoundingModeRT?Float32 properties).
Fixes: 1db1038a61 ("pvr: add device info for BXM-4-64 (36.56.104.183)")
Fixes: e60e0c96ba ("pvr: add device info for BXE-2-32 (36.29.52.182)")
Fixes: 2743363a57 ("pvr: add device info for BXM-4-64 (36.52.104.182)")
Fixes: ea28791d40 ("pvr: add device info for BXE-4-32 (36.50.54.182)")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
(cherry picked from commit 9b44def4e9)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
If both src and dst are compressed formats, adjusting the extent isn't
necessary because it's required that texel block extent matches. The
previous division was also wrong because it was truncating partial
blocks causing issues in some tests.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 4e00e1c3d0)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The sc7180-trogdor-lazor-limozeen devices have been dying off over the
past few weeks, so move the last two jobs to sc7180-trogdor-kingoftown
and retire the device type.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
(cherry picked from commit bbed00ac81)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The sc7180-trogdor-lazor-limozeen devices are having issues, so move the
job to a different device with available capacity.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
(cherry picked from commit 17d38c9668)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
This could override data allocated by the application when shader code
is loaded from binary in vkCreateShaderObjectEXT().
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: d39e443ef8 ("anv: add infrastructure for common vk_pipeline")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
(cherry picked from commit 21952ffb07)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Fix non-functional issue where calls to cs_run_fragment() had swapped
tile_order and enable_tem arguments. Both arguments evaluate to 0.
Hence, no functional change.
Fixes: 53f780ec91 ("panfrost: Remove progress_increment from all CS builders")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
(cherry picked from commit 0d08b197f2)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The pvr_clear_vdm_state_get_size_in_dw() wrongly think instance count
inputs are needed when doing RTA clear for cores without the
gs_rta_support feature. However, the instance ID is exploited to output
the target layer ID, which isn't supported at all for cores w/o that
feature, so it looks that the condition is inverted. In addition, the
pvr_pack_clear_vdm_state() function seems to have similar logic deciding
whether to emit instance_count, and the logic is opposite to the logic
in pvr_clear_vdm_state_get_size_in_dw() for the part checking the
gs_rta_support feature.
Invert the condition to take instance ID inputs for cores with the
gs_rta_support feature instead of those without this feature.
Fixes: b59eb30e88 ("pvr: Fix cs corruption in pvr_pack_clear_vdm_state()")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
(cherry picked from commit 3db93bbf34)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
runtime error: left shift of 65535 by 16 places cannot be represented in type 'int'
This fixes nir_opt_algebraic_pattern_test.bf2f.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Fixes: ecd2d2cf46 ("util: Add functions to convert float to/from bfloat16")
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
(cherry picked from commit 72f2b8a034)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Without this, reg_offset will return 1024 for acc0. This causes
has_invalid_dst_region to decide that the destination region is invalid
(because 1024 != 0), and the lowering code tries to treat the floating
point accumulators as integers. It's a mess.
v2: Add and use set_gfx_platform. Suggested by Caio.
Fixes: 937373eb25 ("i965/fs: Handle fixed HW GRF subnr in reg_offset().")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
(cherry picked from commit cfdb3ddb93)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Integer accumulators and float accumulators do not occupy the same bits,
so the types cannot be arbitrarily changed.
No shader-db or fossil-db changes on any Intel platform.
v2: Use is_accumulator() instead if brw_reg_is_arf(). Add an extra test
to show the desired behavior when an accumulator is not
involved. Suggested by Caio.
Fixes: 64c251bb3a ("intel/fs: Combine constants for SEL instructions too")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
(cherry picked from commit ffdc310bf1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
After abe6d750e5, glXDestroyContext() can defer destruction by marking
the context with xid == None while it is still current.
However, the release-current path did not clear current->currentDpy,
so a context that had already been marked for deletion could remain
associated with a display after unbinding.
Fixes: abe6d750e5 ("xlib: fix glXDestroyContext in Gallium frontends")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14947
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 447a1d2e8d)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
panfrost_bo_import() calls drmPrimeFDToHandle() then pan_kmod_bo_import(),
which also calls drmPrimeFDToHandle() internally. This double import causes
GEM handle refcount leaks because each drmPrimeFDToHandle() increments the
kernel's GEM handle refcount, but only one drmCloseBufferHandle() is called
during cleanup by panfrost_kmod_bo_free(or panthor_kmod_bo_free).
Fix by removing the redundant drmPrimeFDToHandle() and using
pan_kmod_bo_import() directly. On re-import of existing buffers, properly
release the extra pan_kmod_bo reference with pan_kmod_bo_put().
This ensures GEM handle refcount, pan_kmod_bo refcount, and panfrost_bo
refcount are all properly balanced.
Fixes: 5089a758df ("panfrost: Back panfrost_bo with pan_kmod_bo object")
Signed-off-by: Xianzhong Li <xianzhong.li@nxp.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
(cherry picked from commit 248b0b47b7)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The only real requirement here is that the destination offset is zero
and that the destination is big enough to hold the source. The source
offset doesn't matter.
Fixes: bc17288697 ("pan/bi: Lower split/collect before RA")
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit 05c5e52054)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
The non-trivial non-replicate swizzles on IADD.v4x8 and ISUB.v4x8 are
either documented wrong or broken in hardware. Instead of swizzling
b0101 and b2323, they swizzle b0011 and b2233 on G52. This is either a
hardware bug or an issue with documentation. In either case, it's
probably best not to trust it. Those swizzles aren't all that useful
anyway. We also weren't using any of them before (or they'd have
broken) so this isn't a performance regression.
Cc: mesa-stable
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit 538b5c411e)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
Midpoint sorting is incompatible with how our traversal works.
Specifically, we change tMax when a hit is committed so we can skip over
BVH nodes that are guaranteed not to produce a closer hit. However,
changing tMax also changes the intersection interval of box nodes with
the ray, and thus, the midpoints of that interval. Stackless traversal
relies on getting nodes back in the exact same order as before, and if
that requirement is not met, traversal may incorrectly skip over nodes.
The likely benefit of midpoint sorting does not make up for the loss of
ability to skip over BVH nodes exceeding tMax, so simply disable
midpoint sorting.
This fixes geometry being visible behind other geometry when it
shouldn't be in various applications, including Half-Life 2 RTX.
Cc: mesa-stable
(cherry picked from commit c1a7680d93)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
ballot_bit_count_reduce expects the ballot to have 4 components causing
validation failures on targets where 1 < ballot_components < 4. Fix this
by padding the ballot to 4 components.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: ae66bd1c00 ("nir/opt_uniform_subgroup: use ballot_bit_count")
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
(cherry picked from commit cc6eec79c2)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
nir_builder_alu_instr_finish_and_insert initialized the def's bit_size
and num_components so we should set them afterwards.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Fixes: c66967b5cb ("nir: add nir_opt_varyings, new pass optimizing and compacting varyings")
(cherry picked from commit 273fd18b89)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
st_cb_bitmap appends a temporary bitmap sampler view to the sampler
view array passed to set_sampler_views().
1a5c660ef5 changed this path to only release the extra YUV views
returned by st_get_sampler_views(), but the temporary bitmap view is
created locally and is not part of extra_sampler_views. It therefore
stopped being released so release the temporary bitmap sampler view
explicitly after drawing the bitmap quad.
Fixes: 1a5c660ef5 ("st/bitmap: only release YUV samplerviews")
(cherry picked from commit 33864e569e)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
From the OpenCL specification:
`CL_MEM_KERNEL_READ_AND_WRITE`: This flag is only used by
clGetSupportedImageFormats to query image formats that may be both
read from and written to by the same kernel instance. To create a
memory object that may be read from and written to use
CL_MEM_READ_WRITE.
If an application follows the instructions above, i.e. query a list of
supported image formats, using `CL_MEM_KERNEL_READ_AND_WRITE` as
input, and then attempts to create an image using one of the supported
image formats, by calling `clCreateImage` and passing
`CL_MEM_READ_WRITE`, the call to the image creation entry point should
succeed. This instead fails on Mali devices with the error
`CL_IMAGE_FORMAT_NOT_SUPPORTED`.
Rusticl fails when validating the image format against its supported
flags. Formats that support `PIPE_BIND_SHADER_IMAGE` have their
supported flags set as `CL_MEM_WRITE_ONLY` and
`CL_MEM_KERNEL_READ_AND_WRITE`.
This changes the supported CL flags to be `CL_MEM_WRITE_ONLY` for
`PIPE_BIND_SHADER_IMAGE` and `CL_MEM_READ_WRTE |
CL_MEM_KERNEL_READ_AND_WRITE` for `PIPE_BIND_SAMPLER_VIEW |
PIPE_BIND_SHADER_IMAGE`.
Fixes: 3386e142 (rusticl: support read_write images)
Fixes OpenCL-CTS test: `test_image_streams` on Mali. Invocation:
```
test_image_streams write 1D CL_RGB CL_SIGNED_INT8
```
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
(cherry picked from commit e77c984cef)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
This would read OOB and crash because data type is optional per the
SPIRV spec.
Original patch by Faith Ekstrand <faith.ekstrand@collabora.com>.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 1f8be7bfad)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40979>
When converting the index buffer from 4-bytes to 2-bytes, we use the
uploader for the job. Since commit b3133e250e we do an uploader alloc
ref, which releases the uploader buffer if there is no enough space,
creating a new one.
The problem happens when we also need this buffer because it is the one
containing the index buffer to convert. This happens, for instance, if
we need to convert the primitives because they are not supported (e.g.,
converting quads to triangles), as this is done
also using the uploader.
The solution is to ensure the uploader's buffer has an extra reference
so when released, it is not destroyed. This can easily achieved by
calling first pipe_buffer_map_range(), which is required to access the
buffer, and it increases the references.
This fixes `spec@!opengl 1.1@longprim`.
Fixes: b3133e250e ("gallium: add pipe_context::resource_release to eliminate buffer refcounting")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
(cherry picked from commit 48c086cb42)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
R300_PACKET3_3D_CLEAR_HIZ encodes COUNT in 14 bits (COUNT[13:0]), so a
single packet can clear at most 0x3fff dwords.
Large depth surfaces on R5xx can require more HiZ dwords than that.
When we emitted a single packet, COUNT truncated and part of HiZ RAM
remained uncleared, which could show up as HyperZ corruption.
Emit CLEAR_HIZ in chunks of R300_CLEAR_HIZ_COUNT_MAX and reserve enough
atom space for the worst-case packet count derived.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/360
Fixes: 12dcbd5954 ("r300g: enable Hyper-Z by default on r500")
(cherry picked from commit fddc101070)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
