when discarding the whole resource on an unused resource, we can deinit the buffer
range here
in the future, ideally we should be doing something like creating a new vk buffer/image
entirely here and demoting the existing one to a queue that destroys/caches it when
the batch finishes in order to avoid fencing
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
we don't actually have to stall here, we just have to make sure the cs batch
is submitted before the subsequent buffer copy command goes into a gfx
batch in order to preserve the ordering
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
if we need to sync a resource for read-only mapping, we only need to wait on
the fence that was last flagged as having writes to the resource, not batches
that may have reads, as reads don't affect memory coherency
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
this now takes over from previous call sites in zink_transfer_unmap
we add a flush here if we had pending usage to ensure that the resource
gets properly synced
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
this simplifies the barrier helper callsites as we no longer need
to check whether a barrier is needed beforehand in order to avoid potentially
ending a renderpass too early
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9205>
This means less custom test-source-dep stuff for these drivers, though it
means that touching the CI expects files will cause a bit more retesting:
- broadcom drivers retest as a group (but Igalia requested that
organization of CI files)
- radv+radeonsi retest as a group
- lvp+llvmpipe retest as a group
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9161>
If a query is made of a vector ssa_def (possibly from an intermediate
result), return all_bits. If a constant source is a vector, swizzle
the correct component.
Unit tests were added for the constant vector cases. I don't see a
great way to make unit tests for the other cases.
v2: Add a FINIHSME comment about u16vec2 hardware.
Fixes: 96303a59ea ("nir: Add some range analysis for used bits")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9123>
Once the extension fix is merged the CI results change appreciably.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9185>
The code was using the core versions, but for vulkan 1.0 at
least the extension versions are what is required to be asked for.
This fixes zink loading on lavapipe, and blows up the CI.
v2: Use LOCAL device extension variant (zmike)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9185>
Before we introduced the submission thread in 829699ba63, once we
returned from vkQueueSubmit, all signaled syncobj would have a
i915_request/dma-fence waiting to be signaled by some work that would
submitted to HW by i915.
After this submission thread that is no longer the case. We added a
few checks in places like vkQueuePresentKHR() to wait for the binary
semaphores to materialize before we would hand things over to the WSI
code.
Unfortunately 829699ba63 forgot to reset the signaled binary
semaphore.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 829699ba63 ("anv: implement shareable timeline semaphores")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4276
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9188>
When mesa gets a DRI2 1.1 connection (as experienced with
vmwware DDX) we don't get a pointer for this.
Don't explode just keep going.
Fixes: 60ebeb4608 ("glx: Implement GLX_EXT_swap_control for DRI2 and DRI3")
Reviewed-by: Adam Jackson <ajaX@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9184>
On top of the last kernel tree I added a couple of DT changes for db820c
from the qcom landing tree necessary for bringing up the GPU, and a fix to
my OOB cleanups fro cheza. I also enabled the CPU clock driver for db820c
so we can turn on SMP and not leave jobs stranded on a 19Mhz CPU or whatever.
This causes us to need a bit of updating of our TF expectations since the
order of jobs changes a bit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9144>
I missed this regression in the "start using Xorg" branch since the piglit
runs are manual. I made the piglit runs accidentally require a core
context, which a5xx can't do (it's only GL 3.1).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9144>
Per discussion with Daniel Schürmann on IRC about the joys of SSA form
and why you don't actually need use-def chains. Indeed, I didn't. No
shader-db changes, time difference in shader-db is neglible since the
win from this is particularly for large shaders.
Total runtime of
dEQP-GLES31.functional.ssbo.layout.single_struct_array.single_buffer.std430_instance_array
reduced from 1.04s to 0.77s (25%)
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9164>
If there are no destinations, don't produce a _to version, and let the
bare version return the bi_instr.
If there are multiple destinations, take each in the _to version and
don't produce a bare version.
Both cares are probably what you wanted anyway.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9164>
Assuming it's only the first destination breaks assumptions across the
compiler. Add a destination source and fix up the many corresponding
issues. Nothing to backport as far as I understand since multidest
instruction are new.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9164>
Only used in one place (and should never be used elsewhere -- even this
use is questionable). By inlining we avoid O(N^2) behaviour on the
number of sources in liveness updates.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9164>
Fixes excessive (and failing) spilling in dEQP-GLES31.functional.ssbo.layout.*
shader-db results are a toss up (I suspect we'd see better results if we
tracked register pressure directly):
total instructions in shared programs: 161377 -> 161377 (0.00%)
total nops in shared programs: 121159 -> 121203 (0.04%)
nops in affected programs: 1839 -> 1883 (2.39%)
Nops are HURT.
total clauses in shared programs: 31604 -> 31606 (<.01%)
clauses in affected programs: 38 -> 40 (5.26%)
Inconclusive result (value mean confidence interval includes 0).
total quadwords in shared programs: 130847 -> 130845 (<.01%)
quadwords in affected programs: 1246 -> 1244 (-0.16%)
Inconclusive result (value mean confidence interval includes 0).
total loops in shared programs: 18 -> 18 (0.00%)
total spills in shared programs: 705 -> 705 (0.00%)
total fills in shared programs: 1645 -> 1645 (0.00%)
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9164>
We don't support it yet.
Fixes: 61d3ae6e0b ("panfrost: Initial stub for Panfrost driver")
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9164>
