The big pile of crashes were all either not covered by the fractional run
and a full run hadn't been run to update them, or unsupported where
Crash->Skip is not being reported as UnexpectedPass.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23385>
No need to have st_program.c come back into ATI_fs for this when it's a
property of program generation. ARB programs set these up in their
translation, as well.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23111>
Now ati_fs takes the same basic path as prog_to_nir, and we don't have to
think about it so much. Also, the ATI_fs frontend can skip shader info
setup since nir_shader_gather_info does it.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23111>
This means that the main NIR translation for ATI_fs is now independent of
the fp key, and we could do it earlier in the compile pipeline.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23111>
Now it's implemented as a RMW of the FRAG_RESULT_COLOR output var (or
adjusting the store_output intrinsic's value for lowered i/o), which
should be reusable other places we might want to emit shader code for fog
(ARB_fp, fixed function fragment shaders).
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23111>
It's one of the weirder parts of our shader interface's interactions with
the GL API, so let's try to make it a little cleaner.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23111>
Instead of treating all 16-bit values as "native 16-bit types,"
differentiate between concrete casts and mediump casts, where the
former requires native 16-bit types, and the latter only requires
DXIL min-precision. Additionally, UBO/SSBO loads/stores require
native 16-bit types.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23344>
The DXIL backend would like to distinguish between casts to 16-bit
that must cast, vs those that may. If a shader only ever produces
16-bit types from mediump casts and ALU ops on those values, then
the resulting shader can be annotated with DXIL's min-precision
qualifier, basically telling the driver to use 16-bit precision if
it's faster for them. If it uses concrete 16-bit casts, or loads/
stores to externally-visible memory, then it must use the "native"
16-bit flag, which is not supported on all hardware.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23344>
When you set PIPE_CAP_FS_POINT_IS_SYSVAL, we'd fall out of
is_allowed_invariant(), despite it being allowed on special builtins.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22950>
This adds a new limit, changing PIPE_SHADER_TYPES seems frought
with danger and very tricky. Currently only lava/llvmpipe plan to
offer task/mesh in GL land, so let's limit the fallout for now.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23291>
There is no good reason of having it too big and radeonsi returns an
absurd high value through PIPE_SHADER_CAP_MAX_CONST_BUFFER0_SIZE.
This speeds up the CTS testing this device limit.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23378>
In commit 284f0c9a57 I refactored the
handling of the data source to just call a helper rather than special
casing opcodes with 0 or 2 sources. Unfortunately, I also dropped the
"else return 1", creating a fallthrough for all sources other than
SURFACE_LOGICAL_SRC_ADDRESS and SURFACE_LOGICAL_SRC_DATA.
The case below happened to return the correct value for all cases except
SURFACE_LOGICAL_SRC_SURFACE, which has been returning 2 instead of 1
since that commit.
Restore the else case. Thanks to Marcin Ślusarz for catching this.
Fixes: 284f0c9a57 ("intel/compiler: Add an lsc_op_num_data_values() helper")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23347>
