Although this isn't technically required by the Vulkan spec, a few
native Vulkan games including DOOM Eternal expect it to be supported
because Windows drivers all support it. Now that support has been
plumbed through in the kernel backend, expose the ability to submit
sparse binds on the graphics queue that are implicitly synchronized with
graphics commands.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37304>
Create an extra sparse queue when creating a graphics queue, and send
sparse binds to that queue. Synchronize graphics commands against sparse
binds and vice versa using a pair of timeline semaphores.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37304>
Vulkan 1.0 conformance has happened on BXS-4-64, but not on other GPUs
or Vulkan versions using an upstream version of the driver. So let's
update the phrasing to include this.
And since we actually expose Vulkan 1.2 now (see next commit), let's
untangle the conformance information from the GPUs support table; this
way nobody should be confused and think we're conformant to Vulkan 1.2,
when we're not (yet).
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37678>
This driver landed after the move to ld_args_build_id, so it never got
converted over. Let's make sure it's testing for the feature support
rather than just assuming it's there.
Acked-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37393>
This also includes support for the new job cookie system, verifying that jobs
running originate from the claimed source. This is useful internally but won't
affect users, unlike the feature in the title :)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37609>
All the compiler support was implemented as part of the v3dv
implementation (see commit 31e8740808 and MR#27211).
We are using the same size/supported_stages and mostly the same
supported features, so probably at some point it would be good to have
a common place for that info. Zink reuses their definitions, but as
far as I see it does that because the PIPE and equivalent VK
definitions has the same values, that seems somewhat fragile.
We don't support all features, and in order to support arithmetic we
need to enable a lowering.
Using CTS, right now we are passing 1023 tests out of 6053 (the rest
are skipped).
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37621>
The kernel driver zero initialises device memory allocations for us, so all that
needs to be done is to advertise support for the extension.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37732>
In general, the debug flags are served once per proc invocation. So we
can make panvk debug flags global and clean up the existing codes in the
next change. Meanwhile, this changes improves branch prediction on user
builds and logs the enabled debug options when startup is used.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37752>
Fix defect reported by Coverity Scan.
Evaluation order violation (EVALUATION_ORDER)
write_write_typo:
In ret = ret = ({...; drmIoctl(panfrost_device_fd(dev), 3221775434UL, &args);}),
ret is written twice with the same value.
Fixes: e9aedfe508 ("panfrost: Support JM context creation and destruction")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37708>
These registers are shared between BR and BV. This means they can only
be written in BV or in BR during a special "disable binning" section
which synchronizes BR and BV. The register stomping infrastructure isn't
aware of this, so disable stomping for VSC.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37722>
The HW bug was fixed on Xe2, report so accordingly.
Can test behavior with dEQP-VK.fragment_operations.early_fragment.*_maintenance5
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37730>
Add the common magic numbers in a header file and make the functions
use them.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
When the system is under memory pressure (which can happen, for
example, during CI runs), don't immediately give up the exec ioctl
(which, for Vulkan, will result in the device being declared lost).
Instead, retry a little bit just like we do for i915.ko.
This is a trade-off.
One of the reasons to *not* have unified behavior regarding ENOMEM
between i915.ko and xe.ko is the fact that xe.ko uses vm_bind, so if
the user tried to bind more memory than it is able to, we'll just keep
getting ENOMEM as long as we retry the ioctl. We now have a retry
limit, so we'll eventually return the error.
On the other hand, if the problem is other applications consuming all
the memory, having the retry loop may really help avoid unnecessarily
marking the device as lost, since one of our retries may eventually
succeed.
I believe the tradeoff of "we'll now eventually succeed in some cases
where it's possible to succeed, at the expense of retrying for a few
seconds until giving up in cases where we would never be able to
succeed" is an improvement.
If xe.ko ever gives us a way to differentiate between the two
different reasons for ENOMEM, we'll be able to make things much
better. We can also tune our timeouts if needed.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
By this point, the user may have noticed their game is not drawing any
new frames, so perhaps an error message might help.
This would also, of course, help identifying ENOMEM problems in our CI
runs.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
If nothing has freed memory until that point, return the error, which
may make the upper layers report the device as lost. It could be that
the system is under very very heavy swapping and that waiting a little
more would make it work, but let's try 16s for now.
v2: Bring down the timeout from ~60s to ~16s (José).
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
If the ioctl is returning ENOMEM, incessantly retrying does not seem
to be the best way to proceed. After the second retry, sleep 0.1ms,
then more each time, giving the CPU some time to run the other threads
and processes, in the hope that whatever is eating all the memory
might eventually return it.
If the problem is the current thread, then busy looping won't help
either, so here we at least save some power before the user kills the
app.
v2: Adjust the control flow and the sleep time.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
Unify the common code for i915.ko execbuf submission between Iris and
Anv. I plan to add more code to this function in the next patches.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
Don't check something that will never be there, just assert() it.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
The i915.ko backend calls vk_queue_set_lost(), let's unify behavior.
v2: Adjust patch due to series reordering.
Reviewed-by: Rohan Garg <rohan.garg@intel.com> (v1)
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
Move the handling to inside anv_gem_execbuffer(), and also rework
things in a way where we can tell from which caller the error is
coming from.
v2: properly return VkResult (José).
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37559>
