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>
Renato Pereyra
Mike Blumenkrantz
Danylo Piliaiev
Charles Giessen
Dave Airlie
Tapani Pälli
Emma Anholt
Guilherme Gallo