It only caused some optimized shader variants to not be compiled in very
rare cases. I think it doesn't happen in practice, but if it does, it's
not a big deal.
The case when this was useful was when a shader wrote (0,0,0,0) or
(0,0,0,1) or (1,1,1,0, or (1,1,1,1) to a shader output before PS,
but PS didn't use the output.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35392>
This gives descriptors a consistent base address and lets us stop doing
the memory reference counting dance for queue state management. We
still need to track sizes so that the GPU doesn't read outside the arena
but that's a lot simpler.
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35327>
The only material change here is that we're now allocating slightly less
memory every time in the non-contiguous case. Instead of allocating a
power of two plus the over-allocation so our total usable space is a
power of two, we now allocate a power of two and just let the over-
allocation burn space.
This also reworks the internal vma_heap to use actual addresses instead
of the index+offset packed things. This costs us a tiny bit more
looking up the map in alloc() but we save it again on free so there's no
real loss here.
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35327>
This is about 80% of what nvk_heap does today but with the explicit goal
of just pulling out the growable memory arena part out and separating
all of the heap logic.
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35327>
Source: BSpec "Instruction Fields" page (56701), SWSB field.
Credits to Caio Oliveira here, since he was helping me while we found
this issue together.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35395>
This was an oversight when BitSet was parameterized on a key type.
BitSetStream needs to also take a key type to prevent users from mixing
different key types in binary operators. Constraining this makes BitSet
usage more type safe.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35328>
This adds the VP9 decoding support.
This was initially developed by me,
Stéphane Cerveau from Igalia did a bunch of fixes and testing,
Benjamin Cheng from AMD also helped with a few fixes and how
to program the firmware better.
This passes the current VK-GL-CTS tests.
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35398>
This will be reused by radv eventually, so let's move it all
over to common code. It might have other users eventually,
but we can worry about that later.
Reviewed-by: David Rosca <david.rosca@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35398>
Simplify transition_depth_buffer() by reusing a function to update the
fast-clear value instead of open-coding that logic.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35329>
There were a couple issues in iris_resource_prepare_render():
* It previously assumed that the sampler would always look at the raw
dwords for 32bpc formats. However, the sampler only does this on
gfx12.0 for R32 formats (not RG32 formats for example). Update the
comments to reflect this.
* It only initialized the clear color if the render_format was
non-32bpc. However, initialization is still needed outside of this
case because a subsequent sampling operation may use a view format
which looks at the sampler field. Check for the FCV aux-usage instead
of the render format's number of bits-per-channel to fix this.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35329>
Use isl_get_sampler_clear_field_offset() to more accurately determine
when the sampler will change the field it reads from on gfx11-12. This
avoids partial resolving in a number of cases.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35329>
Use get_copy_format_for_bpb() instead of
get_ccs_compatible_uint_format() when performing blorp_copy(). This
matches the code path taken on gfx20 and increases the testing of cases
which would impact gfx12.0 in isl_get_sampler_clear_field_offset().
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35329>
Through testing, I've found that the sampler will fetch the clear color
pixel from the converted clear color field in more cases. So, stop
reporting the raw dword offset for them:
* On gfx12.5, for 32-bpc color images.
* On gfx11-12.0, for 64-bpp color images.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35329>
The AFBC path is behind a driconf option, and so was not tested by any
existing CI jobs. We had a regression with this that went unnoticed for
several months. To avoid similar situations in the future, add AFBC
smoke tests to CI, similar to the existing spilling smoke tests..
Some tests on g52 fail instead of crashing when AFBC is enabled, but
otherwise the CI expectations are identical.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35193>
