Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 2eaa437574 ("panvk: Use memory pools for internal GPU data attached to vulkan objects")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29783>
This fix failure on "dEQP-VK.api.buffer.basic.size_max_uint64".
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 822478ec20 ("panvk: Move the VkBuffer logic to its own source file")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29783>
Contribute to fixing "dEQP-VK.api.object_management.alloc_callback_fail.device".
We needs a way to report errors in mempools.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29783>
When pan_blend_shader_key_table_create was failing, we weren't
destroying the mutex and panvk_pool.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29783>
Fix a crash when a null handle is passed.
(dEQP-VK.api.null_handle.destroy_command_pool)
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: afbac1af77 ("panvk: Move the VkCommandPool logic to panvk_cmd_pool.{c,h}")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29783>
CTS tests both layered and separate DPB, but radv wasn't handling
layered properly when used with the tier 2 dpb handling.
This adjusts the addresses to use the layer index for tier2.
Fixes dEQP-VK.video.decode.*layered*
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29758>
There's no good reason for this to be header-only besides laziness on my
part when I first wrote a few "small" helpers. Some of those are pretty
good sized and don't need to be inlined.
Keeping the original copyright since this is just moving code.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
As long as drivers implement an fmin/fmax that do the right thing with
NaN, there's no reason for the integer comparison.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
I have no idea why I flipped the order of these to checks vs. the C
code when I wrote the NIR helper. We need to deal with NaN first or
else the fmin will smash NaN to MAX_RGB9E5 and it won't get handled as
NaN.
Fixes: 9981709d8f ("nir/format_convert: Add a function to pack RGB9_E5 formats")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
The spec allows denormals and the R11G11B20F decoder handles them but
the encoder always flushes them to zero. We should be consistent and
handle denorms going both directions.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
Previously, [SU]SCALED formats would hit the integer path and we would
generate:
((uint32_t)CLAMP(src[i], min, max)) & MASK
This is fine for unsigned scaled formats. However, for signed formats,
a negative float value cast to an unsigned integer yields undefined
results. On x86, it implicitly clamps to 0. This change makes us
generate:
((uint32_t)(int32_t)CLAMP(src[i], min, max)) & MASK
hich gets us correct casting.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
Change so the size rounds up to the next multiple of the horizontal stride like
is done for VGRF. This was causing an inconsistency in regs_read() -- The original
component_size() calculation for FIXED_GRF excluded any padding at the end but it was
still being discounted by regs_read().
Suggested by Curro.
Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11069
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29736>
Completely skip the stall & programming if the bindless address has
not changed. Only on Gfx12.5+ since previous generations also program
the binding table pool base address through STATE_BASE_ADDRESS.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29595>
In a following change the predicate registers might be used when
flushing the state.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29595>
The mi-builder already takes care of mi write/read fences, but we have
a few cases in Anv where we also need to fence mi-write ->
shader-read.
We also have one case where a command buffer jump address is modified
by a previous mi write command.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29595>
The ioctl DRM_VMW_SYNCCPU may sometimes fail with ERESTART or EBUSY, which
in turn bubbles up to the application as a GL_OUT_OF_MEMORY error.
We are seeing this in glamor, while this does not cause any real issues, it
does pollute the system log.
Retrying DRM_VMW_SYNCCPU fixes this issue.
Reviewed-by: Neha Bhende <neha.bhende@broadcom.com>
Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29755>
The enums were mixed up. Code was working because they were being
used only for their numerical values.
Fixes: e666872c75 ("intel/compiler: Initial bits for DPAS instruction")
Acked-by: Iván Briano <ivan.briano@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29762>
It prevents the hazard when in the following case:
ldc.1.k.imm c[a1.x], 0, 1
(ss)mova1 a1.x, 8
The correct way is:
ldc.1.k.imm c[a1.x], 0, 1
(ss)mova1 a1.x, (r)8
Without it ldc may use a1.x which is set after ldc.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27462>
