CID 1528170 (#1 of 1): Logically dead code (DEADCODE)
At condition gc, the value of gc cannot be NULL.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Illia Polishchuk <illia.a.polishchuk@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20893>
CID 1528164 (#1 of 1): Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)
overflow_before_widen: Potentially overflowing expression
pool->n_passes * pool->khr_perf_preamble_stride with type
unsigned int (32 bits, unsigned) is evaluated using 32-bit arithmetic,
and then used in a context that expects an expression of type uint64_t (64 bits, unsigned).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Illia Polishchuk <illia.a.polishchuk@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20893>
Actually, uintptr_t is of type unsigned long, but the
debug line uses the %d format specifier, which expects an int.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Illia Abernikhin <illia.abernikhin@globallogic.com>
Found by Coverity.
CID: 1515961
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20893>
whandle initialization inside if statement but used also outside
Signed-off-by: Illia Abernikhin <illia.abernikhin@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Found by Coverity.
CID: 1516746
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20893>
When a default value of a struct's field, which is in the
higher half of the first dword, is specified in a gen xml
file, setting op mask makes decoder treat the field as a
header (intel_field_is_header()). As a result, it won't
output the field in batch dump. This is not a common case
but can happen once a gen xml file includes such fields.
The op mask is only meaningful to instructions, so we fix
the above issue by not setting op mask of structs (also
registers).
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24268>
Before this patch, iris_resource_render_aux_usage would disable
compression when the clear color did not support format
reinterpretation.
With this patch, iris now replaces the clear color with zero and keeps
compression enabled. Disabling fast clears would be enough for most aux
usages, but replacement is also done to handle ISL_AUX_USAGE_FCV_CCS_E.
Note that this also fixes a bug. Format reinterpretation with
incompatible clear colors previously was not handled for the MCS aux
usages.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23676>
iris_resource_prepare_render will soon gain the ability to change a
resource's clear color. iris_blorp_surf_for_resource will keep a copy of
that clear color, so make sure calls to it happen after the render
preparation helper. At the moment, this shouldn't have an impact besides
improving debugging.
While we're here, do the same for the generic access preparation helper.
We may convert those to more specific helpers at a later time.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23676>
ISL's state-machine of CCS_D describes full resolves as leaving the aux
buffer in the pass-through state. Hardware doesn't behave this way on
gfx8 however. On that platform, full resolves transition the aux buffer
to the resolved state. This was verified by dumping the CCS before and
after a full resolve on BDW (gfx7 is simply assumed to behave the same).
Ambiguate after resolving to match driver expectations.
Prevents iris from failing piglit's fcc-write-after-clear on BDW with a
future patch which relies on fast-clear encodings being removed after a
resolve. The avoided failure is:
Testing implicit read of partial block UNORM -> SNORM
Probe color at (0,1,0)
Expected: 1.000000 1.000000 1.000000 1.000000
Observed: 0.000000 0.000000 0.000000 0.000000
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23676>
The field is no longer consumed by brw_complie_* and is instead handled
directly by the crocus driver. Therefore, it's safe to leave it zero
and not even bother setting it. This removes our reliance on the
SWIZZLE_* macros in prog_instructions.h.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24288>
