Applications may use out-of-range values, driver is responsible for
clamping to implementation-dependent sample location coordinate
range.
Without clamp we hit assert when packing 3DSTATE_SAMPLE_PATTERN if
application attempts to use bigger value than 0.9375.
util_bitpack_ufixed: Assertion `min <= v && v <= max' failed.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18696>
If the pipeline does not use libraries and the shaders are all found in
the cache, we end up with empty groups and crash at pipeline emit time.
Fixes a bunch of tests under
dEQP-VK.pipeline.monolithic.shader_module_identifier.\*.ray_tracing\*
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18582>
Warning:
aco_register_allocation.cpp(383): warning C4819: The file contains a character that cannot be represented in the current code page (0). Save the file in Unicode format to prevent data loss
This warning was treated as error with compiling with msvc
u8 is belongs to c11 standard so it's safe to use it
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18682>
It's already called in brw_postprocess_nir and calling it the second time
actually breaks shading rate.
Initially, when I added this call here in 9acb30c8c4, I was testing it
on an internal tree, which didn't have brw_nir_lower_shading_rate_output call
in brw_postprocess_nir.
Fixes: 9acb30c8c4 ("intel/compiler: implement primitive shading rate for mesh")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18702>
This brings in new msm UAPI that we'd like to be testing in turnip.
Unfortunately, a530 became flaky across dEQP and piglit. It seems that a
GPU hang from a test that we expect to hang will cause a followup
hangcheck affecting innocent tests. For example:
22-09-19 18:53:22 R SERIAL> [ 348.839188] msm_mdp 901000.mdp: [drm:a5xx_irq] *ERROR* gpu fault ring 0 fence ff55 status C10001C3 rb 084a/084a ib1 000000000105A000/0000 ib2 000000000105B000/0000
22-09-19 18:53:22 R SERIAL> [ 348.839272] msm_mdp 901000.mdp: [drm:recover_worker] *ERROR* A530: hangcheck recover!
22-09-19 18:53:22 R SERIAL> [ 348.852698] msm_mdp 901000.mdp: [drm:recover_worker] *ERROR* A530: offending task: shader_run:sq0 (/piglit/bin/shader_runner tests/spec/glsl-1.30/execution/clipping/vs-clip-distance-enables.shader_test -auto -fbo)
22-09-19 18:53:22 R SERIAL> [ 348.868680] msm_mdp 901000.mdp: [drm:a5xx_irq] *ERROR* gpu fault ring 0 fence ff55 status C10001C3 rb 084a/084a ib1 000000000105A000/0000 ib2 000000000105B000/0000
22-09-19 18:53:22 R SERIAL> [ 348.879586] msm_mdp 901000.mdp: [drm:recover_worker] *ERROR* A530: hangcheck recover!
[...]
22-09-19 18:53:23 R SERIAL> ERROR - Test spec@glsl-1.10@execution@algebraic@glsl-algebraic-logicand-false: Fail: See "//results/piglit.spec@glsl-1.10@execution@algebraic@glsl-algebraic-logicand-false.log"
As a result, I've moved a530 to test-manual-mr until it can be stabilized
again. This updated kernel also brings in a couple of regression fixes
for nouveau gk20a and gm20b.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18624>
The updated board has a stabilized GPU and now I just need to decide if
I'm building a farm of them or not. The new firmware flash needs a
reminder to the kernel of how to do NFS (no v2, thanks). Also, the full
run is long and we need the TEST_PHASE_TIMEOUT variable to go past 20
minutes now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18674>
Right now there is a call to rc_get_variables, which performs a global
analysis of the whole shader, for every IF encountered. As a result,
shaders with a lot of IFs are compiled very slowly. The patological
cases are shaders using relative adressing, where the lowered array
access can result in tens of IFs.
This patch restructures the pass to call the rc_get_variables just once
at the beginning and later reuse the gathered info. We can do this,
because even though we transform the shader in the meantime (like for
example adding extra MOVs) the transformations are not siginificant
enough to influence the relevant variable info we are using.
This reduces CPU time for my shader-db by more than a half. I also
checked that the generated code for all shaders in shader-db is
identical.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18678>
This extension was promoted to Vulkan 1.3 so we should be setting its
properties directly in the VkPhysicalDeviceVulkan13Properties struct
which the common mesa code will use to populate outgoing properties.
Apparently, only the properties struct was promoted and not the features
struct.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Tested-by: Eric Engestrom <eric@igalia.com>
Fixes: ee62a4c751 ('v3dv: implement VK_EXT_texel_buffer_alignment')
Fixes: dEQP-VK.api.info.get_physical_device_properties2.properties.basic
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18697>
../mesa/src/amd/common/ac_surface.c:2324:48: warning: implicit conversion from enumeration type 'AddrResourceType' (aka 'enum _AddrResourceType') to different enumeration type 'enum gfx9_resource_type' [-Wenum-conversion]
surf->u.gfx9.resource_type = AddrSurfInfoIn.resourceType;
~ ~~~~~~~~~~~~~~~^~~~~~~~~~~~
../mesa/src/amd/common/ac_surface.c:3046:38: warning: implicit conversion from enumeration type 'const enum gfx9_resource_type' to different enumeration type 'AddrResourceType' (aka 'enum _AddrResourceType') [-Wenum-conversion]
input.resourceType = surf->u.gfx9.resource_type;
~ ~~~~~~~~~~~~~^~~~~~~~~~~~~
../mesa/src/amd/common/ac_surface.c:3069:38: warning: implicit conversion from enumeration type 'const enum gfx9_resource_type' to different enumeration type 'AddrResourceType' (aka 'enum _AddrResourceType') [-Wenum-conversion]
input.resourceType = surf->u.gfx9.resource_type;
The enums are compatible so lets just add some casts.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18694>
Marcin Ślusarz