This was identified by Coverity. 4bb9c0a28a added uses of a third
address register, but the arrays for tracking address registers only
have two slots.
Add back a version of the assertion from before 4bb9c0a28a to help
prevent future problems. I don't think any drivers that would hit
this path use NIR-to-TGSI yet, so it may be moot.
Reviewed-by: Matt Turner <mattst88@gmail.com>
CID: 1496942
CID: 1496944
Fixes: 4bb9c0a28a ("nir_to_tgsi: Use the same address reg mappings as GLSL-to-TGSI did.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14487>
It's not obvious why the (gl_FrontFacing ? -1.0 : 1.0) case was handled
different for Gfx12+ than for previous generations, and it's not
correct. It tries to negate the result as an integer, and it does this
before the mask operation that clears the other bits in the value.
When we eventually support dual-SIMD8 dispatch, the other front-facing
bit is in g1.6 at bit 15, so similar code should be possible there.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes: c92fb60007 ("intel/fs/gen12: Implement gl_FrontFacing on gen12+.")
Closes: #5876
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14625>
drivers/hardware lacking VK_EXT_image_drm_format_modifier can still use dmabuf,
but that setup has to do the old copy to linear scanout instead of copy to
modifier scanout
this requires a couple extra checks to be added to handle the case
Fixes: 619438bf7ce ("zink: check EXT_image_drm_format_modifier for dmabuf support")
fixes#5836
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14597>
AUX and clear state is stored in the VkDevice private binding
Signed-off-by: Renato Pereyra <renatopereyra@google.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14416>
there is no vulkan driver that can currently pass all these tests, and
some of the tests themselves are broken, but this seems like it should be
correct
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
basically just allocate pages for miptail levels (probably just one) and
then bind them separately since they're probably never going to be batched
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
this one's a bit tricky since vulkan doesn't support vec5, the return from
the instructions is a struct, and I don't want to add temp var support to zink
now instead the process for these ops is:
* rewrite the is_sparse_texels_resident instruction to read the first vec member of the texop
* (temporarily) decrement num_components for sparse texop's dest to get real result size
* wrap texop's return type in spirv-required struct(uint, result)
* unwrap struct, store result normally + store residency info to separate array
* for is_sparse_texels_resident, ignore the mov alu for src[0] and instead use the ssa index
from the parent instr since this is the original texop that was used to store the residency result
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
this automatically wraps the results into the required struct(int, result) type,
handling will come next
note that there is no cts coverage for sparseImageLoadARB, so this is purely
hypothetical
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
these just allocate the whole thing now, which means they aren't actually
sparse, but who cares because nobody but cts is actually going to use it
and those tests pass just fine
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
this would allocate a new stream uploader for every map if the offset was
large (e.g., all sparse buffer usage), which almost immediately consumes all vram
cc: mesa-stable
fixes KHR-GL46.CommonBugs.CommonBug_SparseBuffersWithCopyOps
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
this is now symmetrical since the backing memory was being cached,
and there's no reason not to allow this since memory is no longer in use
by the time it gets returned to the cache
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
this is a bit duplicated because the buffer and image commit code is
a little shared but not enough to combine without becoming spaghetti
this will only get worse once multisampling is supported
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14381>
With the proper version checking in the common vulkan instance code
(commit 88b9b68) it is now possible to bring the reported interface
version up to v5.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563>
With the proper version checking in the common vulkan instance code
(commit 88b9b68) it is now possible to bring the reported interface
version up to v5.
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563>
With the proper version checking in the common vulkan instance code
(commit 88b9b68) it is now possible to bring the reported interface
version up to v5.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563>
With the proper version checking in the common vulkan instance code
(commit 88b9b68) it is now possible to bring the reported interface
version up to v5.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563>
With the proper version checking in the common vulkan instance code
(commit 88b9b68) it is now possible to bring the reported interface
version up to v5.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563>
With the proper version checking in the common vulkan instance code
(commit 88b9b68) it is now possible to bring the reported interface
version up to v5.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563>
as intel perf is a big impact, start building the intel subdir
earlier so there is less chance of long stalls at the end waiting
for one file to link other things.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14630>
This cuts the compile time down for this file on my ryzen from
real 1m4.077s
to
real 0m30.827s
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14630>
Dave Airlie
Mike Blumenkrantz
Ian Romanick
Rhys Perry
Renato Pereyra
Danylo Piliaiev
Charles Giessen