Those are required on Turing+ to handle cross thread synchronization and
other goodies as the c/r stack is gone.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11061>
Replaces some FILE_ADDRESS with LAST_REGISTER_FILE and makes RA not choke
on instructions using TS values.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11061>
Zink uses this, as it doesn't need to differentiate all the entrypoints.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11045>
Set st_rps_bits in hevc message buffer and set corresponding flag to indicate
that st_rps_bits will be used for parsing the short_term_ref_pic_set structure.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10889>
vdpau interface doesn't provide st_rps_bits, it uses NumDeltaPocsOfRefRpsIdx
instead. So disabling the flag to indicate st_rps_bits will not be used.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10889>
Get st_rps_bits from VAPictureParameterBufferHEVC, and set the flag that
indicates st_rps_bits will be used for parsing the short_term_ref_pic_set
structure
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10889>
st_rps_bits is used for accelorater to skip parsing the short_term_ref_pic_set
structure, which is needed for HEVC decode.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10889>
When drawing using util_translate_prim_restart_ib, zink explicitly
ignores pipe_draw_start_count_bias::start, because
util_translate_prim_restart_ib used to create a new index-buffer without
padding at the start.
This makes a lot of sense, because creating a padded index buffer is
just wasteful.
So let's walk back on the choice of starting to pad the output buffer.
Fixes: 1272c2e052 ("util/prim_restart: fix util_translate_prim_restart_ib")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4851
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11059>
OpenGL allows reinterpreting 2D array textures as cubemaps,
so we need to always set the cube-compatible flag for them.
This fixes a piglit test on Lavapipe.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10913>
We need to check if the number of samples are valid for the image
first if we've going to set the cube-compatible bit.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10913>
Now that we handle the cubemap-array views properly, we no longer need
to do this. It's allowed in Gallium to create cubemap views of 2d
arrays, so this should work fine.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10913>
Spec requires apps to use the size returned from
vkGetAndroidHardwareBufferPropertiesANDROID for AHB import, which
includes dedicated image/buffer import and non-dedicated buffer import.
Spec requires venus to use the size from image and buffer memory
requirement for dma_buf fd import if it's dedicated. If not dedicated,
the actual payload size should be used.
For AHB export allocation of VkImage, the app provided size will be 0,
and internally we must use the size from image memory requirement.
For AHB export allocation of VkBuffer, the app provided size comes from
buffer memory requirements and it can be smaller than the actual AHB
size due to page alignment. Internally that's the size we must use.
For AHB import, app must use the size from AHB prop query. Internally,
we have to override that with the size from memory requirement if the
import operation is dedicated to a VkImage or a VkBuffer. If not
dedicated, the actual payload size should be used.
The not working scenario is:
1. App creates an AHB backed VkBuffer, and the exported AHB size is
larger than the buffer memory requirement (very common).
2. App imports the AHB without a dedicated VkBuffer. Then the entire
AHB payload will be imported and the mmap_size might increase.
Test: dEQP-VK.api.external.memory.android_hardware_buffer.*
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11055>
For importing an dma_buf fd, export info is not required. Leaving the
bo_flags missing VIRTGPU_BLOB_FLAG_USE_SHAREABLE bit as well as the
VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE bit. Upon querying fd properties,
DMA_BUF handle type will be specified which generates a new bo_flags
not matching the prior one.
This patch aligns the above 2 bits for the dma_buf import path.
Test: vkGetAndroidHardwareBufferPropertiesANDROID should succeed with
a valid AHB with AHARDWAREBUFFER_FORMAT_BLOB format.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11055>
