These runners are configured to have a single job take up the whole
runner, which means we get to use threads to our hearts content. The pile
of cores means we don't need to spawn separate jobs to try to load-balance
across fdo's shared runner capacity. Having dedicated runners means we
won't get our MRs blocked as much waiting on non-Mesa testing happening on
fd.o.
We manage to complete all of this llvmpipe testing in about 6:15.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14962>
This check for geom shader needed to be expanded for tess support.
dEQP-VK.transform_feedback.simple.depth_clip_control_tese with lvp
Fixes: dacf8f5f5c ("draw: hook up final bits of tessellation")
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15128>
This callback is only intended for software rasterizers, layered drivers, and
other special drivers that go through the software winsys path. Remove the
unimplemented stubs from the Intel drivers.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Dave Airlie <airlied@redhat.com> [crocus]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15118>
Unify the exit paths to clean up the logic. There are logically three modes we
support (KMS without renderonly, KMS with renderonly, and FD); these each
correspond to a leg of a small if statement. Outside of the small if's,
everything else should be identical.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: James Jones <jajones@nvidia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15120>
When handle->type is WINSYS_HANDLE_TYPE_FD, the caller wants a file descriptor
for the BO backing the resource. We previously had two paths for this:
1. If rsrc->scanout is available, we prime the GEM handle from the KMS device
(rsrc->scanout->handle) to a file descriptor via the KMS device.
2. If rsrc->scanout is not available, we prime the GEM handle from the GPU
(bo->gem_handle) to a file descriptor via the GPU device.
In both cases, the caller passes in a resource (with BO) and expects out a file
descriptor. There are no direct GEM handles in the function signature; the
caller doesn't care which GEM handle we prime to get the file descriptor. In
principle, both paths produce the same file descriptor for the same BO, since
both GEM handles represent the same underlying resource (viewed from different
devices).
On grounds of redundancy alone, it makes sense to remove the rsrc->scanout path.
Why have a path that only works sometimes, when we have another path that works
always?
In fact, the issues with the rsrc->scanout path are deeper. rsrc->scanout is
populated by renderonly_create_gpu_import_for_resource, which does the
following:
1. Get a file descriptor for the resource by resource_get_handle with
WINSYS_HANDLE_TYPE_FD
2. Prime the file descriptor to a GEM handle via the KMS device.
Here comes strike number 2: in order to get a file descriptor via the KMS
device, we had to /already/ get a file descriptor via the GPU device. If we go
down the KMS device path, we effectively round trip:
GPU handle -> fd -> KMS handle -> fd
There is no good reason to do this; if everything works, the fd is the same in
each case. If everything works. If.
The lifetimes of the GPU handle and the KMS handle are not necessarily bound. In
principle, a resource can be created with scanout (constructing a KMS handle).
Then the KMS view can be destroyed (invalidating the GEM handle for the KMS
device), even though the underlying resource is still valid. Notice the GPU
handle is still valid; its lifetime is tied to the resource itself. Then a
caller can ask for the FD for the resource; as the resource is still valid, this
is sensible. Under the scanout path, we try to get the FD by priming the GEM
handle on the KMS device... but that GEM handle is no longer valid, causing the
PRIME ioctl to fail with ENOENT. On the other hand, if we primed the GPU GEM
handle, everything works as expected.
These edge cases are not theoretical; recent versions of Xwayland trigger this
ENOENT, causing issue #5758 on all Panfrost devices. As far as I can tell, no
other kmsro driver has this 'special' kmsro path; the only part of
resource_get_handle that needs special handling for kmsro is getting a KMS
handle.
Let's remove the broken, useless path, fix Xwayland, bring us in line with other
drivers, and delete some code.
Thank you for coming to my ted talk.
Closes: #5758
Fixes: 7da251fc72 ("panfrost: Check in sources for command stream")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-and-tested-by: Jan Palus <jpalus@fastmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: James Jones <jajones@nvidia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Tested-by: Dan Johansen <strit@manjaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15120>
There are always set to true. Don't pollute the driver code with them, make
their existence a local detail to pre-Valhall XML and that's it.
Functional change: "four components per vertex" is now set on vertex job DCDs.
This should be a no-op.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15123>
XeHP scratch space is handled differently. Commit ae18e1e707
implemented support for it, but handled it differently between render
and compute shaders: it calculates scratch_addr differently and
doesn't pin the buffer on compute. Make it work on compute shaders by
calling pin_scratch_space() from iris_compute_walker(), which fixes
both the address and the pinning.
This commit can be verified by the two-year-old-but-still-unreviewed
Piglit MR 234. You can also verify this by running a very simple
compute shader with INTEL_DEBUG=spill_fs.
References: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/234
Fixes: ae18e1e707 ("iris: Add support for scratch on XeHP")
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/15070>
I got confused while writing this somehow because of the null descriptor
feature, which enables drivers to consume a null descriptor, which has no
relation to a descriptor layout containing no descriptors
failing to accurately use zero descriptors can put layouts over the maximum
per-stage limits, which causes tests to crash
fixes (lavapipe):
KHR-GL46.shading_language_420pack.binding_uniform_block_array
KHR-GL46.multi_bind.dispatch_bind_buffers_base
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15067>
glWaitSemaphoreEXT triggers si_flush_resource callback
on pipe buffer resources, which may cause segmentation fault.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15098>
It was mistakenly added to indicate it's for a User-Mode Driver,
but all defined registers in Mesa are.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15098>
We need to setup internal_format for resource in case main surface was
not configured (iris_resource_configure_main) which is the case with
vertex buffer objects, otherwise transfer helper will make wrong
decisions when copying such a resource.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14925>
Application may exit without freeing created display list, this
may leave the cache not empty.
This is triggered by Abaqus which just close X11 display without
calling any of GLX cleanup functions like glXDestroyContext. But
GLX hook to X11 display close function to free GLX screen resource.
So display list as a context resource has not been freed, but
cache as a screen resource is freed.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14926>
DRI3 window back buffer is a client resource, so it's destroyed
when context switch drawable for native window.
But some application like Abaqus may leave a dirty back buffer
and reuse it when switch back. So add a driconf option for these
kind of app to keep the entire GLX drawable for native window.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14926>
We need to take ownership of shader keys before we can insert them into
the hash table. Caught by ASan.
==6343==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x00016bc51410 at pc 0x00010498d6cc bp 0x00016bc50240 sp 0x00016bc4f9d0
READ of size 592 at 0x00016bc51410 thread T0
#0 0x10498d6c8 in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long)+0x208 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x196c8)
#1 0x10498da08 in wrap_memcmp+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x19a08)
#2 0x10b7f3f18 in asahi_shader_key_equal agx_state.c:867
#3 0x10a482e7c in hash_table_search hash_table.c:325
#4 0x10b7f4e94 in agx_update_shader agx_state.c:899
#5 0x10b7f0dc4 in agx_draw_vbo agx_state.c:1590
#6 0x10a7c28c4 in u_vbuf_draw_vbo u_vbuf.c:1498
#7 0x10a5db03c in cso_multi_draw cso_context.c:1639
#8 0x10aed03d0 in _mesa_validated_drawrangeelements draw.c:1812
#9 0x10aed08d4 in _mesa_DrawElements draw.c:1945
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15109>
This removes the block at the end of fragment processing and allow
multiple scenes to be queued to the rasterizer up to MAX_SCENES.
Running heaven with this shows up to 39 scenes been allocated in the
first few renders, but it also removes all stalls in rendering until
the present stalls for completion. It reduces frame rendering times
(not enough to make it > 1 fps) but looks to be about 10% increase.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14923>
