On integrated platforms, we have issue where L3 cache not being coherent
with CS and it forces us to push data out L3.
To avoid data cache flush, let's write the IR header with BLORP shader.
There is a small shader launch latency but eventually that should not
matter because writing data with CS (MI_STORE) commands is slower than
shader execution when we consider large number of BVH tree getting
built.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39971>
This sets the per-vertex point size state correctly in the presence of mesh shaders.
(fixes line is just a educated pick)
Fixes: 51d6e4404a ("mesa: allow NULL for vertex shader when mesh pipeline")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40475>
Currently the headless WSI unconditionally uses DRM images as WSI
images, which isn't proper behavior for working with lavapipe driver,
and leads to either error or crash (depending on whether udmabuf is
available).
Properly setup CPU images instead of DRM images for software-rendering
WSI devices.
This fixes (at least) `dEQP-VK.wsi.headless.swapchain.render.*` on
lavapipe.
Fixes: 90caf9bdbd ("vulkan/wsi/headless: drop the wsi_create_null_image_mem override")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40360>
When libdisplay-info is available and we are able to retrieve the
physical size of a display from its EDID, use that to populate the
physicalDimensions field of VkDisplayPropertiesKHR.
Signed-off-by: Erik Kurzinger <ekurzinger@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39989>
When libdisplay-info is available and we are able to retrieve the make
and model of a display from its EDID, use those to construct a more
useful displayName for VkDisplayPropertiesKHR.
Signed-off-by: Erik Kurzinger <ekurzinger@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39989>
Add dedicated BLORP op enums so clear paths can be represented
precisely.
This is enum-only groundwork; behavior and trace output are wired in
follow-up commits.
Signed-off-by: Michael Cheng <michael.cheng@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40414>
The runtime builds a final pipeline state with pointers to structures
coming from the associated pipelines libraries.
So far it has considered that the viewMask was part of a structure
together with the rest of the renderpass information. This information
can be specified in pre-raster, fragment & color-output state groups
and it was assumed would be consistent for all 3. And the runtime
currently takes the pointer to the structure from the last pipeline
library (color output).
Some coming spec/cts will clarify that the viewMask only needs to be
specified for pre-raster & fragment groups, making the value in the
color-output group untrustworthy.
This change creates a new state structure to hold the viewMask on its
own so it is only gather on pre-raster & fragment groups.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (radv)
Reviewed-by: Aitor Camacho <aitor@lunarg.com> (kosmickrisp)
Reviewed-by: Connor Abbott <cwabbott0@gmail.com> (turnip)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (v3dv)
Reviewed-by: Frank Binns <frank.binns@imgtec.com> (powervr)
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com> (panvk)
Royaled-yes-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> (lavapipe)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39940>
Move lowering to nir_lower_subgroups. At some point Intel
backend might want to skip that and lower at the backend IR
boundary, but for now lowering always applies.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40376>
CmdResetEvent2() was calling anv_add_pending_pipe_bits() with no dst_stages
stages causing RESOURCE_BARRIER::Wait stage == none, what causes a GPU hang in
NVL-P simulator.
So here setting dst_stages to VK_PIPELINE_STAGE_2_TOP_OF_PIPE_BIT and adding
an assert in resource_barrier_wait_stage() to catch hw_stage == 0.
This fixes crucible func.event.cmd_buffer.q0 in simulator.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40445>
The prior version of gfxstream-fuchsia featured an Android compat
layer, and only worked with Goldfish. The compat layer was
deleted a while ago.
The Fuchsia Goldfish integration was deleted here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33050
since the Fuchsia emulator itself uses a frozen version of the
library. This goes further in that direction: deleting leftovers
of the Fuchsia Android compat layer, which used provided VK
dispatch.
This allows Fuchsia + gfxstream to build via meson2hermetic, with
the a few additional common core patches applied.
Reviewed-by: David Gilhooley <djgilhooley@gmail.com>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40442>
It is an output. Useful for meson-to-bazel conversion, where
Bazel happened to spot this.
Reviewed-by: David Gilhooley <djgilhooley@gmail.com>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40442>
Both inc_guest_iostream and inc_platform_virtgpu were used
twice in the same include_directories array.
Reviewed-by: David Gilhooley <djgilhooley@gmail.com>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40442>
Sometimes, it's used with fds (int32_t), sometimes with
gem_handle (uint32_t). Be consistent and explicitly cast
when needed.
Reviewed-by: David Gilhooley <djgilhooley@gmail.com>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40442>
This codepath had a bug (always setting `elems[0]`) since it was last
reworked, but there's no subgroup instruction that uses this helper and
support Composites, so it can be replace with an assert.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40356>
There's no reason to adjust the matrix once unconditionally, and then
agaiun conditionally after overwriting the matrix. If we just make the
second adjustment unconditional, we should be good.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40175>
This is just cleaning up some naming, so we consistently refer to things
dealing with luma as "y" and things dealing with chroma as "c".
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40175>
There's a few things going on here:
1. Vulkan makes the YCbCr model and YCbCr range completely orthogonal.
This means that we need to be able to handle an identity transform
while still doing range-remapping, so we apply the range mapping and
color-transform separately, and let the optimizer clean things up.
This is similar to what we did before, but it means it's a bit harder
to get completely optimal code out of this.
2. Vulkan defines that the YCbCr inputs come in a bit of an unusual
order; Cr, Y, Cb. This means we need to reorder things a bit when
applying the YCbCr range and multiplying the YCbCr color-model
matrix. This makes the code a little bit confusing to read at times.
3. Because the alpha-channel is passed through this function, we need to
expand the matrix to 4x3. This is similar to what we've already been
doing, but also a bit unusual. In the future, we might want to keep
the alpha-channel out of this code-path, and just work on a vec3
here.
I suspect that all of these can be solved by rearranging the code a bit.
But I've left that as an excercize for later to make sure we get this
right first, with as few modifications as possible. Some people might
disagree with this approach, but let's see.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40175>
This adds some reusable math to set up YCbCr to RGB color transforms. It
covers ITU BT.601, ITU BT.709 and ITU BT.2020 YUV <-> RGB conversion, as
well as "narrow"" and "full" range.
This code is intended to replace three different implementations of
YUV-transforms already present in Mesa, all of them with different
parameterizations and differences in data-formats. These implementations
are: nir_lower_tex.c, vk_nir_convert_ycbcr.c and vl_csc.c.
None of the exising implementations seems to fully cover all of the needs
of the others. The one that comes the closest is the one in vl_csc.c, but
it has a few issues:
1. It doesn't differentiate between per-channel bit-sizes, which the
Vulkan code needs.
2. It uses enums from p_video_enums.h in Gallium to paremeterize the
behavior.
3. It's written in a monolithic way, handling up to two
range-remappings, which the other implementations doesn't need.
While it could be possible to entangle all of that, that would likely
end up being a more or less a new implementation anyway. So let's instead
try to pick the best of all three implementations into one new one,
that's broken into smaller pieces that can be assembled into either of
the three.
In addition, this implementation has a bunch of unit-tests, to make sure
we don't introduce subtle breakages down the line.
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40175>
Removed this by mistake during a rebase presumably.
This fixes a regression with
dEQP-VK.pipeline.monolithic.multisample.m10_resolve.* on <= GFX8.
Fixes: 1746837a71 ("radv/meta: remove CB_RESOLVE")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40449>
Allow applications to control the virtual address where device memory
is mapped by passing MAP_FIXED to mmap via pan_kmod_bo_mmap().
Support VK_MEMORY_UNMAP_RESERVE_BIT_EXT by replacing the mapping with
a PROT_NONE anonymous mapping to keep the address range reserved.
Only memoryMapPlaced and memoryUnmapReserve are advertised.
memoryMapRangePlaced is not supported because the DRM GEM mmap offset
mechanism requires mapping from offset 0.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40315>
DRM GEM mmap offsets go through drm_vma_offset_exact_lookup_locked()
which requires an exact match on the GEM offset. Passing a non-zero
bo_offset causes EINVAL because the kernel can't find the BO at the
shifted offset. Every caller already passes bo_offset=0 and maps the
full BO size, so drop those parameters and use bo->size directly.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40315>
No idea if this is more typical of navi31 or not, but it's what my system
has.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40409>
The cmd_buffer->vertex_bindings was not cleared when resetting the command buffer.
The previous misaligned_mask_invalid bits were not preserved when calling radv_CmdBindVertexBuffers2 multiple times.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40312>
If we are growing a CL, double the BO allocation size to reduce the
number of allocations in large command buffers. This showed significant
performance improvements in workloads with large CLs (e.g. WebGL
Aquarium with 5000 fishes). Also, this is the same strategy that v3dv
uses.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40425>
Android requires VK_ANDROID_native_buffer v8+ to advertise KHR_swapchain
v69+ for supporting wsi image alias. On newer Android, the same is
required to advertise EXT_swapchain_maintenance1 to avoid memory hit
upon swapchain creation/recreation. This change completes the support.
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40384>
