Move mesh URB allocations together with the other stages.
This fixes a hang that started happening with mesh enabled after
419531c5d9 ("intel/blorp: add a new flag to communicate PSS sync need")
Bspec 45352 says:
L3 Space allocation can only be changed when the GPU pipeline is
completely flushed.
It's likely that the PIPE_CONTROL added in that commit was breaking that
assumption and the URB allocation happening afterwards at the end of the
pipeline emission would then hang. And before that, we were probably
just getting lucky.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25047>
This adds support for calling functions in compute shaders.
Functions are passed two implicit arguments
- the current exec mask
- a context containing all the info needed for intrinsics to work
when not in the toplevel.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24687>
This adds a driver control to instruct NIR to not inline
all functions.
It adds a very simple inlining heuristic that works for
what I've played with, but will probably need to grow some
better ideas.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24687>
This allows a function implementation to be targetted, this will
only be used by the compute shader paths, so keep a compat path
for all the others.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24687>
Don't inline linked functions here, let nir_inline_functions do the job
when we get to it.
Instead just copy over the implementation and any other pieces need.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24687>
Sadly we cannot autogenerate handling for them, so fall back to hand
written handling instead.
Fixes: eaee792 ("vulkan: Add a generated vk_properties struct")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25055>
Note, gl_SamplePosition (rgetpos), and therefore interpolateAtSample(),
doesn't work with sample location_enable=true. For vulkan, "If the
current pipeline uses custom sample locations the value of any variable
decorated with the SamplePosition built-in decoration is undefined."
But ARB_sample_positions doesn't mention this. Possibly the vk text
should be backported to the gl extension. (If the app is specifying the
sample locations, it shouldn't need gl_SamplePosition.)
The upshot of this is 2 out of 3 tests that piglit arb_sample_locations
test tests fail, even though sample locations itself is working.
Possibly the test should be updated. Or we could use driconf to hide
ARB_gpu_shader5 and ARB_sample_shading from this test.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24999>
Using the default value leads to occasional hangs on RV516 for unknown
reasons. Set it to 128 insted of 255.
dEQP and piglit are still happy and I don't expect any real app to hit
this, but lets see. As a side effect this boosts fps in the apps that
have non-unrollable vertex shaders (as the shaders now effectivelly run
almost two times faster) and ~5% dEQP runtime decrease.
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7934
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20873>
We don't fill batch_len later when chaining batches. But that doesn't
seem to be a problem, I checked i915.ko and nothing Gen8+ seems to use
batch_len. The new xe.ko exec ioctl doesn't even ask for batch_len.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24681>
Don't hide failures, we have xe.ko bugs related to that, such as:
https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/496
The bind ioctl may fail if the application does something wrong, but
the wait really should never fail.
v2: Don't print an error message (Lionel).
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24681>
Our sparse implementation will require us to issue partial unbinds,
but partial unbinds are not supported in synchronous vm_bind ioctls,
requiring us to to have our VM be marked with the ASYNC flag. This is
not properly documented and is subject to change in the next
iterations of the API.
Error handling with async binds is also not documented anywhere and is
being actively discussed in the mailing lists, so whatever we decide
to implement here is likely to end up changing in a few weeks. Also, I
haven't seen these errors happening in the real world, so for now
they're a very corner case. So for now just foward errors to
user-space and hope things work.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24681>
For Sparse Resources we need to be able to specify the address, size
and offsets and we also want to be able to issue multiple binds at the
same time. Extend xe_vm_bind_op() to handle those cases and add
the new vfunc.
v2:
- use STACK_ARRAY() (Lionel)
- no more need to work around xe.ko bug that was fixed (José)
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24681>
The only driver that has a vm_bind ioctl is xe.ko, and its vm_bind
ioctl is not called GEM vm_bind, it's just DRM_IOCTL_XE_VM_BIND
(without GEM anywhere). Back when i915.ko was going to have a vm_bind
ioctl it had GEM on its name, so I guess that's how "gem" appeared in
the naming here, but now nothing does, so let's get rid of it.
Also, these vfuncs we have are specifically made to bind and unbind
whole BOs, so rename them to vm_bind_bo() and vm_unbind_bo() in order
to try to clarify what they mean. The goal is to add a more generic
vm_bind() later that can do anything.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
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/24681>
