All the MI_SDI currently have forced write checks (meaning the command
streamer will stall until completion) on Gfx12.0+.
Now on Gfx12.0/12.5, the read commands have implicit waits on previous
writes (BSpec ). So if we're only dealing with CS writes & reads, we
don't need forced write checks.
In the few cases where CS is writing data for other bits of HW, we
need the forced write checks. This change adds an API that will let
the driver decide when to enable forced write checks.
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/29571>
With this change, the engine initialization batches are build and
submitted at vkCreateDevice() but the function doesn't wait for them
to complete. Instead we wait at vkDestroyDevice() or whenever another
submission happens on the queue, we check whether the initialization
batch has completed (without waiting) and free it if completed.
Seems to be about 25% reduction time of vkCreateDevice()
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/28975>
The array pool does a single allocation and then splits it out. The
downside is that the pool is not lockless, but for border colors it
likely doesn't matter much as there is a max border colors for 4k.
Seems to be a 30% time reduction for vkCreateDevice()
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/28975>
The Vulkan spec says:
"If pColorAttachmentInputIndices is NULL, it is equivalent to setting
each element to its index within the array."
Fix updated dEQP-VK.dynamic_rendering.primary_cmd_buff.local_read.*.
v2: Fix it correctly (Samuel)
Fixes: 03490ec019 ("vulkan/runtime: rework VK_KHR_dynamic_rendering_local_read state tracking")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29703>
Add the fixed-rate compression ratios exposed by GL and Vulkan to the
flags for gbm_bo and gbm_surface creation, and intersect these with the
list of supplied modifiers to add another filter.
Although gbm_surface could support this by the EGLSurface flags in
EGL_EXT_surface_compression, gbm_bo cannot: it allocates a buffer first
and then imports it into the consuming API post-hoc, after the modifier
is already (must be) known. It seems more important to keep the
gbm_surface and gbm_bo APIs in sync, so keep the responsibility for
filtering on the GBM side.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27109>
This adds two new methods for the image extension (version 22):
- Query the supported compression bitrates for a given format
- Query the modifiers associated with a given format and bitrate
The interface user can then use createImageWithModifiers to
actually allocate the fixed-rate compressed image. When the default
bitrate is requested, one can query the image for the
__DRI_IMAGE_ATTRIB_COMPRESSION_RATE attribute to determine the
compression rate that was actually used.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27109>
According to PRMs:
"All parameters are of type IEEE_Float, except those in the The ld*,
resinfo, and the offu, offv of the gather4_po[_c] instruction message
types, which are of type signed integer."
Currently, we load parameters with the correct types, but use them as send
sources with the default float type, which may confuse passes downstream.
Fix this by actually storing the retyped sources.
Cc: mesa-stable
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29581>
For A6XX it's a no-op, but A7XX+ doesn't clamp to [0,1] with disabled
depth clamp, to support VK_EXT_depth_clamp_zero_one we have to always
enable clamp and manually set depth range to [0,1] when rs->depth_clamp_enable
is false.
Passes:
dEQP-VK.depth.*
dEQP-GLES3.functional.fbo.depth.depth_test_clamp.* (zink)
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29387>
This AUX-TT is only updated on the CPU since ee6e2bc4a3 ("anv: Place
images into the aux-map when safe to do so"). So the only really
important invalidation that needs to happens is on the beginning of a
primary command buffer.
We are required to idle the pipes prior invalidation the AUX-TT. This
might not be happening when the invalidation is put at the beginning
of the secondary command buffers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29671>
nightly_compare.
Compare the two latest scheduled pipelines and provide information
about the jobs you're interested in.
The job part reports:
- RED previously passing jobs
- YELLOW jobs which failed before, but continue to fail
here is also available link to the previous failed run
- If no job failing, program exits.
The test part reports:
- everything in lovely table
If any failing job is found, after this phase, commit list between these
two scheduled run is printed (you can also use the WebUI link).
Example: I care about all Adreno jobs passing and one Radeon (r300)
with gallium-nine tests.
```
./bin/ci/nightly_compare.py --target "a[3-7][0-9][0-9].*|r300-rv530-nine"
```
Co-authored-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29392>