No need to call it at the end of every block, since we already
know and identified the blocks terminating with returns.
Suggested by Jason Ekstrand.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18442>
glslang had a bug and didn't actually emit it as a terminating
instruction, therefore this went unnoticed thus far. See
https://github.com/KhronosGroup/glslang/issues/3020.
Modified by Caio Oliveira to emit the corresponding NIR intrinsic
right before the halt.
Fixes: 7d1bcf1f55 ("spirv, nir: Handle EmitMeshTasksEXT opcode.")
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18442>
This will be used later to handle branches instructions that have
parameters in them, e.g. SpvOpEmitMeshTasksEXT. No behavior change in
this commit.
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18442>
The check in d3d12_has_video_encode_support was returning no encode support unless
the driver supported D3D12_VIDEO_ENCODER_FRAME_SUBREGION_LAYOUT_MODE_UNIFORM_PARTITIONING_SUBREGIONS_PER_FRAME
when it should also return support when the driver reports only full frame support
(ie. D3D12_VIDEO_ENCODER_FRAME_SUBREGION_LAYOUT_MODE_FULL_FRAME)
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18763>
instead of incurring all the overhead of tracking lifetimes for these,
it makes more sense to just let them delete whenever and then store
the vk object onto its parent image/buffer to be deleted when that gets
freed, as the parent object's lifetime will always be >= the view's lifetime
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18664>
this uses a revised version of radeonsi's buffer list array to track
resources for lifetime/usage management, massively improving performance
by avoiding hash table lookups
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18664>
previously this would no-op unacquired swapchains and then try to
execute a copy from the last-presented swapchain image to the current
image to avoid presenting garbage data
instead, just present garbage like the app requested
fixes#7165
Tested-By: Matti Hamalainen <ccr@tnsp.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18730>
I noticed that glmark2's glFinish()es in its offscreen rendering tests
under zink were spinning. When we passed -1 as the timeout for
drmSyncobjWait(), the kernel would immediately return ETIME.
Fixes: 0a82a26a18 ("turnip: Porting to common implementation for timeline semaphore")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18739>
return VA_STATUS_ERROR_TIMEDOUT;
| ^~~~~~~~~~~~~~~~~~~~~~~~
| VA_STATUS_ERROR_UNKNOWN
../src/gallium/frontends/va/buffer.c:434:14: note: each undeclared identifier is reported only once for each function it appears in
../src/gallium/frontends/va/buffer.c:436:22: error: ‘VA_TIMEOUT_INFINITE’ undeclared (first use in this function); did you mean ‘PIPE_TIMEOUT_INFINITE’?
436 | if (timeout_ns != VA_TIMEOUT_INFINITE)
| ^~~~~~~~~~~~~~~~~~~
| PIPE_TIMEOUT_INFINITE
Fixes: 229c6f79a ("frontends/va: Implement vaSyncBuffer")
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18760>
So using the same buffer for CPU writes and GPU writes might be kinda
unusual. But I noticed we were missing handling for the case while
debugging something unrelated.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18732>
