The way this workaround is implemented, it is being applied to all
gfx 12 platforms(TGL, ADL, RKL, RPL, DG1, DG2 and MTL) but it was
supposed to be fixed in TGL B0.
Unfortunately I did not found any workaround number that would match it.
But as all released platforms don't ship to customers with revision == 0
this workaround was never being applied and can be safely removed.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24699>
Generated mostly with sed:
sed -i -e 's/live_ssa_def/live_def/g' src/compiler/nir/nir.h src/compiler/nir/*.c
Plus three fixups in various Intel drivers.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24703>
We already renamed the type, we just need to rename the enum and the
casting helper functions.
Generated with sed:
sed -i -e 's/nir_instr_type_ssa_undef/nir_instr_type_undef/g' src/**/*.h src/**/*.c src/**/*.cpp
sed -i -e 's/nir_instr_as_ssa_undef/nir_instr_as_undef/g' src/**/*.h src/**/*.c src/**/*.cpp
and two tiny whitespace fixups in lima.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24703>
this is tricky because drivers are exposing their native support, but
that support may not fit the specific needs of the format
as such, (almost) every use of format where alpha emulation workarounds are
present now need to add a second layer of workarounds in order to handle
the case of possibly-genuine A8 (which might also be emulated A8 even if
the driver supports A8 for some things)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24685>
...when trying to ignore components. Trim functionality with nir_ssa_for_src is
deprecated.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24654>
Now that the stride is in the CSO, there's no merging needed at draw-time. The
whole descriptor could probably be uploaded at CSO create time but I didn't want
to deal with that right now, this isn't even my driver anymore I just like
deleting code.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24680>
According to the GL3 spec, only the `CLAMP` mode was deprecated,
the `CLAMP_TO_EDGE` and `CLAMP_TO_BORDER_ARB` are not, so this
extension should be advertised.
As a side note, Davinci Resolve uses a Core profile and tests for
that extension so it fixes an issue with that app.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24660>
this runs io lowering on shader create, which is a huge pita
and waste of time since it requires then re-creating all the deref io later,
but it also makes the variables simpler by eliminating struct awfulness
(which was already eliminated by the split_blocks pass, but who's keeping
track) and will enable future use of some bizarro inter-stage linker thing
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24634>
LLVM does something similar: https://reviews.llvm.org/D153295
fossil-db (gfx1100):
Totals from 21 (0.02% of 133461) affected shaders:
Instrs: 147428 -> 147396 (-0.02%)
CodeSize: 797188 -> 797060 (-0.02%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 2930317cea ("aco/gfx11: deallocate VGPRs at the end of the shader")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24669>
The names basically had the same meaning. Changing them to
uniform_shader_addr and shader_addr makes it clear, that
uniform_shader_addr is the jump target and shader_addr is the next
shader executed by this invocation.
The next_ prefix is dropped since both are input and output variables.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23565>
Partial revert of e516a0a94f ("egl: disable partial redraw when gallium
hud is active").
We shouldn't change the behavior of the application when the hud is
enabled, doing so could make it harder do diagnose issues. Instead, now
we warn and ask the user to manually disable the extension if he
considers it to be worth it.
Fixes: e516a0a94f ("egl: disable partial redraw when gallium hud is active")
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23456>
Fix defect reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable text_data going out of scope leaks the storage it points to.
Fixes: b4c8d2dc45 ("intel/decoder: Add intel_spec_load_common()")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24659>
I originally used CWE for this case since it nicely avoids a lot of the
"complex" operations while still disabling most effects of a fragment shader
in theory, however, there are some cases where CWE isn't quite the same as actually
disabling the fs, so this adds a new rast-discard mode that can be used for
those cases
it can also be used instead of the dummy surface handling that was previously
used for drivers/hw that didn't support primitivesGeneratedQueryWithRasterizerDiscard,
which enables a bunch of gross conditionals to be simplified
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24676>
They were being translated to YUYV and UYVY formats which, in
PIPE_FORMAT parlance, are auto-converted formats, not raw data
formats. Use the raw data formats like everything else.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619>
VK_FORMAT_G8B8G8R8_422_UNORM and VK_FORMAT_B8G8R8G8_422_UNORM already
place the luminance channel in the green component which is where we NIR
lowering code for ycbcr expects it. Set an RGBA swizzle in the common
format table and make it the driver's responsibility to re-map the
formats as needed for their hardware.
The only Vulkan drivers affected by this change are the Intel drivers
and lavapipe. None of NVK, RADV, and v3dv support these formats yet and
Turnip has its own lowering that doesn't rely on the YCbCr format table
in util/vk_format.c.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619>
We're about to start using YCRCB_NORMAL and YCRCB_SWAPUV for 8-bit
interleaved YCbCr and, while ISL claims CCS_E support, it's not well
tested and we don't think it's working yet for all of ANV's use-cases.
Disable it for now in ANV and only for YUV formats.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619>
BLORP uses the get_ccs_compatible_copy_format() based on whether or not
ISL claims the format supports CCS_E, not whether or not CCS_E is used
on the image. This is probably a good thing as it improves consistency.
However, it means that we need CCS-compatible formats for YCRCB_*
formats even if we never use them with CCS_E enabled. In practice,
these do actually seem to work according to the Vulkan CTS but coverage
is likely far less than perfect.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619>
These actually match the Vulkan format enums for single-plane YCbCr
formats, unlike the other PIPE_FORMAT_* enums which put luminance in the
red channel.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619>
Without this, gallivm doesn't know what to do with the result data of a
texture fetch. We have a bunch of gallivm code to handle these but, as
far as I can tell, none of it works properly without channel types. The
YUYV texturing helpers all consume a 32-bit packed value, unpack it,
shuffle things as needed, and then re-pack into a 32-bit RGBA value,
trusting later code to unpack that as 8-bit UNORM. For the raw formats,
this unpacking never happens.
What saves us is that I also don't think any of this code is ever used.
LLVMpipe supports the actual YUYV formats and we don't use the gallium
lowering pass which lowers to the raw formats.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619>
