It is broken and clang uses fp32 for float constants if the fp64 extension
isn't enabled anyway. SPIRVs can't use fp64 constants with printf unless
they enable the Float64 cap, which also requires cl_khr_fp64 to be
supported.
So just remove it and rely on clang handling -cl-single-precision-constant
correctly, which at the moment doesn't seem to be the case, but we can
think about that once we plan to support cl_khr_fp64.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26541>
These are now covered by nir_opt_loop():
- opt_if_loop_last_continue()
- opt_merge_breaks()
- opt_if_loop_terminator()
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24940>
Bindings are not necessarily globally unique, and even the location
where we were trying to read the binding value out of is a union, so
we could be trying to compare binding values against data for other
arg types.
Instead, use the arg metadata offset, which is globally unique and
outside of the union.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26555>
All these jobs are redundant and a waste of resources:
- the containers have already been built & pushed in the merge pipeline
- the mesa build variants have already all passed
- the driver tests have already all passed
None of these jobs are doing anything useful in this pipeline, but it
costs a factor of 2x to our infrastructure, so let's remove them.
In other words, the only job left in the post-merge pipeline is the
`pages` job that deploys the update to the website.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26451>
Otherwise, if a variable has multiple derefs in a shader, we'll crash
trying to remove it a second time. No idea how that can happen though,
seems derefs got sunk by opt_dead_cf.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26435>
When given (e.g.) 3x 16-bit components to store on a device that
isn't using native 16-bit loads and stores, we should be lowering
that into one 32-bit store and one masked store. Instead, the logic
here ends up returning that the best we can do is one 8-byte store,
which is clearly wrong. Stores should round down, loads should
round up.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26293>
For a dGPU, we should have:
1. RAM
2. RAM + write-combined CPU access
3. RAM + cached CPU access
4. VRAM
Eventually there'll be VRAM + write-combined CPU access after 4, using "GPU upload heaps"
For an iGPU, we should have:
1. RAM (declared as device-local)
2. RAM + write-combined CPU access (declared as device-local)
3. RAM + cached CPU access (declared as device-local)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26037>
First, we need to give the parent_instr field a unique name to be able to
replace with a helper. We have parent_instr fields for both nir_src and
nir_def, so let's rename nir_src::parent_instr in preparation for rework.
This was done with a combination of sed and manual fix-ups.
Then we use semantic patches plus manual fixups:
@@
expression s;
@@
-s->renamed_parent_instr
+nir_src_parent_instr(s)
@@
expression s;
@@
-s.renamed_parent_instr
+nir_src_parent_instr(&s)
@@
expression s;
@@
-s->parent_if
+nir_src_parent_if(s)
@@
expression s;
@@
-s.renamed_parent_if
+nir_src_parent_if(&s)
@@
expression s;
@@
-s->is_if
+nir_src_is_if(s)
@@
expression s;
@@
-s.is_if
+nir_src_is_if(&s)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24671>
This test checks the driver's reported conformance version against the
version of the CTS we're running. This check fails every few months
and everyone has to go and bump the number in every driver.
Running this check only makes sense while preparing a conformance
submission, so skip it in the regular CI.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25519>
The inc_compiler should come as part of idep_compiler, idep_nir or
idep_nir_headers dependency.
Acked-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> (v3dv)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25314>
That will make sure the include directories are passed on and also
make sure the generated headers are properly built before whoever code
depends on it. NIR dependency propagates that dependency too.
Since the right include directory is always propagated, we can remove
the extra "compiler/" prefix from the `#include`s in glsl_types.h.
Note: NIR has a special "header only" dependency, so include the
generated headers for compiler there too.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9843
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25314>
This is actually a no-op on AMD, so we really don't want to lower it to
something more complicated. There may be a more efficient way to do
this on Intel too. In addition, in the future we'll want to use this for
lowering boolean reduce operations, where the inverse ballot will
operate on the backend's "natural" ballot type as indicated by
options->ballot_bit_size, instead of uvec4 as produced by SPIR-V. In
total, there are now three possible lowerings we may have to perform:
- inverse_ballot with source type of uvec4 from SPIR-V to inverse_ballot
with natural source type, when the backend supports inverse_ballot
natively.
- inverse_ballot with source type of uvec4 from SPIR-V to arithmetic,
when the backend doesn't support inverse_ballot.
- inverse_ballot with natural source type from reduce operation, when
the backend doesn't support inverse_ballot.
Previously we just did the second lowering unconditionally in vtn, but
it's just a combination of the first and third. We add support here for
the first and third lowerings in nir_lower_subgroups, instead of simply
moving the second lowering, to avoid unnecessary churn.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25123>
