As noted in the previous commit, the intermediate cast to float from
double can produce wrong results.
Fixes upcoming Vulkan CTS tests:
dEQP-VK.spirv_assembly.instruction.compute.float_controls.fp16.input_args.rounding_rte_sconst_conv_from_fp64_up
dEQP-VK.spirv_assembly.instruction.compute.float_controls.fp16.input_args.rounding_rte_sconst_conv_from_fp64_up_nostorage
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp16.input_args.rounding_rte_sconst_conv_from_fp64_up_vert
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp16.input_args.rounding_rte_sconst_conv_from_fp64_up_nostorage_vert
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp16.input_args.rounding_rte_sconst_conv_from_fp64_up_frag
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp16.input_args.rounding_rte_sconst_conv_from_fp64_up_nostorage_frag
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25281>
We convert from doubles to half by going through float in between, but
as noted in the comment in this commit, that can give wrong results in
some cases.
Add some helpers to ensure correct results based on rounding mode that
will be used in the next commit.
v2: Use fi/di from u_math.h (Ian)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25281>
Appendix A: Vulkan environemtn for SPIR-V says:
Operations described as “correctly rounded” will return the infinitely
precise result, x, rounded so as to be representable in
floating-point. The rounding mode is not specified, unless the entry
point is declared with the RoundingModeRTE or the RoundingModeRTZ
Execution Mode.
Conversion between types are classified as correctly rounded, so let's
do rounding correctly.
v2: check rounding mode for destination bit size (Georg)
Fixes upcoming Vulkan CTS tests:
dEQP-VK.spirv_assembly.instruction.compute.float_controls.fp32.input_args.rounding_rtz_conv_from_uint64_up
dEQP-VK.spirv_assembly.instruction.compute.float_controls.fp32.input_args.rounding_rtz_conv_from_int64_up
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp32.input_args.rounding_rtz_conv_from_uint64_up_vert
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp32.input_args.rounding_rtz_conv_from_int64_up_vert
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp32.input_args.rounding_rtz_conv_from_uint64_up_frag
dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp32.input_args.rounding_rtz_conv_from_int64_up_frag
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25281>
This patch fixes the following issues that lead to crashes in some cases:
* an instruction is inserted to get texture lod that depends on a
texture instruction that hasn't been inserted yet.
* this code tries to read channel 1 of the lod, but lod is scalar
* the code assumed there would only be 2 srcs, this isn't the case when
bindless is used.
Fixes: b154a4154b ("nir/lower_tex: rewrite tex/txb -> txd/txl before saturating srcs")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25621>
This lets us throw errors back to the app for shaders that are too
complex. The X server would really like to have this instead of guessing
based on renderer strings when shaders might be too complicated.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25533>
`pvr_setup_isp_faces_and_control()` can be called from a secondary
command buffer. The render pass info's `attachments` array is only
populated in the primary command buffer on which the render pass
was started, thus the `ds_aspect` being used always ended up being
`0` leading to incorrect ISP state being setup.
This commit changes the function to use the `attachments` array
from the render pass struct instead of the one from the recording
state.
dEQP tests fixed:
dEQP-VK.renderpass.suballocation.attachment
.{1.13, 1.65, 1.74, 3.219, 3.236, 3.314, 3.385, 4.426}
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25351>
I'm not sure why I picked html_extra_path instead, as it's meant for
slightly less directly related files than what html_static_path is for.
So let's switch. It shouldn't make much of a real-world difference, but
should make it a bit easier to understand what this is about.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25585>
Only the HTML builder knows about these files, so we can't really link
to them when using other builders. This only matter to the link-checker
right now, because that's the only other builder we use.
It's a bit sad that we can't linkcheck files like these, but it doesn't
work either way. Another way of making it work could be to use the
download-role for these files. I'm not sure I think that's any better,
as that makes the code read a bit more confusingly to me; the intent
isn't to *download* the files, but to view them as raw-text.
I could go either way here, though. Neither is fantastic IMO, but
neither is a disaster either.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25585>
These redirects are all fine. I don't think we want to apply them,
because they are more about implementation details on the target site.
So let's just mark them as OK. They cause no harm.
There's also some redirects that are all about authentication. We also
don't want to apply these, because they would break the links.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25585>
The Wiki in this repo has been removed, and the about section mentions
that this is laanwj's personal fork, and not the upstream. So let's
update the link to the upstream repo instead.
There's no wiki there either, but the main repo itself contains a readme
file with some docs. Most of this is pretty stale, but it seems better
than nothing.
In the longer run, we should probably create a page about etnaviv in the
drivers directory of these docs, and try to keep that up to date.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25585>
The Git Wiki has been long deprecated, and is now partially removed. The
article we pointed to here seems to not have been backed up.
However, there's a new place that documents installing on Windows in the
Git Docs instead. So let's send users there instead.
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25585>
Fix defect reported by Coverity Scan.
Constant expression result (CONSTANT_EXPRESSION_RESULT)
always_true_or: The or condition
type != ANV_TIMESTAMP_CAPTURE_AT_CS_STALL || type != ANV_TIMESTAMP_REWRITE_COMPUTE_WALKER
will always be true because type cannot be equal to two different values
at the same time, so it must be not equal to at least one of them.
Fixes: 5112b42146 ("anv: Handle end of pipe with MI_FLUSH_DW on transfer queue")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25605>
In the linear allocator, when a size larger than the minimum
buffer size is allocated, we currently create the new buffer
to fit exactly the requested size.
In that case, don't bother updating the `latest` pointer, since
this newly created buffer is already full. In the worst case,
the current `latest` is full and it would be the same; in the
best case, there's still room for small allocations, so we avoid
wasting space if the next allocations would fit.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25517>
The refactor in a4f8fd9dd5 changed NV50_PROG_OPTIMIZE
from 3 to 0.
Running with NV50_PROG_OPTIMIZE=0 causes some shaders to not compile. One example is
dEQP-VK.pipeline.monolithic.creation_cache_control.compute_pipelines.duplicate_single_recreate_explicit_caching
which fails with:
"Assertion `insn->src(src0 & FA_SRC_MASK).getFile() == FILE_GPR' failed"
A similar error also happen when testing Serious Sam Fusion 2017
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25601>
