CS-like and TCS control barriers converged in gfx >= 125, so use a
common helper for the message payload setup.
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18362>
Allow us to implement this in brw_fs_visitor.cpp, which then will
let us deduplicate code between the CS-like barrier and the TCS
barrier in a later patch.
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18362>
We can't directly convert from unsigned integers smaller than 64 bit to
unsigned 64 bit integers. Hence, converting from 32 bit to 64 bit is
handled by just merging with 0. To support U8/U16 integers handle them
just the same way.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
We can't convert directly from signed integers smaller 64 bit to signed
64 bit integers. For 32 bit integers this is handled with SHR and MERGE.
In order to also support 8/16 bit singed integers convert them to 32 bit
first.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
We can't convert from a 64 bit integer to any integer smaller than
64 bit directly, hence split the value first and then cvt / mov to the
target type.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
Directly converting from a float to an 8 bit integer and from a 64 bit
float to an integer smaller than 32 bit is not supported, therefore add
an intermediate conversion to an 32 bit integer.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
Conversions to integers must be rounded towards zero, hence, actually
do this for all integers including 8/16 bit sources.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
Converting signed and unsigned integers from 8/16 bit sources to a 64 bit
floating point destination (i2f64 / u2f64) isn't possible, hence convert
the source to 32 bit first.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
Add helper functions to check whether a DataType is an unsigned integer
type and whether a DataType is either an unsigned or signed integer
type.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
Instructions like
mov u16 %r78s 0x00ff (0)
are dropped, since they're not supported by the HW, hence avoid using
8/16 bit destination registers for OP_MOV and use the full width of the
register instead.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
The 'set' instruction does distinguish between signed and unsigned, but
always treats values as 32 bit. For singed values < 0 with a bit width
smaller than 32 bit this falsely results in treating it as a positive
value.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18109>
For those drivers that don't make full use of the 64 bits in
pipe_query_result.u64.
Applications will make use of it via GL_QUERY_COUNTER_BITS to handle
when the value rolls over.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10770>
We don't have any special requirements for this, so we can just expose
the extension.
The tests in CTS have an issue where they only check if a format is
supported for sampling but don't check if an image with that format
can be created for sampling. In our case, since we can't sample
1D depth/stencil images, this causes affected tests to crash in the
simulator (they pass on the device though). There is an issue with
a fix here:
https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/3923
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18489>
On dbenable depth bias is enabled so we need to write the depth
bias data into the depth_bias_array (which gets uploaded to the
device) and also setup the depth bias index (used in the control
stream).
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18438>
Also, update list of expected failures.
dEQP-VK.image.sample_texture.*_bit_compressed_format_two_samplers_*
now reliably pass on Polaris10 (GFX8) and Pitcairn (GFX6).
Stoney has new failures but given there is already a lot of
depth/stencil resolve failures, we shouldn't worry about them.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15587>
If the current layout supports DCC, we initialize it. There's no reason
why we can't leave it in that layout and need to stomp it to
COLOR_ATTACHMENT_OPTIMAL. If the layout supports DCC, it's effectively
identical to COLOR_ATTACHMENT_OPTIMAL anyway.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15587>
With dynamic rendering, the concept of framebuffer dimensions goes away
so this won't make sense. Even with render passes, the render area is
guaranteed to be inside the framebuffer so we may as well clip to the
potentially smaller render area. This commit also moves window scissor
setup to CmdBeginRenderPass2() time. This should be fine, even for meta
ops, as the only meta ops which happen inside a render pass need the
same render area as the render pass itself.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15587>
The test seem to fail when run in conjunction with other tests. This
got revealed after I introduced parrallelism in the VKCTS execution on
VanGogh.
This was caught by pre-merge CI, but idiot me thought this was a
flake... and did not try re-running the job to verify...</BrownBag>
Reference: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7220
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18480>
It was determined that a significant part of queue submission
overhead was from allocation/freeing of CSes constantly inside
`tu_autotune_on_submit`. This has been reduced by retaining
instances of `tu_submission_data` with their corresponding
CSes, this results in entirely eliminating that overhead as
resetting a CS is a very cheap operation compared to allocation
or even freeing it wholly.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18461>
With EXT_gpu_shader4 the support is already in place, we just
have to allow it in glsl and expose the extension name.
v2: Check whether the extension is enabled in the shader (Adam Jackson)
v3: Don't check GLES version in lexer (mareko)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18460>
If a color attachment is used in a render pass but not exported by the
FS, cb_shader_mask would be non-zero for this MRT. Though, to make sure
the hw remapping of SPI_SHADER_COL_FORMAT<->CB_SHADER_MASK works as
expected, we should also clear the unused color attachment in
CB_SHADER_MASK. Otherwise, the hw will remap to the wrong MRT.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7221
Fixes: 8fcb4aa0eb ("radv: compact MRTs to save PS export memory space")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18491>
The color format would be zero and all exports would be removed.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18255>
When building the main FS with GPL we don't know the color export
formats.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18255>
This reports RT commands like vkCmdTraceRaysKHR and
vkCmdBuildAccelerationStructuresKHR in RGP.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18496>
Similar to how other I/O info is cleared at the beginning
of gather_info we should also clear the cross-invocation
mesh shader output mask.
Fixes: 112a856813
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18464>
When the workgroup is 1 dimensional, simply use a vec3
filled with zeroes and the local invocation index.
This is is better than lower_id_to_index + constant folding,
because this way we don't leave behind extra ALU instrs.
Note, this is relevant to mesh shaders on RDNA2 because
it enables us to better detect cross-invocation output
access.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18464>
fence_get_fd is required for any kind of surface flush or native fence
sync export on Android. The typical scenarios are:
- eglDupNativeFenceFDANDROID
- eglSwapBuffers*
- eglMakeCurrent
- glFlush/glFinish for front buffer rendering
This change updates zink_flush to handle PIPE_FLUSH_FENCE_FD via a
forced submit to signal an external sync_fd semaphore. fence_get_fd is
implemented to export the sync file from that semaphore.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18453>
For in-fence handling, dri2 has this below sequence in a row:
1. create_fence_fd: import external fence fd
2. fence_server_sync: import the pipe fence into the driver ctx
3. fence_reference: deref the created pipe fence
Before this change, zink pushed the wrapped external semaphore to the
wait semaphores of the next batch but the followed fence_reference will
destroy the imported semaphore immediately. Instead of extending the
lifecycle of the pipe fence throughout the batch state, we can simply
transfer the semaphore ownership to the batch and destroy it upon batch
reset.
Fixes: 32597e116d ("zink: implement GL semaphores")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18453>
This change fixes below:
1. Dup the fence fd, otherwise, since external semaphore import takes
the ownership of the fd, non-Vulkan part touches the fd leading to
undefined behavior. This can be hit on implementations that defer
the processing of the passed fd.
2. Use VK_SEMAPHORE_IMPORT_TEMPORARY_BIT for importing since that's
required for SYNC_FD handle type because of its copy transference.
Meanwhile, doing temporary import for opaque fd is fine in this path.
Fixes: 32597e116d ("zink: implement GL semaphores")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18453>
