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>
Move the handling to inside xe_exec_ioctl() and also rework things in
a way where we can tell from which caller the error is coming from.
v2:
- properly return VkResult (José).
- adjust the patch due to reordering the series.
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>
For now, this just simplifies checking for devinfo->no_hw, but we're
planning to add more code that everybody calling the XE_EXEC ioctl
will run.
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>
Every single caller does the same check.
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>
This is one of those places where we can very safely add
likely/unlikely.
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>
This check is for the command submission return.
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>
We were walking the instructions in the block for each
first-rpt-instruction in the block. Instead, on the first query per
block, make a set of all the rpts in the block, so we can O(1) check for
the remainder.
shader-db runtime for deadspace3 -7.60909% +/- 2.28996% (n=10) on a
debugoptimized build.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37625>
Android has to enable dumping globally. There's no per app based env
var at runtime since most apps just fork from Zygote process. So we have
to add process name to the dump file name. Now with pandecode.dump as
the base name, it'll be like below on Android:
- pandecode.dump.com.example.VkCube.ctx-*
- pandecode.dump.com.google.android.apps.nexuslauncher.ctx-*
This can be generally useful on Linux as well when debugging different
things to avoid accidentally touching existing dumps.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37729>
